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

[Wenjie Lin <[e-mail]>]

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*

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 <[e-mail]> 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.
> >
> > 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 <[e-mail]> 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.
> >
> > 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.
> > On 2012-02-21, at 9:38 PM, André DeMarre wrote:
> >
> > > 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
> > >
> > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <[e-mail]>
> wrote:
> > >>
> > >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote:
> > >>
> > >>>
> > >>> On 21 Feb 2012, at 21:59, John Bradley wrote:
> > >>>> 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?
> > >>
> > >> 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.
> > >>>
> > >>>> 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?
> > >>
> > >> 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.
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >>
> >
> >
> >
> >
> > --
> > Wenjie Lin
> > _______________________________________________
> > 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