I agree, common origin mapping for OAuth would be a horrible road to go down. Pattern matching redirect URI has been a thorn in Facebook’s side that has never worked.
At best it would be security theatre, and cripple many legitimate use cases. John B. > On Jan 27, 2016, at 11:02 PM, Justin Richer <jric...@mit.edu> wrote: > > 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 >> <mailto: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> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
