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

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

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