Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

[John Bradley <[e-mail]>]

Removing the unstopped response solves nothing , because the resource owner can revoke a scope at any time after granting it.  
Nothing forces the Authorization server to revoke the refresh or access token if a scope is revoked.  That is a implementation choice of the Authorization server.

This 'attack'  is one that only works with badly designed clients that are making unwarranted assumptions about the behaviour of the Authorization server.  

The only way for a client to know if a token has a scope it to try it, or use a introspection endpoint.  End of story.

John B.
On 2012-02-21, at 6:43 PM, William Mills wrote:

> No, I do not agree that this is an attack.  The resource owner has granted different privs than the client expects, but that was done by the resource owner.   The only "attack" is the resource owner against the client, and the client is going to have to have a way to detect invalid tokens anyway.
> 
> As I said in the first paragraph below, this is already (good or bad) part of the protocol, that the scope profile issued may differ.  What *might* fix this is if the auth server must also return the scopes requested if they are covered by the token; so if the client asks for scope A (we'll say this is a legacy client scope) which is a proper subset of B, and the auth server wants to issue B (the new scope for the new version of a client) then the server would have to return "B A" as the scope list indicating both scope.
> 
> The problem still lies in an unscoped response, which some implementations will want to use "" for.  If we force the above we force global scopes to be named, which isn't horrible.
> 
> From: Wenjie Lin <[e-mail]>
> To: William Mills <[e-mail]> 
> Cc: John Bradley <[e-mail]>; "[e-mail] ([e-mail])" <[e-mail]>; "Lee, David" <[e-mail]> 
> Sent: Tuesday, February 21, 2012 12:07 PM
> Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
> 
> Our understanding is that you agree this is indeed a scope attack, that is, the user may get services, which are different than the client has agreed.
> If the protocol adopts the change we’ve suggested, the client immediately figures out the difference between what he has agreed and what is in the access token. How does the client deal with it? Decline the service or take other actions? Indeed, as you rightly pointed out, it is an issue of operation – an excellent note for the implementer. However, this is no longer a protocol issue.
> -W. Lin and D. Lee
> 
> On Sat, Feb 18, 2012 at 8:34 PM, William Mills <[e-mail]> wrote:
> So, I think what you are pointing out is an operability flaw rather than a security one.  It is possible that the client will be issued a token that does not have the permissions it expects, and the only way for the client to determine this in a guaranteed fashion is to do an operation and see a failure.
> 
> The question then is, does this warrant a MUST rather than SHOULD.  The server may issue a more privileged token for example.  From the scope name there's no way for the client to actually resolve the scope name to privilege, so even if the server provides the scope we might have the same problem.
> 
> There are current usages in comaparable systems where an unscoped token implies no restriction.  The semantics of scope names here have intentionally been left fuzzy.  It's a significant change to try to fix this problem, but the questionis whether it's worth it?  I doubt that will get it right in a way that people will agree with, I don't think you proposed change is sufficient to resolve the problem.
> 
> Would it be sifficient to call it out as an implementors note or a nota bene type editorial comment?
> 
> -bill
> 
> 
> From: Wenjie Lin <[e-mail]>
> To: John Bradley <[e-mail]> 
> Cc: "[e-mail] ([e-mail])" <[e-mail]> 
> Sent: Saturday, February 18, 2012 8:18 PM
> Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
> 
> We appreciate your attention and response to our report.
>  
> Since Authorization Server obtains the scope information ONLY from User, it can’t tell whether the issued access token scope  is different from the one requested by Client, so long as User is consistently sending the same altered scope information to Authorization Server. Consequently, as an Option, Authorization Server may choose not to include the scope response parameter to inform Client of the actual scope granted, and that results in the scope attack. This is a protocol issue and is not an implementation issue; one can come up with an implementation that is compliant with the protocol specification yet with a scope attack.
>  
> One may argue that we only care about User protection and security. Consequently, scope attack is apparently not a protocol security issue. However, it would significantly limit the applicability of the protocol, if Client is knowingly exposed to attacks. We need Client protection and security as well in applications, for instance, cloud services.
>  
> Scope attack can be easily fixed. One can simply make it Required that Authorization Server MUST include the scope response parameter to inform Client of the actual scope granted, as we have proposed for your consideration.
>  
> OAuth 2.0 is a sound protocol design. We prove the security properties (for both User and Client) and scope attack is an issue we’ve got stuck in the proof.
>  
> - W. Lin and D. Lee
> 
> On Sat, Feb 18, 2012 at 2:47 PM, John Bradley <[e-mail]> wrote:
> I agree that it is not a protocol problem.
> 
> The problem is that some developers are not understanding the spec.
> 
> One case I saw recently was a proposal to send a scope to the Authorization endpoint that changed is authentication behaviour e.g. ask for mlti-factor authentication.
> 
> On a superficial reading of the spec they thought that not getting a changed set of scopes back in the response that the Authorization server was indicating that it had done what was asked.
> 
> When I pointed out that the user agent can remove scopes because requests are not signed,  they had a similar solution of forcing all the endpoints to always return the scopes granted.
> 
> I hope I talked them out of that.
> 
> The problem is getting people to use scopes to represent resources and not other arbitrary configuration things,  and to understand that even if they do get a scope granted it could disappear before they get to use the access token and they need to be prepared for that.
> 
> The premise that users get access to y for access to x is something that can be built with OAuth but is not something that can be inferred in the way they are proposing.
> 
> From my perspective replying with granted scopes is a convince for the client, but not something that can be depended upon.
> I don't think we need any normative change.
> 
> A don't make stupid assumptions about the persistence of scopes in tokens note would be as far as I would go.
> 
> John B.
> 
> On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:
> 
> > I agree with others - this is not an attack on the protocol. The user has
> > the choice about which scope to grant and the client's redirect to the
> > authorization endpoint is only a request for a particular set of
> > permissions, not a guarantee that it will get them. The user+authorization
> > server decide which scope is actually granted. The client needs to handle
> > cases where that differs from what it originally wanted.
> >
> >
> >
> >
> > From: Wenjie Lin <[e-mail]>
> > To:   [e-mail]
> > Date: 18/02/2012 12:12 PM
> > Subject:      [OAUTH-WG] A Scope Attack against OAuth 2.0
> > Sent by:      [e-mail]
> >
> >
> >
> > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called scope
> > attack, provide a live-demo of the attack on Facebook, and propose a fix
> > with discussions.
> >
> >
> >
> >
> >
> > Scope Attack
> >
> >
> > OAuth authorization of services is associated with service agreement scope.
> > For instance, Client provides an online game to User with a service
> > agreement scope A: User authorizes Client to access his profile information
> > and to post messages on his behalf. A malicious User can request for online
> > game with service agreement scope A, manipulate the scope field, and change
> > it to scope B: User authorizes Client to access his profile information.
> > User can still play the games,  yet Client can’t post messages on User’s
> > behalf, as originally agreed.
> >
> >
> > OAuth 2.0 authorization code grant and implicit grant are vulnerable to the
> > scope attack.
> >
> >
> >
> >
> >
> > A Scope Attack Scenario
> >
> >
> > (1) Authorization Server: Facebook (authorization code grant)
> >
> >
> >      (2) Client: Online gaming company Game. It allows User to play the
> >      games with the service agreement scope A: User authorizes Game to
> >      access his profile information and post messages on his behalf.
> >
> >
> >      (3) User: malicious User with an account at Facebook. He attempts to
> >      play the games yet without authorizing Game to post messages on his
> >      behalf, that is, he changes the scope from A to B: authorization of
> >      Client to access his profile information only.
> >
> >
> >
> >
> >
> > Attack Workflow
> >
> >
> >        (1) User requests Game (Client) for permission to play games,
> >        instantiating OAuth 2.0 with scope A.
> >
> >
> >        (2) Game generates an authorization request with a scope
> >        specification A, and redirects User to Facebook with the request.
> >
> >
> >        (3) User manipulates the scope field and changes it to scope B. The
> >        modified request is then sent to Facebook.
> >
> >
> >        (4) User grants the modified request.
> >
> >
> >        (5) Facebook redirects User back to Game with the authorization
> >        code.
> >
> >
> >        (6) Game exchanges the authorization code for an access token.
> >        However it has no knowledge that the scope A has been changed to
> >        scope B.
> >
> >
> >        (7) Game provides online gaming service to User. However, Game
> >        can’t post messages on User’s Facebook page.
> >
> >
> >
> >
> >
> > A Live-Demo: Facebook and CastleVille (IE and Safari tested)
> >
> >
> >      Step 1: Login Facebook and visit Facebook Apps and Game page
> >
> >
> >      https://www.facebook.com/games
> >
> >
> > Step 2: Click CastleVille.
> >
> >
> >      Step 3: When you see the Request for Permission page, instead of
> >
> >
> >            clicking “Allow”, change the scope field in the URL from your
> >            browser from  “scope=email%2Cpublish_stream%2Cpublish_actions”
> >            to “scope=email%2Cpublish_stream”.
> >
> >
> >      Step 4: After the modification, press ENTER to send the modified
> >
> >
> >            request to Facebook. Now you will see the modified Request of
> >            Permission page.
> >
> >
> > Step 5: Click on “Allow” button and enjoy the game.
> >
> >
> > (video: http://www.youtube.com/watch?v=zkmjLa3VU9w)
> >
> >
> >
> >
> >
> > Impact
> >
> >
> > Client provides services to malicious User yet with the modified service
> > agreement scope by User’s design.
> >
> >
> >
> >
> >
> > Manipulating Scope Field
> >
> >
> > The scope field in access token response is required ONLY IF Authorization
> > Server observes that the User authorized scope is different than the
> > original scope. Consequently, User can manipulate the scope field so that
> > Authorization Server cannot detect the change of the scope. As a result
> > Client provides the services yet can’t obtain the information that is
> > specified in the scope of the original service agreement.
> >
> >
> > Client can verify the service agreement scope by checking all the fields
> > against the original User request before providing the requested services
> > to User.  For instance, Client can verify the granted permissions if
> > Authorization Server (e.g. Facebook)  provides an API. However, this is out
> > of the scope of OAuth 2.0, and Client may not check it. We observe: all top
> > five games recommended by Facebook are vulnerable to the scope attack.
> >
> >
> >
> >
> >
> > Proposed Fix
> >
> >
> > Draft-ietf-oauth-v2-23 Section 5.1:
> >
> >
> > Change from
> >
> >
> >      “scope
> >
> >
> >               OPTIONAL, if identical to the scope requested by the client,
> >
> >
> >               otherwise REQUIRED.”
> >
> >
> > to
> >
> >
> > “scope REQUIRED” /* scope: User authorized scope */
> >
> >
> >
> >
> >
> > Remarks
> >
> >
> > (1) The proof of the correctness of OAuth with our proposed fix will be
> > published in an article: “OAuth 2.0 – Attacks, Fixes, Correctness, and
> > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear”.
> >
> >
> > (2) The implicit grant is also vulnerable to the scope attack. However it
> > cannot be fixed by enforcing scope field in access token response as above;
> > User can change the scope in response before being redirected to Client.
> >
> >
> >
> >
> >
> > Wenjie Lin, The Ohio State University
> >
> >
> > David Lee, HP Labs and The Ohio State University
> >
> >
> > Steve Lai, The Ohio State University
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> 
> -- 
> Wenjie Lin
> 
>