Jetty上的SameSite标志

Question

如果我使用标记SameSite=Lax或SameSite=Strict来托管war文件，我如何将它添加到Jetty生成的会话cookie中？

Answer 1

从Jetty9.4.23开始，您可以在web应用程序的SameSite文件中为JSESSIONID指定所需的web.xml值，如下所示：

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

其他可能的值是__SAME_SITE_LAX__和__SAME_SITE_NONE__。

详情请参见“码头”第4247期。

Answer 2

我使用的是Jetty6.1.19版本，因为Jetty不支持Cookies中的SameSite属性。Jetty还为SameSite提供了一些支持/解决方案，这是Jetty9.*的最新版本。我想出了Jetty6.1.19版本的解决方案，我在Jetty中添加了下面的代码行，即更改方法名addSetCookie of class HttpFields。对我来说是有效的。

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

API代码：

​

​

Answer 3

让我们在CSRF的帮助下理解SameSite cookie。

攻击场景

攻击者将根据目标用户的兴趣创建一个吸引人的网站，例如将其命名为http://www.trustmedude.com。例如，一个提供实时板球得分的网站，甚至一个色情网站。在这个应用程序中，他可以嵌入一个ajax请求来调用url。

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

其中258946257412是攻击者的帐号。现在，如果合法用户登录到银行的原始网站，那么攻击者将强制用户以某种方式浏览他的网站http://www.trustmedude.com，例如在聊天中发送url。当用户单击该网站时，嵌入在该网站中的Ajax请求将在后台执行。如果用户在另一个选项卡中实际登录到银行应用程序，那么他的cookie将在浏览器中随时可用。浏览器将看到一个请求被发送到银行的网站。由于请求是初始化到testbankapp.com域的，因此浏览器在发送用户的有效cookie之前不会三思。够了，笨蛋！

解决方案与同类曲奇

这是CSRF攻击的一个典型例子。在现实世界的攻击中，这将更加复杂。为了防止通过CSRF窃取cookie，HTTP工作组于2016年引入了SameSite cookie标志。让我们了解一下它是如何工作的。基本上，SameSite键有两个可用的值，即松弛值和严格值。

Secure: phpsessid=oIZEL75Sahdgf34ghLnw；HttpOnly；Secure；SameSite=Strict

考虑我们上面的CSRF示例。对于SameSite=Strict，如果链接来自外部站点，浏览器将不会将cookie发送到已通过身份验证的网站。因此，在我们的示例中，即使用户单击攻击者发送的恶意url，浏览器也不会发送cookie。严格的值将阻止cookie的任何跨源使用，因此它被认为最适合于银行应用程序。

但在其他情况下，也可能需要有限的跨来源使用。例如，如果一个网站想要将用户定向到Github，则需要在跟踪该网站的常规链接时允许使用会话cookie。这可以通过设置SameSite=lax来实现。在松散模式下，将允许有限的跨站点使用，即如果请求是GET请求，并且请求是顶级的。顶层意味着url栏应该指示交叉原点请求。例如，当您从某个facebook.com注释重定向到YouTube时，请考虑这种情况。

因此，如果您更喜欢银行级别的安全性，SameSite=Strict是您的选择。

来源：https://www.wst.space/cookies-samesite-secure-httponly/

编辑： 此链接 Jetty不支持这个特性。