Subject: [OAUTH-WG] Stricter End User Endpoint Requirements

From: Nick Snyder <[email-masked]>
Date: Wed, 26 May 2010 16:18:23 -0700

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

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 27 May 2010 10:02:25 +1000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Nick Snyder
Sent: Thursday, 27 May 2010 9:18 AM
To: [email-masked]
Subject: [OAUTH-WG] Stricter End User Endpoint Requirements

Section 3.2  

Does this make sense?
Nick
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth