SameSite cookies

[Carlos Saltos]

WHAT ?

This is a kind request for adding SameSite cookies support for Lift

WHY ?

SameSite for cookies was kind of optional years ago but now it has reached solid ground and now is a must for web security. More info at https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Set-Cookie/SameSite

HOW ?

Adding sameSite: Box[String] to net.liftweb.http.provider.HttpCookie
 and it's correspondent value generation at response time

WHO ?

I'm using Lift happily since 2012, it's a great framework. I thank all the team for that and I hope we can add this new web panorama change to Lift too.

Best Regards,

Carlos Saltos

[Andreas Joseph Krogh]

I welcome this!

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

 

[Tim Nelson]

I don't see any reason not to add this.

[Carlos Saltos]

I was trying to add a PR as a reference for this but I found out that the Servlet API (where Lift is supported) does NOT have SameSite support (a PR is pending here -> https://github.com/eclipse-ee4j/servlet-api/pull/271)

I think since Lift uses Scala it can implement its own cookie encoding/decoding and pass through the Servlet API as a header.

What do you think guys ? ... should we attempt to try that ?

[Andreas Joseph Krogh]

På mandag 05. april 2021 kl. 21:06:42, skrev Carlos Saltos <csa...@gmail.com>:

I was trying to add a PR as a reference for this but I found out that the Servlet API (where Lift is supported) does NOT have SameSite support (a PR is pending here -> https://github.com/eclipse-ee4j/servlet-api/pull/271)

 

I think since Lift uses Scala it can implement its own cookie encoding/decoding and pass through the Servlet API as a header.

 

+1, after all, these things are "just" HTTP-headers.

[Carlos Saltos]

OK, here you have a sample project with a workaround using Netty ->

https://github.com/csaltos/lift-samesite-cookie-workaround

I hope this is enough until adding SameSite to the Servlet API and/or Lift directly.

IMPORTANT: The workaround is working, but of course if not queuing the cookies nor abstracting the third party library Netty away ... use it with care.

[Tim Nelson]

I haven't looked into this, but this comment may be helpful in setting the cookie with Jetty:

https://stackoverflow.com/a/60472326/359319

For reference, here's a previous thread on this issue: 

https://groups.google.com/g/liftweb/c/bKFoFctcY8k/m/KerBmz-xAQAJ

[Carlos Saltos]

Great, that's a nice workaround until we have a more solid solution, thank you !!

[Carlos Saltos]

OK guys, here a PR for trying to fix this for Lift using Scala via the Netty HTTP encoder -> https://github.com/lift/framework/pull/1990

We are going to try to use this patch already for Talenteca.com and I hope you find it valuable.

Best regards,

Carlos Saltos

[Andreas Joseph Krogh]

På onsdag 07. april 2021 kl. 01:57:49, skrev Carlos Saltos <csa...@gmail.com>:

OK guys, here a PR for trying to fix this for Lift using Scala via the Netty HTTP encoder -> https://github.com/lift/framework/pull/1990

 

We are going to try to use this patch already for Talenteca.com and I hope you find it valuable.

 

I think you have about zero chance of getting this merged as it introduces netty-deps.

 

--
Andreas Joseph Krogh

 

[Carlos Saltos]

Oh !! ... why ? ... netty is evil ?

[Andreas Joseph Krogh]

På onsdag 07. april 2021 kl. 03:15:35, skrev Carlos Saltos <csa...@gmail.com>:

Oh !! ... why ? ... netty is evil ?

 

No:-)

But - it's bad policy for any framework to introduce "all kinds of" dependencies just because it is convenient to use for some use-case. Lift is used in many (large) places and version-conflicts might then be introduced as more libraries are transitively pulled in as dependencies. Here it seems Netty is used because you didn't bother to implement the details of "encoder.encode(cookie)". I can understand it's convenient to do so, but it's too slim of a use-case to introduce deps to Netty.

--
Andreas Joseph Krogh

[Henrik Härkönen]

For Jetty I think I managed to handle it with web.xml :

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

Other possible values should be __LAX__ or __STRICT__ . If using "none", then the secure cookie must be true in the cookie-config <secure>true</secure>

You must use Jetty 9.4.23 or more recent.

Maybe this could be set for the basic template project? Should really double check that it works, I was half asleep when playing with it...

-Henrik

[Carlos Saltos]

Nice hack !! ... using the COMMENT section of a cookie to insert new security configuration ... but sadly in our case (and maybe for other people) ... some cookies have to go with STRICT and others with NONE ... this hack is a global all-or-nothing configuration.

The SameSite cookies is a standard going on since 2016 and it's surprising how slow the Servlet API is able to implement it (it's not a decoration, it's a real security measure used in nowadays browsers and API calls on real projects).

Best regards,

Carlos Saltos

[Carlos Saltos]

Yes, you are right, that functionality can be added with explicit code or even shaded code (for not losing the upgrades of new bug fixes, patches, and features to come).

But anyway, I think it's even a worst policy for any framework to leave a security standard lost in the road for years. SameSite cookies it's a security standard since 2016, that's 5 long years.

Let's see what the Lift maintainers decide ... and of course I can gladly add explicit code to the PR or, as mentioned, shaded code.

Best regards,

Carlos Saltos

[Matt Farmer]

Thanks for all the work y’all have done on this. I’ve been following along and am going to try and formulate a more thorough response tonight or tomorrow night.

I, too, am miffed the Servlet API hasn’t been quicker to add support here. 

On Apr 7, 2021, at 10:30 AM, Carlos Saltos <csa...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/8a197fe9-e1f5-40e9-84a1-9b17d382e079n%40googlegroups.com.

[Carlos Saltos]

Great !! ... Thank you very much Matt ... and also thank you very much for all the people and the community that creates and maintains Lift, it's an amazing project we are happily using for years in Talenteca.com.

Best regards,

Carlos Saltos

[Matt Farmer]

Left a comment on the PR — I don't want the Netty dependency, but I'm fine if we pull their cookie encoder implementation, modify it to avoid having to pull in a bunch of other things, and add it to Lift.

[Carlos Saltos]

Ready dear Matt !! ... please find the new cookie encoder simplified and in a Scala version plus Specs2 test here -> https://github.com/lift/framework/pull/1990

If further improvements are required, please let me know and I will gladly try to implement them.

Best regards,

Carlos Saltos

[Carlos Saltos]

And we get the solution merged -> https://github.com/lift/framework/pull/1990

Thanks to all the participants in this security PR, the new Lift version will be even better and better. I love Lift !!