Not true. It is the same.

EHL

On Aug 14, 2011, at 1:55, "Phillip Hunt" 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

No. I don't think so. In the new variant the client has to check the returned 
state to confirm it has not changed or associated with a different user.

Previously the authz server had to do the checks.

Phil

On 2011-08-13, at 21:16, "William J. Mills" 
<<mailto:wmi...@yahoo-inc.com>wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>>
 wrote:

The defense is the same though, correct?

________________________________
From: Phil Hunt 
<<mailto:phil.h...@oracle.com>phil.h...@oracle.com<mailto:phil.h...@oracle.com>>
To: Eran Hammer-Lahav 
<<mailto:e...@hueniverse.com>e...@hueniverse.com<mailto:e...@hueniverse.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>>
Sent: Saturday, August 13, 2011 4:41 PM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

There are two CSRF variations scenarios that I see.

I can attack you and give my client access to your resources (original attack 
on the "resource").

I can attack you and give your client access to my resource (new attack on the 
"client").

Attack on the client vs. attack on the resource may be misleading here.  Draft 
20 only referred to attacks on the "resource" in its original CSRF description.

Phil

@independentid
<http://www.independentid.com><http://www.independentid.com>www.independentid.com<http://www.independentid.com>
<mailto:phil.h...@oracle.com><mailto:phil.h...@oracle.com>phil.h...@oracle.com<mailto:phil.h...@oracle.com>





On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote:

All OAuth CSRF attacks are on the client.

EHL

From: Phil Hunt 
<<mailto:phil.h...@oracle.com><mailto:phil.h...@oracle.com>phil.h...@oracle.com<mailto:phil.h...@oracle.com>>
Date: Sat, 13 Aug 2011 00:21:50 -0700
To: Torsten Lodderstedt 
<<mailto:tors...@lodderstedt.net><mailto:tors...@lodderstedt.net>tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>>
Cc: Eran Hammer-lahav 
<<mailto:e...@hueniverse.com><mailto:e...@hueniverse.com>e...@hueniverse.com<mailto:e...@hueniverse.com>>,
 "OAuth WG 
(<mailto:oauth@ietf.org><mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)"
 
<<mailto:oauth@ietf.org><mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

+1 (to putting more detail in the Threat Model document)

Yes, this is another CSRF attack (hence the change to 10.2).

What is *new* is this is an attack on the client application rather than the 
resource server. As such, I agree this new attack vector is well deserving of 
wider review and discussion before finalizing the draft.

Phil

@independentid
<http://www.independentid.com/><http://www.independentid.com>www.independentid.com<http://www.independentid.com>
<mailto:phil.h...@oracle.com><mailto:phil.h...@oracle.com>phil.h...@oracle.com<mailto:phil.h...@oracle.com>





On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote:



Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
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.

We are constantly facing the fact that a comprehensive description of security 
threats needs more space than we have in the core draft. That's the reason why 
the security document has 63 pages and that's also the reason why we decided to 
let the core spec refer to this document for in-depth explanations. This holds 
true for this threat as well.

regards,
Torsten.


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 
<<mailto:tony...@microsoft.com><mailto:tony...@microsoft.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG 
(<mailto:oauth@ietf.org><mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)"
 
<<mailto: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.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to