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

[André DeMarre <[e-mail]>]

Agreed. In fact, Facebook's auth dialog allows the user to deny
certain permissions the client has requested at the time of
authorization, which makes tampering with the scope field unnecessary.
The user is the resource owner after all.

draft-ietf-oauth-v2-23 Section 3.3:
   The authorization server MAY fully or partially ignore the scope
   requested by the client based on the authorization server policy or
   the resource owner's instructions.  If the issued access token scope
   is different from the one requested by the client, the authorization
   server MUST include the "scope" response parameter to inform the
   client of the actual scope granted.

Regards,
Andre DeMarre

On Fri, Feb 17, 2012 at 7:08 PM, Dick Hardt <[e-mail]> wrote:
> Some of the more interesting capabilities that an app can ask for are
> revokable by the user later on.
>
> Facebook has an API call
>
> /me/permissions
>
> That lets an app determine what permissions the user has granted the app. If
> need be the app can then ask (or re-ask) for additional scopes.
>
> Additionally, Facebook could decide an app should have fewer scopes and take
> away privileges from the app. A good app would be able to deal with no
> longer being authorized to perform an action.
>
> I fail to see the security issue here.
>
> -- Dick
>
> On Feb 17, 2012, at 7:40 PM, William Mills wrote:
>
> I don't think the problem as described is an attack per se, the user is able
> to modify the rights being granted.  The user is after all in control of
> what they want to allow.  In this case it looks like FBs implementation is
> pretty loose with the games apps and there's no guarantee you'll get the
> rights you want as a game developer.
>
> What this scenario mean is that the integrity of the request from the game
> company to FB via the user's context does not have sufficient integrity
> guarantee.  It is certainly possible for the auth server to have a registry
> of known clients and expected scopes, and in fact the auth server is
> expected to communicate to the user what they are approving.
>
> Can an attacker cause a user to approve a token with an unexpected scope?
> That would be a big problem.
>
> ________________________________
> From: Wenjie Lin <[e-mail]>
> To: [e-mail]
> Sent: Friday, February 17, 2012 6:07 PM
> Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0
>
> 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
>