Re: [OAUTH-WG] Another CSRF attack

[Hans Zandbelt <[e-mail]>]

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 <[e-mail]> 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
>
> > On May 5, 2016, at 10:13 AM, Daniel Fett <[e-mail]> wrote:
> >
> > 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. [phone] - H436
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
[image: Ping Identity logo] <https://www.pingidentity.com/>
Hans Zandbelt
Principal Solutions Architect
Ping Identity
------------------------------
[image: CIS 2016] <https://www.cloudidentitysummit.com/en/index.html>