Hi Guido,
do I get it right. The attacker is supposed to use the state value in
order to overwrite the user agent's session state?
best regards,
Torsten.
Am 23.04.2016 um 12:47 schrieb Guido Schmitz:
Hi Torsten,
as the state value is supposed to protect the user agent's session
against CSRF attacks, an attacker can use the leaked state value to
perform a CSRF attack against this user agent.
The attacker can, for example, redirect the user agent to the client's
redirection endpoint (again) and by this, overwrite the previously
performed authorization. When the client then contacts some RS (in the
context of the user under attack), it may use an access token linked to
the attacker's account (instead of an access token linked to the user's
account) at the RS. The effects of such an attack are similar to a
session swapping attack. The attacker does not need to access the
session context directly (which may bound to the user agent), as he
instructs the correct user agent to perform these actions.
- Guido
On 22.04.2016 19:07, tors...@lodderstedt.net wrote:
Hi Daniel,
how is the attackers supposed to utilise the leaked state value? I would
assume the legit client binds it to a certain user agent, e.g. via the
session context, which is not available to the attacker.
best regards,
Torsten.
-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] State Leakage Attack
Von: Daniel Fett <f...@uni-trier.de>
An: Antonio Sanso <asa...@adobe.com>
Cc: Guido Schmitz <gschm...@informatik.uni-trier.de>,oauth@ietf.org,Ralf
Kuesters <kuest...@uni-trier.de>
Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
hi Daniel
On Apr 22, 2016, at 4:35 PM, Daniel Fett <f...@uni-trier.de
<mailto:f...@uni-trier.de>> wrote:
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).
right. so is not really [1] :) since there there is manipulation using
/../../
Of course.
Now the real question why a legit redirect_uri should contain links to
malicious external resources?
Well, why not? :)
Anyway, developers should be made aware that having external
resources/links on these pages is a bad idea.
- 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
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
