5:32 a.m.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "Bill Burke"
<bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 14 January, 2015 11:33:08 AM
Subject: Re: [keycloak-dev] oauth vulnerabilities
On 14.1.2015 09:41, 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
I wonder that it's quite restrictive and not compatible with other stuff
using url mappings? For example in servlet specification if you map
servlet under "/a/*", it would map to everything including
"/a/b/page.html" .
Isn't it sufficient to just refuse url if it contains dangerous
characters like dots in the path?
In a servlet environment it's fine, because the url-pattern is relative to the
application. So you know all child resources belong to the application.
The problem is that by allowing a recursive wildcard is that it allows a very bad practice
which is to share the same client_id and secret for multiple applications. For example an
app with redirect 'http://acme.org/*' could be used by all apps under the same
domain.
Marek
>
> 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>
>> 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