Your attack only works if the bad client can make a request to the token
endpoint with that code, which is only true if it's either a public
client with no secret or the bad client has stolen the secret from the
good client. In the latter case, you need to revoke and re-register your
'good' client at the server.
And the network paths are very different. One uses HTTP 302's through a
browser, which is outside the control of the client. The other uses
direct HTTP calls to the auth server, no browser. The latter is a much
harder target to crack, especially with client credentials on the line.
-- Justin
On 11/30/2012 09:19 AM, Ariel Barreiro wrote:
But when we are talking of redirection URI manipulation, are we
talking of compromising the server or some place in the networking
route in which the request_uri can be changed or we are talking of a
compromise in the user browser?
When I think of redirection URI manipulation, I would think that I
would chnge the redirect_uri, so that the authorization code is sent
somwhere else. If that's the case, then wherever the authorization
code is received, it can be used to request a token from that place
and that seems perfectly possible, always talking with unregistered
redirect_uris
On Fri, Nov 30, 2012 at 12:07 PM, John Bradley <[email protected]
<mailto:[email protected]>> wrote:
The client in the is case is a server. The front channel involves
making indirect connection through the user agent.
The back channel is a direct TLS protected server to server
communication without the users browser in the path.
John B.
On 2012-11-29, at 7:01 PM, Ariel Barreiro <[email protected]
<mailto:[email protected]>> wrote:
Aha, maybe that's the bit that I didn't understand that good
then... front channel and back channel, although I can see
difference I am not quite sure of how is it different on the
implementation
Client request to the auth end point is through a browser...
fine, you send the redirect uri. After authenticating you get
back to the redirect_uri with the auth code.
Isn't it the client, again, with the auth code, the one that
initiates the request to the token end point? I see no different
channel on the requests.
On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer <[email protected]
<mailto:[email protected]>> wrote:
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
