GWTP CSRF protection

[Brad Cupit]

Hi,

I have a minor security concern with GWTP's CSRF protection: the cookie has the same value as the JSESSIONID.

In our GWTP app we'll mark our real JSESSIONID as both secure and HttpOnly. This way the it can't be sniffed, and XSS attacks won't be able to read it and hijack the session.

Then I noticed the GWTP CSRF cookie is not secure, not HttpOnly, and uses the same session ID. So an attacker could just read the GWTP cookie instead.

From what I've seen GWT's CSRF protection uses a hash instead of the session ID (which sounds great!)

Am I the first to come across this, or maybe I'm missing something obvious?

Thanks in advance!

[Clay Harris]

That depends in part on your implementation, but CSRF does not rely on its own cookie, it adds a header to the request.  Then the cookie and the header (which is hashed) are compared.  Cookies alone could be spoofed, you're right, but that's why there's a header as well.  http://www.gwtproject.org/articles/security_for_gwt_applications.html#xsrf

So based on that, I don't think it's a real concern.  Watch your request headers using devtools, and see if they have an xsrf value to confirm

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clay Harris]

Our implementation did not produce a separate cookie, so you may be implementing it differently.  I couldn't really tell you how that's working, though having the same value (unless you're manually comparing before and after) is key, as that's what validates the session.  

But that's not the key area to look.  You should look under the Request Headers tab, and see if there's a request header similar to "com.google.gwt.user.client.rpc.XsrfToken".  That's the important part, as it is what an attacker cannot spoof.

Also, keep in mind that your emails go to the whole group - so you may want to redact domains / identifying URL information when posting images, as it will be out there for the world to see

On Wed, Apr 30, 2014 at 8:47 AM, Brad Cupit <brad....@riptidesoftware.com> wrote:

Hi Clay,

Thank you so much for your response! You said something interesting: CSRF protection doesn't rely on its own cookie. It's very possible we've got it setup wrong.

Here's a screenshot of the cookies in our app:

I should also mention we're using GWTP 0.7, but I've looked at the latest code and it looks the same as the version we're using. The cookie gets created with a value matching the session ID.

Is there a way to not use this cookie and still get the CSRF protection? Or to change the value so it's not the JSESSIONID?

Thanks again Clay.

- Brad

[Brad Cupit]

Ack, great point!

Regarding the cookie, I think I see the difference. We're using GWTP's @SecurityCookie approach rather than GWT's XsrfToken. I've read through the GWT XsrfToken documentation and it doesn't seem like it's compatible with GWTP actions.

I did find GWTP's RandomSecurityCookieFilter though, which uses a different value than the session ID and seems like what I want.

I have a question though: with GWTP's @SecurityCookie approach, is the basic idea that 'secure' Actions must have a session and 'insecure' Actions don't need one? Or is there more to it than that?

- Brad

On Wednesday, April 30, 2014 8:53:42 AM UTC-4, Clay Harris wrote:

Our implementation did not produce a separate cookie, so you may be implementing it differently.  I couldn't really tell you how that's working, though having the same value (unless you're manually comparing before and after) is key, as that's what validates the session.  

But that's not the key area to look.  You should look under the Request Headers tab, and see if there's a request header similar to "com.google.gwt.user.client.rpc.XsrfToken".  That's the important part, as it is what an attacker cannot spoof.

Also, keep in mind that your emails go to the whole group - so you may want to redact domains / identifying URL information when posting images, as it will be out there for the world to see

On Wed, Apr 30, 2014 at 8:47 AM, Brad Cupit <brad....@riptidesoftware.com> wrote:

Hi Clay,

Thank you so much for your response! You said something interesting: CSRF protection doesn't rely on its own cookie. It's very possible we've got it setup wrong.

Here's a screenshot of the cookies in our app:

I should also mention we're using GWTP 0.7, but I've looked at the latest code and it looks the same as the version we're using. The cookie gets created with a value matching the session ID.

Is there a way to not use this cookie and still get the CSRF protection? Or to change the value so it's not the JSESSIONID?

Thanks again Clay.

- Brad

On Wednesday, April 30, 2014 8:34:25 AM UTC-4, Clay Harris wrote:

That depends in part on your implementation, but CSRF does not rely on its own cookie, it adds a header to the request.  Then the cookie and the header (which is hashed) are compared.  Cookies alone could be spoofed, you're right, but that's why there's a header as well.  http://www.gwtproject.org/articles/security_for_gwt_applications.html#xsrf

So based on that, I don't think it's a real concern.  Watch your request headers using devtools, and see if they have an xsrf value to confirm

On Wed, Apr 30, 2014 at 8:26 AM, Brad Cupit <brad....@riptidesoftware.com> wrote:

Hi,

I have a minor security concern with GWTP's CSRF protection: the cookie has the same value as the JSESSIONID.

In our GWTP app we'll mark our real JSESSIONID as both secure and HttpOnly. This way the it can't be sniffed, and XSS attacks won't be able to read it and hijack the session.

Then I noticed the GWTP CSRF cookie is not secure, not HttpOnly, and uses the same session ID. So an attacker could just read the GWTP cookie instead.

From what I've seen GWT's CSRF protection uses a hash instead of the session ID (which sounds great!)

Am I the first to come across this, or maybe I'm missing something obvious?

Thanks in advance!

--
You received this message because you are subscribed to the Google Groups "GWTP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Clay Harris]

That's probably the difference - we'rd not using Actions, but regular GWT RPC.  We need to make that transition though, heh.  As such, I won't be much help the GWTP @SecurityCookie approach, unfortunately

[Brad Cupit]

Clay, thank you very much for your help and quick responses!

- Brad

[Brad Cupit]

To anyone familiar with GWTP CSRF protection, is the basic idea that 'secure' Actions must have a session and 'insecure' Actions don't need one? Or is there more to it than that?

- Brad

[Brad Cupit]

Ok, I figured it out.

With GWTP's @SecurityCookie approach the cookie value gets sent twice: once as part of the cookie and once in the body of each POST. If the server sees the two don't match, it's a CSRF attack and it throws an exception.

In CSRF attacks the attacker doesn't know the cookie values, so this works great.

In an XSS attack, however, the attacker does know the cookie values, unless you mark the cookie as HttpOnly. Obviously we don't want to allow any XSS attacks, but it's a good idea to mark the JSESSIONID as HttpOnly just in case, so XSS attacks can't hijack the session.

Unfortunately, the HttpSessionSecurityCookieFilter's cookie duplicates the JSESSIONID, and this cookie can't be marked HttpOnly since JavaScript needs to read it (to add the value to the POST body).

So I think users should be discouraged from using HttpSessionSecurityCookieFilter as an XSS attack could see the JSESSIONID value and hijack the session.

Instead I'll use RandomSecurityCookieFilter, since it's a random number instead of the JSESSIONID. Now I just need to figure out how to make that cookie 'secure'.

If there's interest I can file some issues:

1. deprecate HttpSessionSecurityCookieFilter in favor of RandomSecurityCookieFilter
2. configurable way to make the random cookie 'secure'

- Brad

[Christian Goudreau]

There is interest! We'll need to bring GWTP to a new level of security!

Christian Goudreau | CEO - Président

M: 1.877.635.1585 | S: christian.goudreau

ArcBees | Blog | Facebook | LinkedIn

[Brad Cupit]

Great!

I filed two issues: #484 and #485

- Brad

[V.B.]

Any updates on this?

[Asier]

I'm with V.B: any updates?

This feature would be very useful to my public GWT projects.

Regards.

El lunes, 17 de octubre de 2016, 0:01:23 (UTC+2), V.B. escribió:

Any updates on this?