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 protected]> 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. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
