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

[Wenjie Lin <[e-mail]>]

On Sat, Feb 18, 2012 at 9:52 PM, André DeMarre <[e-mail]>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 <[e-mail]> 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 <[e-mail]> 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 <[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
> >> >
> >> >
> >> > _______________________________________________
> >> > OAuth mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>



-- 
Wenjie Lin