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