[keycloak-dev] Open Redirect Vulnerability

Stian Thorgersen stian at redhat.com
Fri Apr 17 01:05:13 EDT 2015


This attack assumes that it's a valid client and the redirect uri is valid. It's about untrusted clients being able to bypass user consent by adding expected errors. Google lets anyone register a client so you can register attack.com as a client and the redirect will be perfectly valid. What Google does differently to Facebook is that they don't redirect to the client in an error, so the user will always see a grant page. While Facebook if you enter the wrong scope will redirect to attack.som without showing a consent screen.

We should make sure that Keycloak never redirects to a client that requires consent from the user without user input. Including if there's an error (for example invalid grant_type) and the client requires consent we display a page stating there was an error with a link continue to application. Once a user has consented to a client (persisted grants exists for the user-client) we can redirect to the client as the user has now trusted the client. 

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 7:51:37 PM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> Another scenario is AS partially validating the redirect uri. For instance,
> http://somesite.com/attacker.
> 
> If the registered redirect uri is just http://somesite.com and the AS is not
> checking its full format, it may consider that the uri above is valid. What
> is also covered by KC, so no problem here as well.
> 
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 12:57:02 PM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> I thought the attack was: put in an attacker redirect uri and an invalid
> parameter, auth server fails, redirects to non-validated attacker
> redirect uri.
> 
> On 4/16/2015 3:06 AM, Stian Thorgersen wrote:
> > I don't get the attack, he states that:
> >
> >    Now let's assume an attacker:
> >     * Registers a new client to the victim.com provider.
> >     * Registers a redirect uri like attacker.com.
> >
> > If the attacker can register a client with a redirect uri, how is it then
> > an open redirect?!
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, April 16, 2015 1:31:17 AM
> >> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> >>
> >> One more thing...
> >>
> >> We never redirect unless the redirect URI and client id is validated.
> >>
> >> On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
> >>> Hi,
> >>>
> >>>       Is KC considering this vulnerability [1] when performing redirects
> >>>       ?
> >>>       Specially for OAuth Clients doing authorization code grant.
> >>>
> >>> Regards.
> >>>
> >>> [1]
> >>> http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


More information about the keycloak-dev mailing list