The request to the auth endpoint is front channel, through a browser.
The request to the token endpoint is back channel, server-to-server.
These are very, very different attack surfaces. If an attacker has
access to and control of both channels, you're pretty hosed anyway and
OAuth (nor TLS, nor basically anything else I can think of) will help you.
The security model in OAuth comes from limiting the knowledge at each
part of the transaction and spreading the risk appropriately.
-- Justin
On 11/29/2012 04:43 PM, Ariel Barreiro wrote:
But so the protection of sending the SAME redirect_uri in both the
auth end point and token end point makes not much of a sense when
there is a registered URI, and if there's not, an attacker, as far as
I understood, can compromise both the request to the auth end point as
well as the token end point, so I would assume that it doesn't make
much sense either.
On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer <[email protected]
<mailto:[email protected]>> wrote:
So here's the breakdown of how the redirect uri works:
- If the client sends a redirect URI to the auth endpoint, and the
client has registered one or more redirect URIs, it MUST match one
of the redirect URIs it had registered. (for a soft definition of
"match" -- it can be prefix, or pattern, or exact string, so long
as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint,
and the client has either only registered one or the AS has some
notion of a "default" redirect URI, the AS will just use that one.
Now the part that seems to trip people up:
- If the client had sent a redirect URI to the auth endpoint, then
it MUST send the EXACT SAME redirect URI to the token endpoint.
This request is back-channel and protected with the client's
credentials.
- If the client did not send a redirect URI to the auth endpoint,
then it does NOT send a redirect URI to the token endpoint.
So here's where the protection comes in. If the attacker modifies
the request to the auth endpoint so that it has a different
redirect URI, then that redirect URI MUST match one that's
attached to the client_id in the request. Furthermore, the call to
the token endpoint to get the token MUST also contain that
modified redirect URI as well as any client credentials needed to
make the call. A "good" client will send a "good" redirect URI,
even if the code has been sent someplace else in the mean time.
Hope this clears things up,
-- Justin
On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
But isn't having a registered redirect URI on the authorization
end point enought to prevent this, why is it required to send the
redirect URI to the token end point if the previous method
prevents it?
I appreciate a lot your response but I am still finding it hard
to picture it, and, was in your explanation a modification to the
request URI?
On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <[email protected]
<mailto:[email protected]>> wrote:
A confidential client authenticates to the token endpoint
preventing an attacker from getting the token.
In the case of a public client if you get the code and
redirect URI then you can get the token. (Why confidential
clients are better than public ones)
Sending the redirect URI to the token endpoint protects the
client from the case where client A gets a code for user B
because the user logged into A and A is using the client ID
of client Z because it wants to impersonate user B at client
A. Client A pretending to be client Z can easily get the
code. However the redirect URI that the real client Z sends
will be different than the one the fake client Z used to get
code and the real client A won't be able to exchange the code
for a access token and be tricked into thinking that the
resource owner is the one presenting it the code.
That is the long explanation. The short one is unregistered
redirect URI are bad. Sending the redirect URI to the token
endpoint protects clients from becoming confused about the
presenter of the code.
Nothing is going to help a public client if someone
intercepts code.
John B.
On 2012-11-29, at 3:05 PM, Ariel Barreiro <[email protected]
<mailto:[email protected]>> wrote:
Still I can't see how to prevent the attack. I understand
that there is no redirection when requesting an access
token, however, the protocol requests the client to send the
redirect_uri to the token end point to validate it was the
same used in the authorization. If the authorization was
compromised, couldn't the access token request be forged as
well?
On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt
<[email protected] <mailto:[email protected]>> wrote:
There is no redirection when requesting an access token.
Token requests are typically out-of-band from the user.
The attack only happens during an authorization
redirect flow in the browser.
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
[email protected] <mailto:[email protected]>
On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:
> I am struggling a bit to understand this attack and
the advice in to how to prevent. I understand that if I,
as an attacker, can change the redirection uri when
authorizing, can not it as well change the redirect uri
when requesting an access token?
>
> Any explanation examples on how this attack might work
and how sending the redirect_uri when requesting the
access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=
> _______________________________________________
> OAuth mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
