Nick, You are talking about cross-site request forgery (CSRF) attacks. These need to be mentioned in the (currently empty) Security Considerations section. There is text about CSRF in the OAuth 1.0 Security Considerations. There are better solutions than CAPTCHAs or always re-authenticating.
-- James Manger -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nick Snyder Sent: Thursday, 27 May 2010 9:18 AM To: oauth@ietf.org Subject: [OAUTH-WG] Stricter End User Endpoint Requirements Hi all, I am fairly new to this mailing list so my apologies if this has already been discussed. Section 3.2 (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.2) The way in which the authorization server authenticates the end user (e.g. username and password login, OpenID, session cookies) and in which the authorization server obtains the end user's authorization, including whether it uses a secure channel such as TLS/SSL, is beyond the scope of this specification. However, the authorization server MUST first verify the identity of the end user. This paragraph seems to imply that it is sufficient to use a session cookie to "verify" the identity of the user. Although the client cannot determine what the session cookie is, it can still take advantage of the fact that the browser will automatically include this cookie in any request to the authorization server. Consider an authorization server that implements the following end user endpoint and we are dealing with the web server flow 1) End user logs in and obtains a session cookie. This step is skipped if the end user already has a valid session cookie. 2) Client information is displayed to end user and the end user is asked to approve or deny the request by submitting a form. 3) End user endpoint verifies the cookie, approves or denies the request, and redirects the user to the redirect_uri If the form submission in step 2 only contains parameters that the client knows or can figure out then all then all a malicious client has to do it is get the end user to click on a link while they are logged in to the service. This link could lead to a webpage controlled by the malicious client where the the malicious client constructs the necessary form and automatically submits that form on page load using javascript. The client would then be redirected to whatever redirect_uri the malicious client specified and the end user would have no idea what just happened. As an illustrative example, assume that Facebook implemented the above end user endpoint. The malicious client could be a Facebook application which gets users to click on its crafted link via Facebook ads (thereby guaranteeing that anyone clicking on the ad is already logged in to Facebook). The end user would click on the ad and have no idea that they just authorized the malicious application to post to their wall. My suggestion would be to add language that defines "verification" as collecting some piece of information that the client could not reasonably know, deduce, or coerce the client into submitting (as is the case of the session cookie). This piece of information could be left undefined in the spec but examples would be 1) Require the user to always re-authenticate (e.g. username & password) before granting authorization 2) Have a CAPTCHA on the form in step 2 of my example Does this make sense? Nick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
