With the mix up attack we assumed that the attacker is able to modify the
request. In that case checking nonce in the code flow is not sufficient as
the attacker can modify nonce.
In this attack the attacker as I understand it can only view request and
response, so checking nonce in code will prevent the paste of the code.
Unfortunately (Torsten) checking nonce in the code flow is optional.
What I don’t know is if there is a variation of the attack where the client
uses the attackers proxy and the attacker can modify the request.
One other mitigation is to use the Connect post response mode. That would stop
the code leak as long as the client is not going through the proxy.
Post response mode to stop referrer leaking etc is looking like a good idea in
general.
PKCE S256 still seems like the best idea. However if a browser is using a
malicious proxy that could also probably be circumvented.
Basically in that situation the attacker has access to cookies etc so OAuth may
not be the largest problem.
John B.
Sent from Mail for Windows 10
From: nov matake
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
