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

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 4 Sep 2011 15:04:14 -0700

Sorry for the late response.

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Sunday, August 21, 2011 10:59 AM
> To: Eran Hammer-Lahav
> Cc: Niv Steingarten; [email-masked]
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> 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.

A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through.

To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify.

> 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.

Of course it matters.

The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session.

> 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.

I'm having a hard time following all these scenarios. But the important part is that OAuth assumes the 'user-agent' is a compliant and secure web browser. If the user-agent does not enforce cookie boundaries, XSS, CORS policy, etc. there isn't much we can do. In other words, if the user installs a poorly design native application which has its own user-agent implementation opened to known web attacks, all bets are off.

The security model behind all these is pretty simple. The active user session has to be protected from any external access by attackers and enforce same-origin policy.

I still don't see the need to add the proposed section.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Sep 2011 15:50:39 +0200

Hi Eran,

>A textbook CSRF attack is when an attacker constructs a URI and then 
> manipulate a user-agent with an active session to call that. In the 
> simplest example, an >attacker constructs a URI that transfers a 
> million dollars from the current account to its, then tricks the user 
> to click on that link or automatically >redirects the user to that URI. 
> Because the user is already signed in and has an active session token, 
> the request goes through.

>To prevent it, the request URI must include an artifact that binds the 
> request to the active session. Since the attacker has no way of 
> accessing the session >information, it cannot construct as a URI. In 
> practice, this means adding a hidden form parameter to the button with 
> some hash of the session information >that the server can verify.

So I would conclude we have the same understanding of what CSRF means.

>The only way the attacker can get access is by calling the 'I agree' 
> button action via an active user session. The attacker cannot access 
> the hidden form >value with the session hash (or whatever the server is 
> using for CSRF protection). So whatever URI it constructs will not work 
> when called with the active >user session.

My point is: the attacker in the threat I'm trying to describe does not 
need to create any URL since it just remote controls the user-agent. The 
malicous code runs outside of the browser and "just" uses the URLs 
provided by the authz server. Yes, there need to be a session. No, the 
attacker does not need to inject any URL he made up.

>I'm having a hard time following all these scenarios. But the 
> important part is that OAuth assumes the 'user-agent' is a compliant 
> and secure web browser. If >the user-agent does not enforce cookie 
> boundaries, XSS, CORS policy, etc. there isn't much we can do. In other 
> words, if the user installs a poorly design >native application which 
> has its own user-agent implementation opened to known web attacks, all 
> bets are off.
>
>The security model behind all these is pretty simple. The active user 
> session has to be protected from any external access by attackers and 
> enforce same-origin policy.

What didn't you understand? I would be happy to improve my description. 
What I basically try to get across: a malicious piece of software 
running on the resource owners device can simulate her consent. As a 
pre-requisite the attacker must be able to either abuse an existing 
session or to create a new one. I gave four examples of how this could 
be achieved. At least the last has obviously nothing to do with browser 
security features. The threat also has nothing to do with poor design or 
user-agent implementation flaws. It is a deliberate attack against the 
resource owner.

One could argue that prevention of malicous software is not the 
responsibility of the authz server. I could agree with that. But people 
seem to expect an OAuth authz server to cope with such attacks. That's 
why I believe we either clearly draw this boundary in the spec or give a 
hint on how to prevent this kind of threat.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 14 Sep 2011 06:59:47 -0700

Is this malicious piece of software external a native application either past of a native client or external to the browser?

EHL

> Sent: Wednesday, September 14, 2011 6:51 AM
> To: Eran Hammer-Lahav
> Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> Hi Eran,
> 
> >> 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.
> 
> >Of course it matters.
> 
> My point is: the attacker in the threat I'm trying to describe does not need to
> create any URL since it just remote controls the user-agent. The malicous
> code runs outside of the browser and "just" uses the URLs provided by the
> authz server. Yes, there need to be a session. No, the attacker does not
> need to inject any URL he made up.
> 
> >> 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.
> >>
> >> 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.
> >> 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.
> 
> What I basically try to get across: a malicious piece of software running on the
> resource owners device can simulate her consent. As a pre-requisite the
> attacker must be able to either abuse an existing session or to create a new
> one. I gave four examples of how this could be achieved. At least the last has
> obviously nothing to do with browser security features. The threat also has
> nothing to do with poor design or user-agent implementation flaws. It is a
> deliberate attack against the resource owner.
> 
> responsibility of the authz server. I could agree with that. But people seem to
> expect an OAuth authz server to cope with such attacks. That's why I believe
> we either clearly draw this boundary in the spec or give a hint on how to
> prevent this kind of threat.
> 
> regards,
> Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Sep 2011 16:25:34 +0200

It is a native app and it is external wrt the browser.

regards,
Torsten.

On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote:
> Is this malicious piece of software external a native application
> either past of a native client or external to the browser?
>
> EHL
>
>> running on the

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 14 Sep 2011 07:30:56 -0700

I suggest we address this particular scenario in the thread model document.

EHL

> Sent: Wednesday, September 14, 2011 7:26 AM
> To: Eran Hammer-Lahav
> >> My point is: the attacker in the threat I'm trying to describe does
> >> not need to create any URL since it just remote controls the
> >> user-agent. The malicous code runs outside of the browser and "just"
> >> uses the URLs provided by the authz server. Yes, there need to be a
> >> session. No, the attacker does not need to inject any URL he made up.
> >>
> >> session or to create a new one. I gave four examples of how this
> >> could be achieved. At least the last has obviously nothing to do with
> >> browser security features. The threat also has nothing to do with
> >> poor design or user-agent implementation flaws.
> >> It is a
> >> responsibility of the authz server. I could agree with that. But
> >> people seem to expect an OAuth authz server to cope with such
> >> attacks. That's why I believe we either clearly draw this boundary in
> >> the spec or give a hint on how to prevent this kind of threat.
> >>
> >> regards,
> >> Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Sep 2011 16:39:47 +0200

ok

regards,
Torsten.

On Wed, 14 Sep 2011 07:30:56 -0700, Eran Hammer-Lahav wrote:
>> >> >> create his own requests in order to abuse a user's session. 
>> This
>> >> can
>> >> >> nounce, signature as parameter on every request URL), which 
>> bind
>> >> URLs
>> >> >> to a certain session.
>> >>
>> >> >to click on that link or automatically >redirects the user to 
>> that
>> >> URI.
>> >> >To prevent it, the request URI must include an artifact that 
>> binds
>> >> the
>> >> >accessing the session >information, it cannot construct as a 
>> URI.
>> >> In
>> >> >practice, this means adding a hidden form parameter to the 
>> button
>> >> with
>> >> >> But why should the attacker create requests et all? All he 
>> needs
>> >> is
>> >> >> button we are talking about. The authorization server may add 
>> a
>> >> page
>> >> >using for CSRF protection). So whatever URI it constructs will 
>> not
>> >> work
>> >> >> system messages ("send mouse click") or component techniques 
>> such
>> >> as
>> >> >> automatically control and obtain data from such applications. 
>> So
>> >> this
>> >> >> should be feasible.
>> >> >>
>> >> >> controlling such a browser instance will be even simpler then 
>> in
>> >> (1).
>> >> >>
>> >> >> flow with the resource owner for one particular scope. Using 
>> the
>> >> same
>> >> >> browser instance and based on the cookies obtained in the 
>> first
>> >> run,
>> >> >boundaries, XSS, CORS policy, etc. there isn't much we can do. 
>> In
>> >> other
>> >> >has its own user-agent implementation opened to known web 
>> attacks,
>> >> all
>> >> >bets are off.
>> >> >
>> >> >session has to be protected from any external access by 
>> attackers
>> >> and