Springs CSRF 保护 HTML *only* 登录页面

Posted 2023-02-27

【中文标题】Springs CSRF 保护 HTML *only* 登录页面

【英文标题】：Springs CSRF protection for a HTML *only* login page

【发布时间】：2016-01-15 18:05:18

【问题描述】：

我正在尝试利用 Spring Security 内置的 CSRF 保护。这些是我正在使用的春季版本：

Spring 框架版本 - 4.2.1

Spring 安全性 - 4.0.2

spring 安全文档中提到，登录页面也必须受到保护以免受 CSRF 攻击。我看到当我启用 CSRF 保护（并且没有传递令牌）时我的登录不起作用 - 正如预期的那样。

我的登录页面是一个纯 html 页面（不是 JSP），我不能使用任何 Spring 或 JSTL 标签。我正在考虑实施类似于此处描述的解决方案 -

With Spring Security 3.2.0.RELEASE, how can I get the CSRF token in a page that is purely HTML with no tag libs

上述链接中解释的解决方案（作者的博客在评论中链接到已接受的答案）是在登录页面上进行 AJAX 调用，该调用将获取 CSRF 令牌的值，然后将其包含在登录请求

不过，spring 文档中也提到，只要访问 csrfToken，就会创建一个新的 HttpSession。我有几个问题-

我获取 csrf 令牌的 ajax 调用将不受保护，因为我必须在登录之前调用它。

考虑到 ajax 调用不安全，访问 CSRF 令牌后立即生成新的 HttpSession 这一事实也值得关注。

应用程序的其余部分仅进行 AJAX 或 REST 调用，我计划实现客户端拦截器，以便在用户登录后将 CSRF 令牌包含在标头中。（据我了解，用户会话有一个 CsrfToken )

有没有人知道如何使用 Spring 的 CSRF 保护来保护纯 HTML 登录页面？

【问题讨论】：

为什么纯 html 或令牌获取是否“不安全”很重要，“不安全”是什么意思？ （两者都不必是 POST，我看不出在用户不知情的情况下请求该资源的危害。）

或者换句话说，如果您的应用程序由于机器人点击登录页面或请求过多的令牌而崩溃，那么您的应用程序编写得不好。

或者换一种说法，如果你有一个坚固的前门，你就不需要在大门上安装蜂鸣器。

你是对的，请求资源没有害处。但是即使在登录之前创建多少个 HttpSessions 也会是一个问题，不是吗？有一些方法可以检测和防止这样的 DOS 攻击，所以也许我想多了。我想知道这种方法是否可以接受，或者还有其他我没有想到的方法。

CSRF 保护是为了避免在用户不知情的情况下（通常）在您的网站深处填写和提交表单。对于没有副作用的 url，您不需要它，例如静态 html 页面...

【参考方案1】：

1）如果你仔细研究CSRF vulnerability，你会发现通过GET请求获取token是没有漏洞的。

2) 在登录/注销等之后，当创建一个新会话时，令牌会发生变化，您可能需要再次获取它。在this 帖子中有更多讨论。

Spring Lemon 的源代码将是如何使用 AJAX+CSRF 的一个很好的参考。另请参阅official guide。