+1 ;)
On Fri, Jan 22, 2016 at 8:45 PM John Bradley <ve7...@ve7jtb.com> wrote:
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
<mailto: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
<mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
