CODEWITHSUNDEEP
google-chrometomcatcookiessamesite
Debojit Kundu
Debojit Kundu

Reputation: 131

Samesite attribute of cookies set in response are not getting modifed by tomcat's cookieprocessor

Recently browsers are increasing security to prevent CSRF attacks via enhancing samesite cookie default value to Lax, i.e., if the samesite attribute is not set by the server while setting cookie via response set-cookie header, browser will consider them as Lax, and not stored, so in the subsequent calls the cookies are not sent back to server failing those requests. This happens on cross domain communication where a cross domain application is running in an iFrame on the main website.

We have one such server application that sets two cookies on the response of successful authentication requests, and those cookies are supposed to be sent back to server with every subsequent call to make the server believe the requests are authenticated for further processing. These cookies don't have any samesite attribute set explicitly, so the new browsers (Chrome 80) is not sending them back in the subsequent calls.

The server application is hosted on tomcat. So in order to mitigate the issue we used tomcat's cookieprocessor to set the cookie's samesite attribute to be set as "none", so that cross domain calls cane be made. Unfortunately that did not work. Despite setting samesite attribute explicitly via cookieprocessor that response while checked via developer tools does not show any trace of samesite attribute.

So here the question: am I getting it correct that tomcat should modify the server's response to add the samesite attribute to the cookies those are set via set-cookie header on the response? I tried debugging the cookieprocessor code by setting up remote debugging but it looks like the response's are not intercepted and hence the cookie header is getting modified. What I am doing wrong here?

Note: I have configured the cookieprocessor in application's meta-inf/context.xml.

Upvotes: 3

Views: 6888

Answers (2)

Debojit Kundu
Debojit Kundu

Reputation: 131

I actually resolved the mystery by myself. Cookieprocessor works only if the cookies are added via response.addCookie() method. So, if the cookies are set via set/add header methods cookieporcessor won't do anything. Actually our server application does the header approach to add cookie and not the addCookie() method.

Upvotes: 2

Jarrett Chan
Jarrett Chan

Reputation: 31

So you're using Tomcat, but what version of Tomcat are you using?

The initial release of the CookieProcessor SameSite support used "None" to refer to behavior to unset the SameSite value.

https://bz.apache.org/bugzilla/show_bug.cgi?id=63865

Fixed in:
- master for 9.0.28 onwards
- 8.5.x for 8.5.48 onwards

I'm not sure if the CookieProcessor from Tomcat considers the User-Agents of the clients.

If you implement this way, your application may not support the known incompatible clients: Chrome 51-66, MacOSX Mojave (10.14) Safari/Embedded, iOS 12, UCBrowser prior to 12.13.2

https://www.chromium.org/updates/same-site/incompatible-clients

We solved our normal cookies by using addHeader to support SameSite.

We solved our session cookies in our nginx layer.

For JSESSIONID, it seems you could also use a Filter to wrap HttpServletRequest to append a copy of the session cookie with proper attributes whenever a new session is created. Though it is adding like ~80B for the overriding JSESSIONID.

Upvotes: 3

Related Questions