Re: [OAUTH-WG] State Leakage Attack

[John Bradley <[e-mail]>]

Inline
> On Apr 25, 2016, at 6:01 AM, Daniel Fett <[e-mail]> 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. [phone] - H436