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]> 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]> 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]> 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]> 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]> 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]> 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]>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 >>>>> [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] >>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
