Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

[John Bradley <[e-mail]>]

Perhaps Frankenstein response is a better name than cut and paste attack.

John B.
On Jan 22, 2016 1:22 AM, "David Waite" <[e-mail]> wrote:

> On Jan 21, 2016, at 2:50 PM, John Bradley <[e-mail]> wrote:
>
> In that case you probably would put a hash of the state in the code to
> manage size.  The alg would be up to the AS, as long as it used the same
> hash both places it would work.
>
> Yes, true.
>
>
> Sending the state to the token endpoint is like having nonce and c_hash in
> the id_token, it binds the issued code to the browser instance.
>
> I think I understand what you are saying. Someone won’t be able to
> frankenstein up a state and a token from two different responses from an
> AS, and have a client successfully fetch an access token based on the
> amalgamation.
>
>
> This protects against codes that leak via redirect uri pattern matching.
> failures etc.  It prevents an attacker from being able to replay a code
> from a different browser.
>
> Yes, if a party intercepts the redirect_url, or the AS fails to enforce
> one time use (which even for a compliant implementation could just mean the
> attacker was faster than the state propagated within the AS)
>
> Makes sense. Thanks John.
>
> -DW
>
> If the client implements the other mitigations on the authorization
> endpoint, then it wouldn't be leaking the code via the token endpoint.
>
> The two mitigations are for different attacks, however some of the attacks
> combined both vulnerabilities.
>
> Sending the iss and client_id is enough to stop the confused client
> attacks, but sending state on its own would not have stopped all of them.
>
> We discussed having them in separate drafts, and may still do that.
> However for discussion having them in one document is I think better in the
> short run.
>
> John B.
>
> On Jan 21, 2016, at 4:48 PM, David Waite <[e-mail]>
> wrote:
>
> Question:
>
> I understand how “iss" helps mitigate this attack (client knows response
> was from the appropriate issuer and not an attack where the request was
> answered by another issuer).
>
> However, how does passing “state” on the authorization_code grant token
> request help once you have the above in place? Is this against some
> alternate flow of this attack I don’t see, or is it meant to mitigate some
> entirely separate attack?
>
> If one is attempting to work statelessly (e.g. your “state” parameter is
> actual state and not just a randomly generated value), a client would have
> always needed some way to differentiate which issuer the authorization_code
> grant token request would be sent to.
>
> However, if an AS was treating “code” as a token (for instance, encoding:
> client, user, consent time and approved scopes), the AS now has to include
> the client’s state as well. This would effectively double (likely more with
> encoding) the state sent in the authorization response back to the client
> redirect URL, adding more pressure against maximum URL sizes.
>
> -DW
>
>