Perhaps Frankenstein response is a better name than cut and paste attack. John B. On Jan 22, 2016 1:22 AM, "David Waite" <da...@alkaline-solutions.com> wrote:
> On Jan 21, 2016, at 2:50 PM, John Bradley <ve7...@ve7jtb.com> 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 <da...@alkaline-solutions.com> > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
