Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

[Torsten Lodderstedt]

Hi Eran,

This is still just a CSRF attack.


I think you may be right. I still believe this particular style of attack on the
authorization server is worth mentioning, be it in its own separate section or
under the existing CSRF section (as you suggested).

This is not a style of attack but techniques to enhance other exploits, in this 
case, CSRF. If you lack CSRF protection, then yes, lack of resource owner 
forced interaction will make it easier to execute. But that's just a tiny speed 
bump considering the actual exploit.

I don't see any reason to include this new text based on this threat analysis.

However, this doesn't mean this discussion wasn't useful. We did identify the 
need to explicitly discuss CSRF attacks on the authorization endpoint. We need 
to explicitly separate the two target of CSRF attacks (client, server) because 
while the solution is the same, the implementation is very different (due to 
the use of redirections in one).


I agree, we should explicitely document these two variants of CSRF 
(client, authz server). But I suspect it's not only CSRF we are talking 
about in this thread - at least not textbook CSRF. Let me explain my 
thoughts:


As far as I understood, in a textbook CSRF attack the attacker would 
create his own requests in order to abuse a user's session. This can be 
prevented by utilizing standard CSRF coutermeasures (page token, nounce, 
signature as parameter on every request URL), which bind URLs to a 
certain session.


But why should the attacker create requests et all? All he needs is 
already provided by the authorization server themselves. The malicious 
client can download the HTML pages comprising the authorization flow 
from the authz server and use the embedded URLs to issue the requests 
which normaly would have been issued by the resource owner herself 
(using the use agent indeed). It's more or less the push on a "I agree" 
button we are talking about. The authorization server may add a page 
token to the respective form URL. But it does not matter since the 
client just uses the authz server manufactured URL to post the form.


So let's assume the attacker has to programmatically handle HTML forms 
the authorization server delivers to the user agent. As you correctly 
pointed out, the pre-requisite for such an attack to succeed is that the 
resource owner must be authenticated somehow, e.g. based on a session 
cookie. Which also means, we are talking about clients running on the 
victim's device, within the user agent or as native app.


I see the following possible scenarios:

1) external system browser - The app could utilize an existing session 
within the system browser on the victim's device. It could then remote 
control a browser window, e.g. using low-level operating system messages 
("send mouse click") or component techniques such as ActiveX. There are 
tools available to create macros which automatically control and obtain 
data from such applications. So this should be feasible.


2) internal browser (cross-browser cookies) - If the authorization 
server uses cross-browser cookie techniques, such as flash cookies, the 
attacker could instantiate an internal (invisible) browser and try to 
utilize a session associated with such a cookie. I assume controlling 
such a browser instance will be even simpler then in (1).


3) internal browser (silent authz flow) - This is a scenario where the 
attacker is unable to abuse an existing session on the device. It could 
instead create an internal browser and perform an authorization flow 
with the resource owner for one particular scope. Using the same browser 
instance and based on the cookies obtained in the first run, it could 
silently perform additional authorization flows for other scopes.


4) internal browser (non-interactive authentication methods) - There are 
authentication methods available w/o the need for user-interaction, for 
examples SIM card authentication or certificate-based authentication. 
The attacker could utilize an internal, invisible browser instance in 
combination with such an authentication method in order to perform the 
authorization process.


I'm not sure whether the scenarios described above can be classified as 
CSRF.


regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Auth Code Swap Attack

[Torsten Lodderstedt]

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] *On 
Behalf Of *Eran Hammer-Lahav

*Sent:* Monday, August 15, 2011 9:35 AM
*To:* OAuth WG (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 )
*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 >

*Date: *Fri, 12 Aug 2011 12:06:36 -0700
*To: *"OAuth WG (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-

Re: [OAUTH-WG] Auth Code Swap Attack

[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] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (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)
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 mailto:tony...@microsoft.com>>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (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

Re: [OAUTH-WG] Auth Code Swap Attack

[David Recordon]

So far Facebook has used `state` in examples within our documentation
and strongly recommend it but have not gone so far as to mandate it.

Quoting https://developers.facebook.com/docs/authentication/:
> Cross site request forgery is an attack in which an trusted (authenticated
> and authorized) user unknowingly performs an action on website. To prevent
> this attack, you should pass an identifier in the state parameter, and then
> validate the state parameter matches on the response. We strongly recommend
> that any app implementing Facebook user login implement CSRF protection using
> this mechanism.

I'd rather clearly document this in the spec, strongly recommend a
solution but not mandate this specific parameter.

--David


On Sun, Aug 21, 2011 at 12:02 PM, Eran Hammer-Lahav  wrote:
> 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] On Behalf Of
> Eran Hammer-Lahav
> Sent: Monday, August 15, 2011 9:35 AM
> To: OAuth WG (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)
> 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 
> Date: Fri, 12 Aug 2011 12:06:36 -0700
> To: "OAuth WG (oauth@ietf.org)" 
> Subject: [OAUTH-WG] Auth Code Swap Attack
>
>
>
>
>
>
>
> Recommended Changes to draf

Re: [OAUTH-WG] Auth Code Swap Attack

[Phil Hunt]

I think the complication here is that CSRF issues are multi-site issues where 
the attacker cross connecting his client with a victims resource, or a victims 
client with the attackers resource.

So while an individual site (e.g. Facebook) may presume little or no risk - 
there is a network effect here. A CSRF attacker could be using facebook to 
attack another site. See Yaron's original text about Plaxo/Live at the start of 
this thread.

Would it be reasonable to assess whether a resource site could make it 
mandatory based on a pre-registered client?  IOW, would Facebook want to make 
state mandatory for Confidential clients, but not public clients?

Would it be acceptable to change status from OPTIONAL to RECOMMENDED?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2011-08-21, at 6:10 PM, David Recordon wrote:

> So far Facebook has used `state` in examples within our documentation
> and strongly recommend it but have not gone so far as to mandate it.
> 
> Quoting https://developers.facebook.com/docs/authentication/:
>> Cross site request forgery is an attack in which an trusted (authenticated
>> and authorized) user unknowingly performs an action on website. To prevent
>> this attack, you should pass an identifier in the state parameter, and then
>> validate the state parameter matches on the response. We strongly recommend
>> that any app implementing Facebook user login implement CSRF protection using
>> this mechanism.
> 
> I'd rather clearly document this in the spec, strongly recommend a
> solution but not mandate this specific parameter.
> 
> --David
> 
> 
> On Sun, Aug 21, 2011 at 12:02 PM, Eran Hammer-Lahav  
> wrote:
>> 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] On Behalf Of
>> Eran Hammer-Lahav
>> Sent: Monday, August 15, 2011 9:35 AM
>> To: OAuth WG (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)
>> Subject: Re: 

Re: [OAUTH-WG] Auth Code Swap Attack

[Eran Hammer-Lahav]

> -Original Message-
> From: Phil Hunt [mailto:phil.h...@oracle.com]
> Sent: Sunday, August 21, 2011 10:39 PM
> To: David Recordon
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Auth Code Swap Attack
> 
> I think the complication here is that CSRF issues are multi-site issues where
> the attacker cross connecting his client with a victims resource, or a victims
> client with the attackers resource.
> 
> So while an individual site (e.g. Facebook) may presume little or no risk -
> there is a network effect here. A CSRF attacker could be using facebook to
> attack another site. See Yaron's original text about Plaxo/Live at the start 
> of
> this thread.

It's still just a CSRF attack.
 
> Would it be reasonable to assess whether a resource site could make it
> mandatory based on a pre-registered client?  IOW, would Facebook want to
> make state mandatory for Confidential clients, but not public clients?

That's irrelevant. The authorization server has absolutely no way of verifying 
if the client is implementing a CSRF protection properly. Making 'state' 
required does not accomplish such an enforcement. A client can pass the 
proposed text requirement with "state=ni".

> Would it be acceptable to change status from OPTIONAL to RECOMMENDED?

Parameters are either required or optional. We can makes it optional and 
recommended for a particular purpose which is consistent with the existing text.

It should be mandatory to implement CSRF protection. We agree on that and 
should add it to the text. We also agree that 'state' is a great way of 
implementing it and should recommend it. We already do that in the security 
consideration section and can enhance that when defining the 'state' parameter.

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