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

From: Wenjie Lin <[email-masked]>
Date: Fri, 17 Feb 2012 18:07:17 -0800

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

---

From: William Mills <[email-masked]>
Date: Fri, 17 Feb 2012 18:40:13 -0800 (PST)

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 <[email-masked]>
To: [email-masked] 
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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Feb 2012 20:08:24 -0700

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:

> 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
> (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.
> (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)
> clicking “Allow”, change the scope field in the URL from your browser from  “scope=email%2Cpublish_stream%2Cpublish_actions” to “scope=email%2Cpublish_stream”.
> request to Facebook. Now you will see the modified Request of Permission page.
> 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
> (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.
>

---

From: André DeMarre <[email-masked]>
Date: Sat, 18 Feb 2012 00:20:55 -0800

Agreed. In fact, Facebook's auth dialog allows the user to deny
certain permissions the client has requested at the time of
authorization, which makes tampering with the scope field unnecessary.
The user is the resource owner after all.

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.

Regards,
Andre DeMarre

On Fri, Feb 17, 2012 at 7:08 PM, Dick Hardt <[email-masked]> wrote:
> 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 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.
>
> 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
> 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.
> with the service agreement scope A: User authorizes Game to access his
> is, he changes the scope from A to B: authorization of Client to access his
> profile information only.
>
> Attack Workflow
> OAuth 2.0 with scope A.
> (2) Game generates an authorization request with a scope specification A,
> has no knowledge that the scope A has been changed to scope B.
> clicking “Allow”, change the scope field in the URL from your browser from
> “scope=email%2Cpublish_stream%2Cpublish_actions” to
> “scope=email%2Cpublish_stream”.
> 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
> published in an article: “OAuth 2.0 – Attacks, Fixes, Correctness, and
> Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear”.
> User can change the scope in response before being redirected to Client.
>

---

From: Shane B Weeden <[email-masked]>
Date: Sat, 18 Feb 2012 16:34:54 +1000

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-masked]>
To:	[email-masked]
Date:	18/02/2012 12:12 PM
Subject:	[OAUTH-WG] A Scope Attack against OAuth 2.0
Sent by:	[email-masked]

Scope Attack

A Scope Attack Scenario

      (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.

        (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.

            clicking “Allow”, change the scope field in the URL from your
            browser from  “scope=email%2Cpublish_stream%2Cpublish_actions”
            to “scope=email%2Cpublish_stream”.

            request to Facebook. Now you will see the modified Request of
            Permission page.

Impact

Manipulating Scope Field

Proposed Fix

Change from

      “scope

               otherwise REQUIRED.”

to

Remarks

---

From: John Bradley <[email-masked]>
Date: Sat, 18 Feb 2012 19:47:24 -0300

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.

---

From: Wenjie Lin <[email-masked]>
Date: Sat, 18 Feb 2012 20:18:45 -0800

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-masked]> wrote:

> 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.
>
> 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.

---

From: William Mills <[email-masked]>
Date: Sat, 18 Feb 2012 20:34:53 -0800 (PST)

So, I think what you are pointing out is an operability flaw rather than a security one.  It is possible that the client will be issued a token that does not have the permissions it expects, and the only way for the client to determine this in a guaranteed fashion is to do an operation and see a failure.

The question then is, does this warrant a MUST rather than SHOULD.  The server may issue a more privileged token for example.  From the scope name there's no way for the client to actually resolve the scope name to privilege, so even if the server provides the scope we might have the same problem.

There are current usages in comaparable systems where an unscoped token implies no restriction.  The semantics of scope names here have intentionally been left fuzzy.  It's a significant change to try to fix this problem, but the questionis whether it's worth it?  I doubt that will get it right in a way that people will agree with, I don't think you proposed change is sufficient to resolve the problem.

Would it be sifficient to call it out as an implementors note or a nota bene type editorial comment?

-bill

________________________________
 From: Wenjie Lin <[email-masked]>
To: John Bradley <[email-masked]> 
Cc: "[email-masked] ([email-masked])" <[email-masked]> 
Sent: Saturday, February 18, 2012 8:18 PM
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

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

---

From: André DeMarre <[email-masked]>
Date: Sat, 18 Feb 2012 21:52:51 -0800

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:

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-masked]> wrote:
> protocol specification yet with a scope attack.
>
>
>
> security as well in applications, for instance, cloud services.
>
>
>
> consideration.
> proof.
>> Authorization endpoint that changed is authentication behaviour e.g. ask for
>> mlti-factor authentication.
>>
>> changed set of scopes back in the response that the Authorization server was
>> indicating that it had done what was asked.
>>
>> are not signed,  they had a similar solution of forcing all the endpoints to
>> always return the scopes granted.
>>
>> can be built with OAuth but is not something that can be inferred in the way
>> they are proposing.
>>
>> >            browser from
>> >  “scope=email%2Cpublish_stream%2Cpublish_actions”

---

From: Wenjie Lin <[email-masked]>
Date: Tue, 21 Feb 2012 11:25:27 -0800

On Sat, Feb 18, 2012 at 9:52 PM, André DeMarre <[email-masked]>wrote:

>    the resource owner's instructions.  *If the issued access token scope
> *
> *   is different from the one requested by the client, the authorization
>   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.

> >> A don't make stupid assumptions about the persistence of scopes in
> tokens
> >> note would be as far as I would go.
> >>
> >> John B.
> >>
> >> > OAuth 2.0 authorization code grant and implicit grant are vulnerable
> to
> >> > the
> >> > scope attack.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > A Scope Attack Scenario
> >> >
> >> >
> >> > 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

-- 
Wenjie Lin

---

From: Wenjie Lin <[email-masked]>
Date: Tue, 21 Feb 2012 12:07:54 -0800

Our understanding is that you agree this is indeed a scope attack, that is,
the user may get services, which are different than the client has agreed.**
**

If the protocol adopts the change we’ve suggested, the client immediately
figures out the difference between what he has agreed and what is in the
access token. How does the client deal with it? Decline the service or take
other actions? Indeed, as you rightly pointed out, it is an issue of
operation – an excellent note for the implementer. However, this is no
longer a protocol issue.

-W. Lin and D. Lee

On Sat, Feb 18, 2012 at 8:34 PM, William Mills <[email-masked]> wrote:

> So, I think what you are pointing out is an operability flaw rather than a
> security one.  It is possible that the client will be issued a token that
> does not have the permissions it expects, and the only way for the client
> to determine this in a guaranteed fashion is to do an operation and see a
> failure.
>
> The question then is, does this warrant a MUST rather than SHOULD.  The
> server may issue a more privileged token for example.  From the scope name
> there's no way for the client to actually resolve the scope name to
> privilege, so even if the server provides the scope we might have the same
> problem.
>
> There are current usages in comaparable systems where an unscoped token
> implies no restriction.  The semantics of scope names here have
> intentionally been left fuzzy.  It's a significant change to try to fix
> this problem, but the questionis whether it's worth it?  I doubt that will
> get it right in a way that people will agree with, I don't think you
> proposed change is sufficient to resolve the problem.
>
>   ------------------------------
> *From:* Wenjie Lin <[email-masked]>
> *To:* John Bradley <[email-masked]>
> *Cc:* "[email-masked] ([email-masked])" <[email-masked]>
> *Sent:* Saturday, February 18, 2012 8:18 PM
> *Subject:* Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
>
> 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
> 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
>

-- 
Wenjie Lin

---

From: William Mills <[email-masked]>
Date: Tue, 21 Feb 2012 13:43:21 -0800 (PST)

No, I do not agree that this is an attack.  The resource owner has granted different privs than the client expects, but that was done by the resource owner.   The only "attack" is the resource owner against the client, and the client is going to have to have a way to detect invalid tokens anyway.

As I said in the first paragraph below, this is already (good or bad) part of the protocol, that the scope profile issued may differ.  What *might* fix this is if the auth server must also return the scopes requested if they are covered by the token; so if the client asks for scope A (we'll say this is a legacy client scope) which is a proper subset of B, and the auth server wants to issue B (the new scope for the new version of a client) then the server would have to return "B A" as the scope list indicating both scope.

The problem still lies in an unscoped response, which some implementations will want to use "" for.  If we force the above we force global scopes to be named, which isn't horrible.

________________________________
 From: Wenjie Lin <[email-masked]>
To: William Mills <[email-masked]> 
Cc: John Bradley <[email-masked]>; "[email-masked] ([email-masked])" <[email-masked]>; "Lee, David" <[email-masked]> 
Sent: Tuesday, February 21, 2012 12:07 PM
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

Our understanding is that you agree this is indeed a scope attack, that is, the user may get services, which are different than the client has agreed.
If the protocol adopts the change we’ve suggested, the client immediately figures out the difference between what he has agreed and what is in the access token. How does the client deal with it? Decline the service or take other actions? Indeed, as you rightly pointed out, it is an issue of operation – an excellent note for the implementer. However, this is no longer a protocol issue.
-W. Lin and D. Lee

-- 
Wenjie Lin

---

From: John Bradley <[email-masked]>
Date: Tue, 21 Feb 2012 18:59:44 -0300

Removing the unstopped response solves nothing , because the resource owner can revoke a scope at any time after granting it.  
Nothing forces the Authorization server to revoke the refresh or access token if a scope is revoked.  That is a implementation choice of the Authorization server.

This 'attack'  is one that only works with badly designed clients that are making unwarranted assumptions about the behaviour of the Authorization server.  

The only way for a client to know if a token has a scope it to try it, or use a introspection endpoint.  End of story.

John B.

---

From: Nicholas Devenish <[email-masked]>
Date: Tue, 21 Feb 2012 22:32:00 +0000

> This 'attack'  is one that only works with badly designed clients that are making unwarranted assumptions about the behaviour of the Authorization server.  

Unwarranted assumptions? The spec in 3.3 says:

"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."

- It says MUST; therefore any server that doesn't do this is non-compliant?
- It says scope different from the one requested by the *client*. The possibility that the resource owner intercepts this request and changes it doesn't seem to be considered here (it is not strictly the clients request if that happens)
- The purpose seems to be that the client should be told if the scope changes; this would be important if the client requires a certain scope level to work (though this could be solved more generally in many other ways that wouldn't be in the scope of the oauth spec)

Thus, assuming that the server is stating compliance, isn't the assumption completely warranted?

> The only way for a client to know if a token has a scope it to try it, or use a introspection endpoint.  End of story.

An introspection endpoint obviously isn't part of the specification, so isn't relevant to the discussion (though it solves the discussed facebook issue).

You are right though, that the only way for a client to know for sure is to try to use it; Even if the spec mandated always returning the scope to the client, the user could always intercept the return redirection (assuming a non-confidential client) and change the scope there.

Perhaps MUST should change to SHOULD, given that this essentially seems unenforceable?

---

From: John Bradley <[email-masked]>
Date: Tue, 21 Feb 2012 20:01:42 -0300

> Thus, assuming that the server is stating compliance, isn't the assumption completely warranted?

No the authorization server may at any time for any reason remove a scope from a granted access_token or refresh_token.   

Reporting back changes in scopes granted along with the access_token is a convenience not a security feature.  

Assuming it is a security feature and those scopes will continue to be valid for the token after granting is a bad design given the OAuth 2 spec.
> Perhaps MUST should change to SHOULD, given that this essentially seems unenforceable?

A SHOULD may lead people to the conclusion that it is secure.   I am happy with saying it is not secure the only want to know is to have the client be prepared to deal with tokens that do not contain the desired scope when used.   That is the only 100% solution.

John B.

---

From: André DeMarre <[email-masked]>
Date: Tue, 21 Feb 2012 16:38:46 -0800

The consensus seems to be, and I agree, that this shouldn't be
considered an "attack," but that's really just nomenclature. I do
concede that there is a spec issue here that I failed to appreciate at
first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued
access token scope is different from the one requested by the client,"
it suggests that the authorization server knows what was requested by
the client. That isn't strictly true; it only knows what was in the
authorization request, not who put it there. For the client to truly
know what the auth server wants, (1) it would need to communicate
directly with the client, (2) the client would need to preregister its
desired scope, or (3) the client would need to sign a message that the
user passes to the authorization endpoint. 1 and 3 are clearly not
compatible with the spec, 2 might be; but that's not the point.

A more correct statement in section 3.3 would be "If the issued access
token scope is different from the one in the authorization request..."

Regards,
Andre DeMarre

---

From: André DeMarre <[email-masked]>
Date: Tue, 21 Feb 2012 16:50:06 -0800

FWIW, it could be that the authorization request was authored by
neither the client nor the user. An unrelated fourth party can
construct an authorization endpoint URL using a client_id that isn't
his own and send a user there. This wasn't possible in OAuth 1 because
of how it used request tokens.

Regards,
Andre DeMarre

---

From: John Bradley <[email-masked]>
Date: Tue, 21 Feb 2012 21:59:25 -0300

Yes,  OpenID Connect deals with the issue by using a signed request extension in the cases where the client needs to be certain the request is only from the legitimate client and not tampered with.

As you observe anyone can send a request the client_id and redirect_uri are not secret in any way.   

Though a well behaved client should be using state to check for XSRF attacks. (that is a real attack)

Signed requests have uses,  but are not core to OAuth. 

John B.

---

From: Wenjie Lin <[email-masked]>
Date: Thu, 23 Feb 2012 15:55:14 -0800

We assume that the authorization server is trustworthy and won’t do
anything that violates the spec. We want to prevent attacks by the client
on the user, as well as the attacks by the user on the client.****

The scope attack is by the user on the client. From the point view of the
user it is not an attack. However, the client takes it as an attack; the
user violates the service agreement by the client who may have no knowledge
about it, unless the authorization server always sends him the authorized
scope information when granting an access token, as we've proposed, and the
client can figure out the difference/violation and decide how to deal with
it.****

** **

When the client identifies the difference between his specified scope and
that in the access token, he can choose to abort or continue the service,
or take other actions. This is an implementation issue and is beyond the
scope of OAuth. There are other possible anomalies from implementations,
such as revocation of the scope by the user. However, they are not well
specified in the current spec and we take them as an implementation rather
than a protocol issue.****

** **

There might be applications where the client would not perceive scope
attack as an attack if he could allow any changes of the service agreement
scope by the user. If OAuth were aimed for such clients only, it would
significantly limit the applicability of the protocol.

We appreciate the insightful discussions on how the client could check and
handle the scope differences and beyond. They are extremely helpful for the
implementers.

-W. Lin and D. Lee

On Tue, Feb 21, 2012 at 4:59 PM, John Bradley <[email-masked]> wrote:

> Yes,  OpenID Connect deals with the issue by using a signed request
> extension in the cases where the client needs to be certain the request is
> only from the legitimate client and not tampered with.
>
> >>>> This 'attack'  is one that only works with badly designed clients
> that are making unwarranted assumptions about the behaviour of the
> Authorization server.
> >>>
> >>> "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."
> >>>
> >>> - It says scope different from the one requested by the *client*. The
> possibility that the resource owner intercepts this request and changes it
> doesn't seem to be considered here (it is not strictly the clients request
> if that happens)
> >>> - The purpose seems to be that the client should be told if the scope
> changes; this would be important if the client requires a certain scope
> level to work (though this could be solved more generally in many other
> ways that wouldn't be in the scope of the oauth spec)
> >>>
> >> No the authorization server may at any time for any reason remove a
> scope from a granted access_token or refresh_token.
> >>
> >> Assuming it is a security feature and those scopes will continue to be
> valid for the token after granting is a bad design given the OAuth 2 spec.
> >>>
> >>>> The only way for a client to know if a token has a scope it to try
> it, or use a introspection endpoint.  End of story.
> >>>
> >>> An introspection endpoint obviously isn't part of the specification,
> so isn't relevant to the discussion (though it solves the discussed
> facebook issue).
> >>>
> >>> You are right though, that the only way for a client to know for sure
> is to try to use it; Even if the spec mandated always returning the scope
> to the client, the user could always intercept the return redirection
> (assuming a non-confidential client) and change the scope there.
> >>>
> >> A SHOULD may lead people to the conclusion that it is secure.   I am
> happy with saying it is not secure the only want to know is to have the
> client be prepared to deal with tokens that do not contain the desired
> scope when used.   That is the only 100% solution.
> >>
> >> John B.
> >>
> >>
> >>
> >>

-- 
Wenjie Lin

---

From: Phil Hunt <[email-masked]>
Date: Thu, 23 Feb 2012 16:10:53 -0800

I'm still not seeing how "user choice" can become an "attack"

While a user might hack the request or a phishing attempt might generate a link that requests an unusual scope combination, it shouldn't matter since the authorization server should allow the user to decline specific scopes if they want to / or the authorization server may choose to override specific combinations of scope.

The client has to be prepared to accept in all cases that it may not get what it asks for. It may for example be entirely refused. If the client doesn't get what it asked for then it can choose to generate an error to the user.

A common case is many apps will connect to social nets and request "ReadProfile" and "UpdateStatus". Yet the user might not want to grant "UpdateStatus". The client app has to handle this gracefully.

Finally scope is a right granted to the client for access to a resource -- not the other way around as your attack suggests.

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-02-23, at 3:55 PM, Wenjie Lin wrote:

> We assume that the authorization server is trustworthy and won’t do anything that violates the spec. We want to prevent attacks by the client on the user, as well as the attacks by the user on the client.
> 
> The scope attack is by the user on the client. From the point view of the user it is not an attack. However, the client takes it as an attack; the user violates the service agreement by the client who may have no knowledge about it, unless the authorization server always sends him the authorized scope information when granting an access token, as we've proposed, and the client can figure out the difference/violation and decide how to deal with it.
>  
> When the client identifies the difference between his specified scope and that in the access token, he can choose to abort or continue the service, or take other actions. This is an implementation issue and is beyond the scope of OAuth. There are other possible anomalies from implementations, such as revocation of the scope by the user. However, they are not well specified in the current spec and we take them as an implementation rather than a protocol issue.
>  
> There might be applications where the client would not perceive scope attack as an attack if he could allow any changes of the service agreement scope by the user. If OAuth were aimed for such clients only, it would significantly limit the applicability of the protocol. 
> 
> We appreciate the insightful discussions on how the client could check and handle the scope differences and beyond. They are extremely helpful for the implementers.
> 
> -W. Lin and D. Lee
>

---

From: Kristoph <[email-masked]>
Date: Thu, 23 Feb 2012 16:22:28 -0800

Privilege de-escalation is not an attack. Your argument comes down to "I can change something and no error is shown so it's an attack" but you've not actually shown any sort of negative consequence because, you know, there isn't one. 

]{

---

From: Wenjie Lin <[email-masked]>
Date: Thu, 23 Feb 2012 17:02:32 -0800

As we have shown in our Feb 17th email, the negative consequence is a
violation by the user of the service agreement, that is, the user is able
to play the game but the client cannot post messages on behalf of the user.*
***

*"Scope Attack*

post messages on User’s behalf, as originally agreed."

**

- W. Lin and D. Lee

On Thu, Feb 23, 2012 at 4:22 PM, Kristoph <[email-masked]> wrote:

> Privilege de-escalation is not an attack. Your argument comes down to "I
> can change something and no error is shown so it's an attack" but you've
> not actually shown any sort of negative consequence because, you know,
> there isn't one.
>
> ]{
>
> on the user, as well as the attacks by the user on the client.
> >
> > The scope attack is by the user on the client. From the point view of
> the user it is not an attack. However, the client takes it as an attack;
> the user violates the service agreement by the client who may have no
> knowledge about it, unless the authorization server always sends him the
> authorized scope information when granting an access token, as we've
> proposed, and the client can figure out the difference/violation and decide
> how to deal with it.
> >
> > When the client identifies the difference between his specified scope
> and that in the access token, he can choose to abort or continue the
> service, or take other actions. This is an implementation issue and is
> beyond the scope of OAuth. There are other possible anomalies from
> implementations, such as revocation of the scope by the user. However, they
> are not well specified in the current spec and we take them as an
> implementation rather than a protocol issue.
> >
> > We appreciate the insightful discussions on how the client could check
> and handle the scope differences and beyond. They are extremely helpful for
> the implementers.
> >
> > -W. Lin and D. Lee
> >
> > >>> "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."
> > >>>
> > >>> - It says scope different from the one requested by the *client*.
> The possibility that the resource owner intercepts this request and changes
> it doesn't seem to be considered here (it is not strictly the clients
> request if that happens)
> > >>> - The purpose seems to be that the client should be told if the
> scope changes; this would be important if the client requires a certain
> scope level to work (though this could be solved more generally in many
> other ways that wouldn't be in the scope of the oauth spec)
> > >>>
> > >> Assuming it is a security feature and those scopes will continue to
> be valid for the token after granting is a bad design given the OAuth 2
> spec.
> > >>>
> > >>> You are right though, that the only way for a client to know for
> sure is to try to use it; Even if the spec mandated always returning the
> scope to the client, the user could always intercept the return redirection

-- 
Wenjie Lin

---

From: Nicholas Devenish <[email-masked]>
Date: Fri, 24 Feb 2012 01:12:24 +0000

On 24 Feb 2012, at 01:02, Wenjie Lin wrote:

> As we have shown in our Feb 17th email, the negative consequence is a violation by the user of the service agreement, that is, the user is able to play the game but the client cannot post messages on behalf of the user.

That's not a negative within the context of the OAuth protocol, which protects the users interests, not the clients. It looks as though with the current wording, it's basically not possible to be compliant (very mildly) in this scenario.

But as John Bradley pointed out, it's completely legitimate for a client to give the "game" full permissions, and then edit the scope afterwards (though I can't find an explicit reference in the draft, I expect it to be covered by one of the "This is out of scope" or revocation clauses).

Implementations that want to allow clients to enforce the scope contract with the user could always just implement a method to get the actual scope back (like facebook), but it's not an attack against the protocol or user..

---

From: John Bradley <[email-masked]>
Date: Thu, 23 Feb 2012 22:33:22 -0300

In that case the game is the client as it is using the access token to get to the protected resource (FB graph API in this case).  The resource owner can revoke a granted scope at the authorization server after the fact.   That is how Facebook works now, as near as I can tell.

Not that Facebook is a good example of how OAuth should work,  They issue long lived access tokens and not refresh tokens.

A well behaved Authorization server would grant a refresh tokens with all of the granted scopes,  once the short lived access token expires it would get a new one and see that it had been downs coped from the original grant scope set.  

The correct design is using a refresh token.  that way if the user has edited the scopes on the way to the Authorization server the client just needs to use the refresh token with the scopes it believes were granted.
If it gets back a downs coped response it knows something has changed.

I have a hard time being sympathetic, because OAuth was not intended to enforce service agreements on behalf of the Client,  it is acting on behalf of the resource owner.

Enforcing multiparty service agreements should be a OAuth extension for those that want it.

John B.

---

From: Dan Taflin <[email-masked]>
Date: Fri, 24 Feb 2012 16:55:38 +0000

Thereby depriving the client of visibility on the social network. Yes, this is a hack, by the user, against the client, and there is material harm. The user is getting something without giving the client what was originally promised.

Of course, the client will quickly discover the hack, and could take whatever action it deems appropriate, such as shutting itself down with an error message. The question is, should the oauth protocol provide the client with the information up front by providing scope information along with the access token?

Dan

From: Wenjie Lin [mailto:[email-masked]]
Sent: Thursday, February 23, 2012 5:03 PM
To: Kristoph
Cc: Lee, David; [email-masked] ([email-masked])
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

"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."

- W. Lin and D. Lee

On Thu, Feb 23, 2012 at 4:22 PM, Kristoph <[email-masked]<mailto:[email-masked]>> wrote:
Privilege de-escalation is not an attack. Your argument comes down to "I can change something and no error is shown so it's an attack" but you've not actually shown any sort of negative consequence because, you know, there isn't one.

]{

On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote:

> We assume that the authorization server is trustworthy and won't do anything that violates the spec. We want to prevent attacks by the client on the user, as well as the attacks by the user on the client.
>
> On Tue, Feb 21, 2012 at 4:59 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
> > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Wenjie Lin