making CSRF prevention a MUST and recommending the state parameter as
implementation pattern is ok with me.
regards,
Torsten.
Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:
I light to the recent discussion, do you still feel that changing
'state' from optional to required is the best approach?
EHL
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Sunday, August 21, 2011 11:04 AM
*To:* Eran Hammer-Lahav
*Cc:* OAuth WG (oauth@ietf.org)
*Subject:* Re: [OAUTH-WG] Auth Code Swap Attack
My intention is to require clients to implement CSRF prevention. I
thought making the state parameter mandatory would be the
straightforward way.
regards,
Torsten.
Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:
I would like to hear from the other 3 authors of the proposed change
about their reasons for changing the use of 'state' from recommended
to required for CSRF prevention. It would also help moving this issue
forward if the 4 authors can provide answers or clarifications on the
issues raised below.
Assuming we can count all 4 authors are in favor of making the change,
I believe we have a tie (4:4) and therefore no consensus for making it
(as of this point). However, we did identify issues with the section's
language and clarity which we should address either way.
To clarify -- I am not proposing we close this issue just yet.
EHL
*From:*oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] *On Behalf Of *Eran Hammer-Lahav
*Sent:* Monday, August 15, 2011 9:35 AM
*To:* OAuth WG (oauth@ietf.org <mailto:oauth@ietf.org>)
*Subject:* Re: [OAUTH-WG] Auth Code Swap Attack
To demonstrate why making state required as proposed isn't very
helpful, here is an incomplete list of other requirements needed to
make an effective CSRF:
* State value must not be empty (a common bug in many implementations
using simple value comparison).
* 'Non-guessable' isn't sufficient as most developers will simply use
a hash of the session cookie, with or without salt which isn't
sufficient. We use "cannot be generated, modified, or guessed to
produce valid values" elsewhere in the document, but this is much
easier to get right for access tokens and refresh tokens than CSRF
tokens which are often just some algorithm on top of the session cookie.
* State CSRF value should be short-lived or based on a short-lived
session cookie to prevent the use of a leaked state value in multiple
attacks on the same user session once the leak is no longer viable.
In addition, this is not what "state" was originally intended for. If
the working group decides to mandate a CSRF parameter, it should
probably be a new parameter with a more appropriate name (e.g.
'csrf'). By forcing clients to use "state" for this purpose,
developers will need to use dynamic queries for other state
information which further reduces the security of the protocol (as the
draft recommends not using dynamic callback query components).
Encoding both CSRF tokens and other state information can be
non-intuitive or complicated for some developers/platforms.
EHL
*From:*Eran Hammer-Lahav
*Sent:* Friday, August 12, 2011 2:53 PM
*To:* Anthony Nadalin; OAuth WG (oauth@ietf.org <mailto:oauth@ietf.org>)
*Subject:* Re: [OAUTH-WG] Auth Code Swap Attack
This is really just a flavor of CSRF attacks. I have no objections to
better documenting it (though I feel the current text is already
sufficient), but we can't realistically expect to identify and close
every possible browser-based attack. A new one is invented every other
week.
The problem with this text is that developers who do no understand
CSRF attacks are not likely to implement it correctly with this
information. Those who understand it do not need the extra verbiage
which is more confusing than helpful.
As for the new requirements, they are insufficient to actually
accomplish what the authors propose without additional requirements on
state local storage and verification to complete the flow. Also, the
proposed text needs clarifications as noted below.
*From: *Anthony Nadalin <tony...@microsoft.com
<mailto:tony...@microsoft.com>>
*Date: *Fri, 12 Aug 2011 12:06:36 -0700
*To: *"OAuth WG (oauth@ietf.org <mailto:oauth@ietf.org>)"
<oauth@ietf.org <mailto:oauth@ietf.org>>
*Subject: *[OAUTH-WG] Auth Code Swap Attack
*Recommended Changes to draft-ietf-oauth-v2*
In section 4, request options (e.g. 4.1.1) featuring "state"
should change from:
state
OPTIONAL. An opaque value used by the client to maintain state
between the request and callback. The authorization server
includes this value when redirecting the user-agent back to the
client.
to:
state
REQUIRED. An opaque value used by the client to maintain state
between the request and callback. The authorization server
includes this value when redirecting the user-agent back to the
client. The encoded value SHOULD enable the client application to
determine the user-context that was active at the time of the
request (see section 10.12). The value MUST NOT be guessable or
predictable, and MUST be kept confidential.
Making the parameter required without making its usage required (I.e.
"value SHOULD enable") accomplishes nothing. Also, what does "MUST be
kept confidential" mean? Confidential from what? Why specify an
"encoded value"?
Section 10.12 Cross-Site Request Forgery
Change to:
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
enable the attacker to intermix the attacker's security context
with that of the resource owner resulting in a compromise of
either the resource server or of the client application itself. In
the OAuth context, such attacks allow an attacker to inject their
own authorization code or access token into a client, 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.
In order to prevent such attacks, the client application MUST
encode a non-guessable, confidential end-user artifact and submit
as the "state" parameter to authorization and access token
requests to the authorization server. The client MUST keep the
state value 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.
Upon receiving a redirect, the client application MUST confirm
that returned value of "state" corresponds to the state value of
the user-agent's user session. If the end-user session represents
an authenticated user-identity, the client MUST ensure that the
user-identity has NOT changed.
The above text uses 'user-context' and this 'user-identity'. Neither
term is defined.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
