no comments?
Am 21.08.2011 19:59, schrieb Torsten Lodderstedt:
Hi Eran,
This is still just a CSRF attack.
I think you may be right. I still believe this particular style of
attack on the
authorization server is worth mentioning, be it in its own separate
section or
under the existing CSRF section (as you suggested).
This is not a style of attack but techniques to enhance other
exploits, in this case, CSRF. If you lack CSRF protection, then yes,
lack of resource owner forced interaction will make it easier to
execute. But that's just a tiny speed bump considering the actual
exploit.
I don't see any reason to include this new text based on this threat
analysis.
However, this doesn't mean this discussion wasn't useful. We did
identify the need to explicitly discuss CSRF attacks on the
authorization endpoint. We need to explicitly separate the two target
of CSRF attacks (client, server) because while the solution is the
same, the implementation is very different (due to the use of
redirections in one).
I agree, we should explicitely document these two variants of CSRF
(client, authz server). But I suspect it's not only CSRF we are
talking about in this thread - at least not textbook CSRF. Let me
explain my thoughts:
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.
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.
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.
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
