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

[Torsten Lodderstedt <[e-mail]>]

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.

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

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

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

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.
>I still don't see the need to add the proposed section.

>EHL