Definitely the latter. I don’t think the requirement actually helps secure things in practice and artificially limits things otherwise.
— Justin > On Jan 27, 2016, at 7:19 PM, Nat Sakimura <sakim...@gmail.com> wrote: > > You mean the string comparison on authority section would allow execution of > some code? Or are you suggesting that not checking the path portion would > allow the attacker to plant something on the other paths on the host? > > Yes, the later is possible especially when there are user generated content > on the same host, and if we are worried on it, we would have to do the > discovery. > > Nat > > 2016年1月28日(木) 5:45 Justin Richer <jric...@mit.edu <mailto:jric...@mit.edu>>: > Unless I’m missing something, requiring the authority section to match > discounts attackers being able to deploy executable code on a path. This kind > of hole was exploited in a number of Facebook hacks. Yes I’m aware that those > were dealing with redirect URIs but we’re talking about the same kind of > sub-component URI matching here, and I can only see it getting us into > trouble. > > — Justin > > >> On Jan 27, 2016, at 1:15 PM, Nat Sakimura <sakim...@gmail.com >> <mailto:sakim...@gmail.com>> wrote: >> >> yeah. >> >> But for Google, Microsoft, etc., every RP can whitelist, cannot they? ;-) >> >> Otherwise, for a code phishing attack, you need to implement discovery of >> some sort. My thinking before reading your email was: >> >> if( authority(authz_ep)==authority(token_ep) ) { >> get_token(token_ep, code, client_credential); >> } else { >> get_token(token_ep_from_discovery(), code, client_credential); >> } >> >> where token_ep_from_discovery() either returns the value of the >> toke_endpoint member from .well-known/openid-configuration OR the value of >> turi parameter in the query. >> >> 2016年1月28日(木) 2:03 Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>>: >> There's at least one smallish deployment that has a different authority for >> the Authorization Endpoint and the Token Endpoint. >> >> from https://accounts.google.com/.well-known/openid-configuration >> <https://accounts.google.com/.well-known/openid-configuration> : >> >> { >> "issuer": "https://accounts.google.com <https://accounts.google.com/>", >> "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth >> <https://accounts.google.com/o/oauth2/v2/auth>", >> "token_endpoint": "https://www.googleapis.com/oauth2/v4/token >> <https://www.googleapis.com/oauth2/v4/token>", >> "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo >> <https://www.googleapis.com/oauth2/v3/userinfo>", >> "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke >> <https://accounts.google.com/o/oauth2/revoke>", >> "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs >> <https://www.googleapis.com/oauth2/v3/certs>", >> ... >> } >> >> >> On Wed, Jan 27, 2016 at 6:30 AM, John Bradley <ve7...@ve7jtb.com >> <mailto:ve7...@ve7jtb.com>> wrote: >> It think requiring a common authority segment for the authorization endpoint >> and the token endpoint might work in common cases, but there are legitimate >> cases where the URI of the Authorization endpoint might be a alias in the >> case of multi tenants, all using a common token endpoint. >> >> The larger problem would be the RS, it is not uncommon to have the AS and RS >> in different domains, so with bearer tokens unless you make the same >> authority restriction for RS then you are not really stoping the attacker. >> They can get the AT by impersonating the RS. >> >> I think trying to enforce a common origin policy over OAuth would be a bad >> direction to go. >> >> I understand that it seems like a easy fix on the surface, and it works for >> most of the things people are using OAuth for today, but would be quite >> limiting over the long term. >> >> John B. >> > On Jan 27, 2016, at 7:31 AM, sakim...@gmail.com >> > <mailto:sakim...@gmail.com> wrote: >> > >> > Hi Hans, >> > >> > Sorry, I mixed up the IdP mix-up attack and the code phishing attack. >> > >> > Mandating the Authorization and Token Endpoint being in the same >> > authority would solve the later without changing the wire protocol. >> > >> > For AS mix-up attack, mandating the client to change the redirection >> > endpoint >> > per AS would solve the problem without change the wire protocol. >> > >> > If these are not possible, then we would have to look at changing the >> > wire protocol. The solution that solves the both cases must >> > provide the token endpoint URI authoritatively, which means >> > you have to mandate some variation of discovery mandatory. >> > >> > Nat >> > >> > >> > At 2016-01-27 17:01 Hans Zandbelt wrote: >> >> I don't see how that can deal with the specific form of the attack >> >> where the Client would have sent the authorization request to the >> >> legitimate authorization endpoint of a compromised AS and believes it >> >> gets the response from that, where in fact it was redirected away to >> >> the good AS. >> >> IOW, I don't think this is so much about mixing up endpoints where to >> >> send stuff to, but mixing up the entity/endpoint from which the Client >> >> believes the response was received. That may just be terminology >> >> though. >> >> Bottom line as far as I see is that a wire protocol element in the >> >> response is needed to tell the Client who issued it, regardless of how >> >> the Client deals with configuration of the AS information. >> >> Hans. >> >> On 1/27/16 1:31 AM, Nat Sakimura wrote: >> >>> So, is there a lot of cases that the authority section of the Good AS's >> >>> Authorization Endpoint and the Token Endpoints are different? >> >>> If not, then requiring that they are the same seems to virtually remove >> >>> the attack surface for the mix-up related attacks. It does not introduce >> >>> new parameter nor discovery. If it can be done, it probably is not worth >> >>> adding a new wire protocol element to mitigate the mix-up variants. >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> >> > https://www.ietf.org/mailman/listinfo/oauth >> > <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
