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 <lin....@osu.edu> > To: oauth@ietf.org > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
