CSRF prevention using a session token is really an application specific
thing that Keycloak cannot handle automatically. Even the referenced
Tomcat filter requires that you manually encode every URL you publish.
Also, if you read the linked owasp doc, it doesn't recommend that you
include CSRF tokens in URLs. #1 it screws up browser caches, and #2 the
token is still stored in browser history.
IMO, CORS, specifically the Origin header, is the best and least
intrusive approach to prevent CSRF. Keycloak has support for that.
Thanks Scott,
As far as I understand now the Chapter 22. Security Vulnerabilities of
Keycloak documentation talks about the security of authentication
workflow. I believe it will be nice if you added clear explanation of
what security the adapters provide and don’t provide after authentication.
Thanks
Ilia
*From:*Scott Rossillo [mailto:srossillo@smartling.com]
*Sent:* Saturday, February 20, 2016 10:29 AM
*To:* Baskin, Ilia
*Cc:* keycloak-user(a)lists.jboss.org
*Subject:* Re: [keycloak-user] Is it CSRF vulnerability?
Are you using the Tomcat adapter? If so you have to configure Tomcats'
CSRF filter.
Once you've authenticated with an SSO server like Keycloak, you still
have to use platform specific CSRF
https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Preventi...
On Fri, Feb 19, 2016 at 6:19 PM Baskin, Ilia
<ibaskine(a)microstrategy.com <mailto:ibaskine@microstrategy.com>> wrote:
Scott,
I know that, but this is exactly how CSRF works. There are several
simple ways to defend against CSRF and I am surprised that
Keycloak, a security application, doesn’t utilize any.
Thanks.
Ilia
*From:*Scott Rossillo [mailto:srossillo@smartling.com
<mailto:srossillo@smartling.com>]
*Sent:* Friday, February 19, 2016 6:15 PM
*To:* Baskin, Ilia
*Cc:* keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
*Subject:* Re: [keycloak-user] Is it CSRF vulnerability?
Once you’ve authenticated with Keycloak, your application has an
session id provided by Tomcat. This is why your requests are
succeeding. If you examine your XHR requests, I’d assume the
session id cookie is being passed to the server.
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com <mailto:srossillo@smartling.com>
On Feb 19, 2016, at 6:01 PM, Baskin, Ilia
<ibaskine(a)microstrategy.com
<mailto:ibaskine@microstrategy.com>> wrote:
Hi,
I am experimenting with Keycloak to evaluate its suitability
for our application. Here is one of my experiments, that got
me warried:
I created a simple page (see attached), deployed it on Tomcat
and registered it in Keycloak as confidential client. As you
can see the page contains a button clicking on which executes
simple XHR request. Notice that XHR request doesn’t contain
Authorization header. On submission of my page URL I am
redirected to Keycloak for authentication. After
authentication I can submit XHR requests at will.
Now I copied my page and deployed the copy on the same Tomcat
as a different totally unsecured application. If I open this
page in another browser tab and click on XHR button it will go
through without any problem. It looks to me as a typical CSRF
case. Am I missing something here?
Thanks.
Ilia
<index.html>_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user