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