Subject: [OAUTH-WG] Another CSRF attack

From: Daniel Fett <[email-masked]>
Date: Thu, 5 May 2016 16:13:47 +0200

We found another attack on session integrity (read: a CSRF attack).

This attack breaks the session integrity for clients that allow the use
of multiple AS where one AS might be malicious. It only works for
clients that do not use a session or cookie to track which AS a user
wanted to use when starting the OAuth flow. (We assume that such
clients, in lack of other options, use different redirection URIs for
the different AS.)

Let's call the malicious AS AIdP and the honest HIdP.

The attack works as follows: When a user wants to authorize using AIdP,
AIdP redirects the user back to the redirection URI of HIdP at the
client. AIdP attaches to this redirection URI the state issued by the
client, and a authorization code or access token obtained from HIdP. The
client then believes that the user logged in at HIdP. Hence, the user is
logged in at the client using the attacker's identity at HIdP or the
client accesses the attacker's resources at HIdP believing that these
resources are owned by the user.

This attack should also be applicable to OpenID Connect in all modes.

The obvious fix here is that RP should track in a session or cookie
where the user wanted to log in. Using different redirection URIs is not
sufficient.

Can anybody confirm this attack, and whether it was described before?

Cheers,
Daniel, Guido, Ralf

-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

---

From: Justin Richer <[email-masked]>
Date: Thu, 5 May 2016 14:50:27 -0400

I’ve not heard this attack spelled out like this, but I know that our client library was explicitly coded to prevent this by remembering the “issuer” of the outgoing request and tying that to the session and state value.

 — Justin

> On May 5, 2016, at 10:13 AM, Daniel Fett <[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 5 May 2016 23:00:48 +0200

Also, for OIDC the spec explicitly mentions about the state parameter:
"Typically,
Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by binding the
value of this parameter with a browser cookie" which is stronger that what
OAuth provides on its own; though it does not not explicitly mention to
store the issuer as part of that state, Clients would typically do that
using the same mechanism AFAICT.

Though this attack may not have been spelled out before, IMHO it falls out
of the previously described ones and sending the "state" to the token
endpoint was proposed to mitigate using stolen codes to impersonate users
whereas per-issuer redirect URIs which were proposed to prevent a code from
being stolen.

Hans.

On Thu, May 5, 2016 at 8:50 PM, Justin Richer <[email-masked]> wrote:

> I’ve not heard this attack spelled out like this, but I know that our
> client library was explicitly coded to prevent this by remembering the
> “issuer” of the outgoing request and tying that to the session and state
> value.
>
>  — Justin
>

-- 
 <https://www.pingidentity.com/>
Hans Zandbelt
Principal Solutions Architect
Ping Identity
------------------------------
 <https://www.cloudidentitysummit.com/en/index.html>