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

[Shane B Weeden <[e-mail]>]

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