http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html I think we're pretty good, the ones I worry about is relative urls in redirect URI checks i.e. "http://cloud.com/provisioned/good-site/../hacker-site" I'll log a bug for this if you agree that relative redirect URLs shouldn't be allowed. (Those containing "." and "..") Another really dangerous thing that we do is have full-scope-allowed set to true by default. If a rogue client gets registered, they pretty much have access to every single application the user can access with all of their privileges.

I agree we shouldn't allow relative redirect URLs. We should also improve our wildcard matching to only allow one level, for example: http://www.site.com/a/* Should match: http://www.site.com/a/page.html But not: http://www.site.com/a/b/page.html

We don't check the redirect_uri in the access token request either. I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that. ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 8 January, 2015 2:31:59 AM > Subject: Re: [keycloak-dev] oauth vulnerabilities > > Read this one, specifically that attack on github (you have to scroll > down a bit): > > http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html > > wildcard redirect uri patterns are pretty scary! > > On 1/7/2015 8:14 PM, Bill Burke wrote: >> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html >> >> I think we're pretty good, the ones I worry about is relative urls in >> redirect URI checks i.e. >> >> "http://cloud.com/provisioned/good-site/../hacker-site" >> >> I'll log a bug for this if you agree that relative redirect URLs >> shouldn't be allowed. (Those containing "." and "..") >> >> Another really dangerous thing that we do is have full-scope-allowed set >> to true by default. If a rogue client gets registered, they pretty much >> have access to every single application the user can access with all of >> their privileges. >> > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I agree we shouldn't allow relative redirect URLs. We should also improve our wildcard matching to only allow one level, for example: http://www.site.com/a/* Should match: http://www.site.com/a/page.html But not: http://www.site.com/a/b/page.html We don't check the redirect_uri in the access token request either. I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that. ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 8 January, 2015 2:31:59 AM > Subject: Re: [keycloak-dev] oauth vulnerabilities > > Read this one, specifically that attack on github (you have to scroll > down a bit): > > http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html > > wildcard redirect uri patterns are pretty scary! > > On 1/7/2015 8:14 PM, Bill Burke wrote: >> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html >> >> I think we're pretty good, the ones I worry about is relative urls in >> redirect URI checks i.e. >> >> "http://cloud.com/provisioned/good-site/../hacker-site" >> >> I'll log a bug for this if you agree that relative redirect URLs >> shouldn't be allowed. (Those containing "." and "..") >> >> Another really dangerous thing that we do is have full-scope-allowed set >> to true by default. If a rogue client gets registered, they pretty much >> have access to every single application the user can access with all of >> their privileges. >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

+1 for support multiple levels. One thing I am not sure is disable "Full scope allowed" by default. Disabling it will improve security a bit, but it's also not backward compatible. And I reckon if we disable it, there might be bunch of questions on keycloak-user like "My rest applications, which worked on 1.0 don't work on anymore" ;-) Marek On 14.1.2015 19:14, Bill Burke wrote: > I disagree. Wildcard should be able to match multiple levels. For > complex sites it would get really tedious otherwise. (and not backward > compatible for what we currently have). > > On 1/14/2015 3:41 AM, Stian Thorgersen wrote: >> I agree we shouldn't allow relative redirect URLs. >> >> We should also improve our wildcard matching to only allow one level, >> for example: >> >> http://www.site.com/a/* >> >> Should match: >> >> http://www.site.com/a/page.html >> >> But not: >> >> http://www.site.com/a/b/page.html >> >> We don't check the redirect_uri in the access token request either. >> I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that. >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Thursday, 8 January, 2015 2:31:59 AM >>> Subject: Re: [keycloak-dev] oauth vulnerabilities >>> >>> Read this one, specifically that attack on github (you have to scroll >>> down a bit): >>> >>> http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html >>> >>> wildcard redirect uri patterns are pretty scary! >>> >>> On 1/7/2015 8:14 PM, Bill Burke wrote: >>>> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html >>>> >>>> >>>> I think we're pretty good, the ones I worry about is relative urls in >>>> redirect URI checks i.e. >>>> >>>> "http://cloud.com/provisioned/good-site/../hacker-site" >>>> >>>> I'll log a bug for this if you agree that relative redirect URLs >>>> shouldn't be allowed. (Those containing "." and "..") >>>> >>>> Another really dangerous thing that we do is have >>>> full-scope-allowed set >>>> to true by default. If a rogue client gets registered, they pretty >>>> much >>>> have access to every single application the user can access with >>>> all of >>>> their privileges. >>>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>