SameSite flag on Jetty session cookies

Question

How can I add the flag SameSite=Lax or SameSite=Strict to session cookies generated by Jetty if I am using it to host war files?

Answer 1

Starting with Jetty 9.4.23, you can specify the desired SameSite value for JSESSIONID cookie set by Jetty in web.xml file of your web app like this:

<session-config>
    <cookie-config>
        <comment>__SAME_SITE_STRICT__</comment>
    </cookie-config>
</session-config>

Other possible values are __SAME_SITE_LAX__ and __SAME_SITE_NONE__.

See issue #4247 in Jetty for details.

Answer 2

I'm using Jetty 6.1.19 version, As Jetty doesn't support the SameSite attribute in Cookies. Jetty also provided some support/workaround for SameSite its lastest version of Jetty 9.*. I figure out a workaround of Jetty 6.1.19 version I have added the below line of code in Jetty API, Change in method name addSetCookie of class HttpFields. It is worked for me.

buf.append(";SameSite=Strict");

API code:

Answer 3

Let us understand SameSite cookie with the help of CSRF.

Attack scenario

The attacker will create an attractive website based on the target user’s interest, lets call it http://www.trustmedude.com for instance. For example, a website that provides live cricket score or even a porn website. Inside that application he can embed an ajax request to call the url

https://www.testbankapp.com/transfer?amt=1000&toAccNo=258946257412&fromAccNo=954781203584&mode=imps

Where 258946257412 is the account number of the attacker. Now, if the legitimate user is logged into the bank’s original website, then the attacker will force the user to browse his website http://www.trustmedude.com by some means, for example by sending the url in chat. When the user clicks on the the website, the Ajax request embedded in the website  will be executed in the background. If the user is actually logged into the bank application in another tab, then his cookies will be readily available in the browser. The browser will see a request is being sent to the bank’s website. Since the request is being initiated to the testbankapp.com domain, the browser will not think twice before sending the valid cookie of the user. That’s it, pwned!

The solution with samesite cookie

This is a typical example of CSRF attack. In a real world attack this will be more complex. To prevent stealing cookie by means of CSRF, HTTP working group introduced the SameSite cookie flag in 2016. Let’s understand how it works. Basically SameSite key has two values available namely lax and strict. Example with SameSite:

Set-Cookie: phpsessid=oIZEL75Sahdgf34ghLnw; HttpOnly; Secure; SameSite=Strict

Consider our CSRF example above. In case of SameSite=Strict, the browser will not send the cookie to an already authenticated web site, if the link derives from an external site. So, in our example the browser will not send the cookies even if the user clicks on the malicious url sent by the attacker. The value strict will block the cookie from any cross origin usage, and hence it is considered as most appropriate for a banking application.

But there can be other cases where a limited cross origin usage is required. For example if a website wants to direct users to Github, session cookie needs to be allowed when following a regular link from this website. This can be achieved by setting SameSite=lax. In lax mode limited cross site usage will be allowed, i.e if the request is a GET request and the request is top-level. Top level means the url bar should indicate the cross origin request. For example, consider the case when you are redirected to facebook.com from some YouTube comment.

So, if you prefer banking level security SameSite=Strict is your choice.

Source: https://www.wst.space/cookies-samesite-secure-httponly/

Edit: As per this link Jetty doesn't support this feature.