Jetty会话cookie上的SameSite标志

Question

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

Answer 1

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

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

其他可能的值为__SAME_SITE_LAX__和__SAME_SITE_NONE__。

有关详细信息，请参见issue #4247 in Jetty。

Answer 2

我使用的是 Jetty 6.1.19 版本，因为 Jetty 不支持 Cookie 中的 SameSite 属性。 Jetty 还为 SameSite 的最新版本 Jetty 9.* 提供了一些支持/解决方法。我想出了 Jetty 6.1.19 版本的解决方法 我在 Jetty API 中添加了以下代码行，更改类 HttpFields 的方法名称 addSetCookie。它对我有用。

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，例如通过在聊天中发送网址。当用户点击网站时，嵌入在网站中的Ajax请求将在后台执行。如果用户实际上在另一个选项卡中登录了银行应用程序，那么他的cookie将在浏览器中随时可用。浏览器将看到正在向银行网站发送请求。由于请求是发送到testbankapp.com域的，因此浏览器在发送用户的有效cookie之前不会三思而后行。就是这样，pwned！

具有相同网站Cookie的解决方案

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

  

Set-Cookie：phpsessid = oIZEL75Sahdgf34ghLnw;仅Http;安全;   SameSite =严格

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

但是可能存在其他需要有限交叉来源使用的情况。例如，如果某个网站想要将用户定向到Github，那么在关注该网站的常规链接时，需要允许会话cookie。这可以通过设置SameSite = lax来实现。在松弛模式下，将允许有限的跨站点使用，即如果请求是GET请求且请求是顶级的。顶级表示网址栏应指示交叉原始请求。例如，考虑从YouTube评论中重定向到facebook.com的情况。

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

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

编辑根据this link Jetty不支持此功能。