Yes redirect URI matching is a problem. In Connect we mandate an exact match because people are really bad at securing open relays. Trying to pattern match the redirect also allows an attacker to circumvent the fragment processing of the browser and generally increase the possible attack surface.
There is the state parameter that can be used to maintain a relay state at the client, there is no real need for anything other than an exact match. Anything other than an exact match on the registered redirect will lead to sadness due to the client inevitably being unclear on the pattern matching rules. John B. On 2013-05-17, at 9:06 PM, Antonio Sanso <asa...@adobe.com> wrote: > Hi *, > > > I was wondering what you thing about the second "issue" described (the > "Lassie come home"). > > I have encountered lately in one enterprise installation and I think is > fairly easy to make it wrong as well. > > Regards > > Antonio > > On May 17, 2013, at 5:46 PM, John Bradley wrote: > >> The implicit flow is secure in Connect, but we added a number of things to >> make it so. >> >> The reason to have it in OAuth 2 is for clients in the browser there are use >> cases for that and it allows the browser to receive and extract the token >> without passing it to a web server backend. >> Used as intended it is fine as the browser based JS App is receiving the the >> token directly over TLS so there is no substitution attack possible. >> >> The problem is when the client is not in the browser the browser itself is >> an attack surface, that an attacker can use to confuse a client. >> >> If people want to do SSO based on OAuth they need to follow the example of >> Google, PayPal and others who are implementing Connect rather than rolling >> there own protocol on top of OAuth 2. >> >> John B. >> >> >> On 2013-05-17, at 5:22 PM, Lewis Adam-CAL022 >> <adam.le...@motorolasolutions.com> wrote: >> >>> One wonders that - if in hindsight - the implicit flow was a mistake to >>> include in the framework. Yes it saves a single round trip for use cases >>> where the tokens are exposed to the UA, but it's not clear that >>> optimization is worth the security headaches that are going to be caused >>> down the road (or are already going on for that matter) by people using it >>> in scenarios where it should not be (because as stated, it is easier). >>> Probably would have been better to let the subset of cases that didn't need >>> the extra step of the code just go ahead and implement it anyway, and >>> ensure that the majority of native apps use cases would have been >>> implemented with better security. >>> >>> adam >>> >>> -----Original Message----- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >>> Richer, Justin P. >>> Sent: Wednesday, May 15, 2013 3:22 PM >>> To: Antonio Sanso >>> Cc: "WG <oauth@ietf.org>"@il06exr01.mot.com >>> Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks >>> >>> The biggest problem with this attack is the passing of the access token to >>> a backend server (and its subsequent passing of that token to someone else) >>> and the assumption that the presentation of the access token means that the >>> user is authenticated and present. It simply doesn't mean that, and this is >>> a bad assumption that unfortunately many people make thanks to providers >>> like Facebook using OAuth (or, mostly-OAuth since they're not actually RFC >>> compliant) in the authentication protocol. >>> >>> It's also a problem that so many people are using the implicit flow >>> "because it's easy", missing the point of why it's there in the first >>> place. The implicit flow is really only intended for cases where you can't >>> hide secrets from the user agent, cases like an in-browser application. The >>> flow diagrams that you have don't fit the implicit flow very well at all, >>> since the access token is getting passed back to some other service. >>> >>> -- Justin >>> >>> On May 13, 2013, at 11:14 AM, Antonio Sanso <asa...@adobe.com> >>> wrote: >>> >>>> Hi *, >>>> >>>> I wrote a blog post showing two well known OAuth related attacks. I paste >>>> here the link for your consideration: >>>> >>>> http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-devil-wears.html >>>> >>>> Any comment is more than appreciated. >>>> >>>> Regards >>>> >>>> Antonio >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> 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
