Inline > On Apr 25, 2016, at 6:01 AM, Daniel Fett <[email protected]> wrote: > > Am 24.04.2016 um 22:31 schrieb John Bradley: >> 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. > > Note that we do not propose checking the referrer as a mitigation; we > propose using the referrer policy (at the client) to suppress the > referrer (just as in the open redirector draft where it is used at the > AS). So the recommendation here is to use the referrer policy also at > the client.
OK thai is inline with what we recommend in sec 2.3 of https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 That document is mostly about redirectors on AS. More needs to go into it on the issue for clients. > >> Are you saying that the proposed mitigation of the AS tying state to code is >> not sufficient? > > Yes, it is not sufficient as an attacker can request a new code for his > own account at the AS for the same state. > So the attacker gets the leaked state then uses there own browser with the stolen to get a new code in there browser. Than takes the new code and old state and pastes that into a XSRF attack in the users browser. (Sort of the reverse of stealing a leaked code and presenting to the client in the the attackers browser with a new state) I see how the mitigation of tying state and code together would not work for that. However a client using PKCE would not be vulnerable as a side effect of using a different PKCE challenge for each request though a asymmetric PKCE challenge would not have this property. OK I will grant you that leaking state and using that in a XSRF with a different code to bind and attackers resource to the account is a new twist. John B. > (Note that from draft-bradley-oauth-jwt-encoded-state-05 it does not > become clear how the JTI value comes into play here; you should probably > add some clarification on generating this value and how to check it. An > example would be good.) > > -Daniel > > -- > Informationssicherheit und Kryptografie > Universität Trier - Tel. 0651 201 2847 - H436 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
