On Sat, Feb 18, 2012 at 9:52 PM, André DeMarre <[email protected]>wrote:
> The spec already does what you ask... > > Wenjie Lin wrote: > > 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. > > That's not true. Consider 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.* > > The problem is the underlined part above. The authorization server can never figure out whether *the issued access token scope is different from the one requested by the client, *since the authorization server only receives scope information from the user – never from the client. So long as the user sends to the authorization server a consistent scope, that can be different than the one requested by the client, the authorization server can never figure out the difference. Consequently, the authorization server MAY NOT *include the "scope" response parameter to inform the client of the actual scope granted, *resulting in a scope attack. > See also draft-ietf-oauth-v2-23 section 5.1 regarding issuing an access > token: > scope > OPTIONAL, if identical to the scope requested by the client, > otherwise REQUIRED. The scope of the access token as described > by Section 3.3. > > > Regards, > Andre DeMarre > > On Sat, Feb 18, 2012 at 8:18 PM, Wenjie Lin <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> > >> > To: [email protected] > >> > Date: 18/02/2012 12:12 PM > >> > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 > >> > Sent by: [email protected] > >> > > >> > > >> > > >> > 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 > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > -- Wenjie Lin
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
