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
