Hi Antonio, Am 22.04.2016 um 16:30 schrieb Antonio Sanso: >> 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. > > probably is not redeemed instead, just because the redirect_uri is not the > correct one. > The mitigation that good implemented AS use (also Github) is to follow > section 4.1.3 the OAuth core specification [RFC6749], in particular: > > "ensure that the "redirect_uri" parameter is present if the "redirect_uri" > parameter was included in the initial authorization request as described in > Section 4.1.1, and if included ensure that their values are identical."
The attack is not based on a manipulation of the redirect_uri. Instead, a correct redirect_uri is used, but the page loaded from the redirect_uri contains links or external resources (intentionally or not). - Daniel -- Informationssicherheit und Kryptografie Universität Trier - Tel. 0651 201 2847 - H436 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
