[keycloak-dev] Open Redirect Vulnerability

Stian Thorgersen stian at redhat.com
Thu Apr 16 09:52:17 EDT 2015


Thinking about it some more the reason I didn't get it is because it's not applicable to Keycloak because we don't allow anyone to register a client. Only admins are allowed to create clients in Keycloak, so a client is a trusted entity.

If it's possible to register untrusted clients, like it is for any social provider (or SaaS service), this becomes a problem. It doesn't have anything to do with verifying the redirect-uri, because you still set a valid redirect-uri. Even worse it's actually a problem with the spec itself as the post says. For any error except a redirect-uri related error it should redirect back to the application. That could be an invalid response_type, invalid_scope, etc..

Google doesn't actually follow the spec as they display an error page for invalid_scope instead of redirecting back to the client.

If we have implement support for anyone to register clients in Keycloak, we need to do the same. If it's a "untrusted client" never redirect to client in case of an error. The rule could be if it requires consent, display error page, if it doesn't require consent redirect to app.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 3:35:36 PM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> Yep, but that is pretty much about tricking users. For instance, a malicious
> client could utilize a user's trust in your authorization server to launch a
> phishing attack.
> 
> Bill already stated that KC redirects to an internal error page instead of
> redirecting to client when some error occurs (eg.: invalid client_id or
> redirect uri). Which is one of the most important recommendations [1]. The
> URI is also validated using the full redirection uri, not only part of it.
> 
> Google also provides some restrictions when defining redirect URIs. For
> instance, you can't use fragments.
> 
> [1] https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08
> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 4:06:16 AM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> 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
> > 
> _______________________________________________
> 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