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

[Eran Hammer-Lahav <[e-mail]>]

Sorry for the late response.

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[e-mail]]
> Sent: Sunday, August 21, 2011 10:59 AM
> To: Eran Hammer-Lahav
> Cc: Niv Steingarten; [e-mail]
> 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