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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > > > > > > > > -- > > Wenjie Lin > > _______________________________________________ > > 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
