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

[Torsten Lodderstedt <[e-mail]>]

ok

regards,
Torsten.

On Wed, 14 Sep 2011 07:30:56 -0700, Eran Hammer-Lahav wrote:
> I suggest we address this particular scenario in the thread model 
> document.
>
> EHL
>
>> -----Original Message-----
>> From: Torsten Lodderstedt [mailto:[e-mail]]
>> Sent: Wednesday, September 14, 2011 7:26 AM
>> To: Eran Hammer-Lahav
>> Cc: Niv Steingarten; [e-mail]
>> Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> 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
>> >
>> >> -----Original Message-----
>> >> From: Torsten Lodderstedt [mailto:[e-mail]]
>> >> Sent: Wednesday, September 14, 2011 6:51 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Niv Steingarten; [e-mail]
>> >> 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.
>> >>
>> >> >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
>> >>
>> >>
>> >>