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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
