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 <wmi...@yahoo-inc.com>
To: Barry Leiba <barryle...@computer.org>; Anthony Nadalin
<tony...@microsoft.com>
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>; "e...@sled.com"
<e...@sled.com>
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 <barryle...@computer.org>
To: Anthony Nadalin <tony...@microsoft.com>
Cc: "e...@sled.com" <e...@sled.com>; "OAuth WG (oauth@ietf.org)"
<oauth@ietf.org>
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 <tony...@microsoft.com> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
