Re: [OAUTH-WG] Auth Code Swap Attack

["William J. Mills" <[e-mail]>]

After thinking about this and getting on the phone with Eran, I think making "state" required isn't right (because we're dictating one solution/format to no real point), but CSRF protection *is* REQUIRED.  I also think that we're probably not sufficiently clear about which state parameter we're talking about, since we have 2, but that's a different question). The core of the problem described 
in the first message of this topic is a plain CSRF vulnerability of the 
redirect URI.  Alice's (our victim) browser visits the malicious 
redirect URI, presents her credential, and the bad thing happens.

I'm proposing a 3rd variant.  The original -20 text is included below, it's closer to where I think we should be.  This leans on a rather fuzzy-term "non-guessable" but I'm OK with it if no on else objects.



10.12.  Cross-Site Request Forgery

Cross-site request forgery (CSRF) 
is an attack whereby malicious URLs are sent to the user-agent of an end user (generally as hidden links or images) and transmitted from the 
user-agent the server trusts or has authenticated. The most commonly exploited mechanism for this is credentials held in cookies automatically presented by a web browser.  CSRF attacks against the client's redirection URI allow 
an attacker to inject their own authorization code or access token, 
which can result in the client using an access token associated with the attacker's account rather than the victim's.  CSRF 
attacks are also possible against an authorization endpoint.  

Client applications MUST implement CSRF protection for the redirection URI.  CSRF protection for a request is data included in the request that ties that request to the user's authenticated state, i.e. a cryptographic signature of the user credential and the redirection URI path.  Upon receipt of a request the client application computes the CSRF data based on the presented credential and compares that to the CSRF protection data presented in the request.  CSRF protection data MUST contain a non-guessable value, and the client MUST keep it in a 
location accessible only by the client or the user-agent (i.e., 
protected by same-origin policy). The "state" redirection URI parameter is provided as one method of carrying CSRF protection data, and is RECOMMENDEDto provide the greatest compatibility with systems implementing strong redirection URI validation.  


It is strongly RECOMMENDED that 
the client includes the "state" request parameter with authorization 
requests to the authorization server.  The "state" request parameter 
MUST contain a non-guessable value, and the client MUST keep it in a 
location accessible only by the client or the user-agent (i.e., 
protected by same-origin policy). 


For example, using a DOM variable, HTTP cookie, or HTML5 client-side 
storage.  The authorization server includes the value of the "state" 
parameter when redirecting the user-agent back to the client which MUST 
then ensure the received value matches the stored value. 




Original -20 text:


10.12.  Cross-Site Request Forgery

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated.  CSRF attacks on the authorization endpoint can allow an attacker to obtain authorization without the consent of the resource owner. 


The "state" request parameter SHOULD be used to mitigate against CSRF attacks, particularly for login CSRF attacks.  CSRF attacks against the client's redirection URI allow an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's account rather than the victim's.  Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. 


It is strongly RECOMMENDED that the client includes the "state" request parameter with authorization requests to the authorization server.  The "state" request parameter MUST contain a non-guessable value, and the client MUST keep it in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy). 


For example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.  The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client which MUST then ensure the received value matches the stored value. 



________________________________
From: William J. Mills <[e-mail]>
To: Barry Leiba <[e-mail]>; Anthony Nadalin <[e-mail]>
Cc: "OAuth WG ([e-mail])" <[e-mail]>; "[e-mail]" <[e-mail]>
Sent: Monday, August 15, 2011 10:07 AM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack


I'm a -1 on both of these until I re-read the attack description and really parse this again.  Perhaps I'm being confused by the usage of "client" here.  My initial reaction is that any time we are relying on the client to protect itself from CSRF it is a mistake.

I do think that CSRF protection is REQUIRED, the remaining question is whether it's reasonable to force folks to use the state parameter.  My gut says it's not unreasonable to force this simple model.


I also don't particularly like either CSRF description used.  As I've said before I think there are better discussions of it out there.

More later when I have more time to think on this.

-bill



________________________________
From: Barry Leiba <[e-mail]>
To: Anthony Nadalin <[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "OAuth WG ([e-mail])" <[e-mail]>
Sent: Monday, August 15, 2011 8:06 AM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

On Mon, Aug 15, 2011 at 10:51 AM, Anthony Nadalin <[e-mail]> wrote:
> That's nice, four people come up with text and you decide to use your text.
> Making state optional does nothing to fix the protocol issue, people will get
> this wrong and have. Our developers have been through this and agreed
> upon the text that was generated. They find the text in the current draft
> unacceptable and confusing and think that new text is acceptable.

I have to agree with what Tony says above.  The text proposed in his
message was agreed upon by several WG participants, and unless there's
some significant objection to it I think we should use it in the -21
version, subject to final WG review.

Barry, as chair
_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth