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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
