I described a similar attack at the meeting in Darmstadt. Using stolen state to inject code from a different session.
We were calling that the cut and paste attack. The proposed mitigation is ing the draft that Mike and I did. This was based on the attacker making a new request in a different user agent and using that state. In open redirectors draft we do talk about referrer leaking info, and methods to address that. Checking referrer is a weak protection at best, as that is easily faked in many circumstances. Are you saying that the proposed mitigation of the AS tying state to code is not sufficient? John B. > On Apr 22, 2016, at 9:20 AM, Daniel Fett <f...@uni-trier.de> wrote: > > Hi all, > > During our formal analysis of OAuth we found an attack that allows > CSRF. It is similar to the "code" leak described by Homakov in [1] and > therefore not really surprising. In this attack, the intention for an > attacker is to steal the "state" value instead of the "code" value. > > Setting: > > In the auth code grant, after authentication to the AS, the user is > redirected to some page on the Client. If this page leaks the > referrer, i.e., there is a link to the attacker's website or some > resource is loaded from the attacker, then the attacker can see not > only code but also state in the Referer header of the request. > > The fact that code can leak was described in [1]. Since code is > single-use, it might be already redeemed in most cases when it is sent > to the attacker. > > State, however, is not limited to a single use (by 6749 or others) and > therefore can be used by the attacker to mount a CSRF attack and > inject his own code into a (new) auth code grant. > > We suggest > a) making state single use, and > b) highlighting to developers the importance of non-leaky redirection > endpoints, and to this end > c) recommending the use of "referrer policies" [2] to mitigate such attacks. > > Could somebody confirm whether this attack is new? > > Cheers, > Daniel, Guido, and Ralf > > [1] http://homakov.blogspot.de/2014/02/how-i-hacked-github-again.html > [2] https://w3c.github.io/webappsec-referrer-policy/ > -- > Informationssicherheit und Kryptografie > Universität Trier - Tel. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
