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
