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

[Torsten Lodderstedt <[e-mail]>]

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.