-----Original Message-----
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, September 14, 2011 7:26 AM
To: Eran Hammer-Lahav
Cc: Niv Steingarten; oauth@ietf.org
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:tors...@lodderstedt.net]
>> Sent: Wednesday, September 14, 2011 6:51 AM
>> To: Eran Hammer-Lahav
>> Cc: Niv Steingarten; oauth@ietf.org
>> 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
>>
>>
>>
