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

[William Mills <[e-mail]>]

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 scopeA: 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 scopeA, manipulate the scope field, and change
it to scopeB: 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 scopeA: 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 scopeA.
(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 scopeB. 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 scopeA has been
changed to scopeB. 
(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