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

[Torsten Lodderstedt <[e-mail]>]

no comments?

Am 21.08.2011 19:59, schrieb 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth