【问题标题】:Spring Security and CSRF attackSpring Security 和 CSRF 攻击
【发布时间】:2018-03-05 08:58:11
【问题描述】:

我正在开发一个应该非常安全的 Java Web 应用程序,因此我在 SSL 服务器上应用了 Spring Security 和 Spring MVC,并启用了 CSRF;我使用 POST 成功提交了所有表单以及生成的 CSRF 令牌,但是有些页面具有 GET 方法,如果任何攻击者从任何浏览器打开任何页面的源代码,他可以在 Form 标签内看到生成的 CSRF 令牌,那么他可以使用只要会话受到攻击的用户处于活动状态,它就可以将任何内容发布到我们的网站!我说的对吗?

我应该怎样做才能使网站非常安全?我应该使用任何其他开源以及 spring security 来覆盖其他攻击,如跨站点脚本等。我应该强制所有页面使用 POST 来避免任何 CSRF 攻击吗?

更新

我尝试通过客户端工具在同一会话下使用与登录用户相同的令牌提交请求来进行更多测试,但它失败了,响应说登录失败,并且标头包含 nosniff

X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY

所以我认为在 spring security 中使用 GET 来处理 csrf 是安全的,而不用害怕有人读取 GET 页面中的令牌,除非攻击者使用 XSS 攻击来进行提交

【问题讨论】:

    标签: java spring security spring-security csrf


    【解决方案1】:

    攻击者可以看到自己的 CSRF 令牌,但不能看到其他用户的 CSRF 令牌。不同的用户有不同的token,用错token应该是不行的。

    所以这里没有什么可担心的。不要惊慌。

    【讨论】:

    • 如果攻击者在受害者会话打开时放置脚本来读取 GET 页面(例如显示读取某些 GET 页面的广告),他可以读取该页面的敏感数据并窃取该页面内任何 POST 操作中的令牌,并使用它来执行 POST 操作。
    • @HanySak​​r,是的,但是如果攻击者可以发布脚本,那么 CSRF 是他最不想考虑的事情之一。在这种情况下,他还可以做其他更严肃、更直接的事情,例如删除JavaScript key logger 来窃取用户密码。可以这样想:CSRF 在逐个用户的基础上工作,但跨站点脚本会同时攻击许多用户。跨站脚本比 CSRF 危险得多。
    • 感谢您的回复。实际上我需要对任何攻击关闭大门,我已经处理了跨站点脚本,并且想如果我可以将所有页面更改为POST而不是GET,它将完全覆盖CSRF,并且不会让任何人猜测生成的令牌。我看到了一个为每个页面生成令牌的解决方案,例如 HDiv,但我不知道它是否与 Spring Security 集成?
    【解决方案2】:

    但是有些页面有 GET 方法,如果任何攻击者打开 来自任何浏览器的任何页面的来源他都可以看到生成的 CSRF 标记内的表单标记,然后他可以使用它来发布任何内容到 只要会话处于活动状态,受攻击的用户就可以访问我们的网站! 我说的对吗?

    是的,您是对的,使用 GET 会使您的网站泄露敏感信息。这正是Spring SecurityRFC Specification 不鼓励使用GET 请求发送敏感信息的原因。如果您要发送 CSRF 令牌,您应该 POST。

    我应该怎样做才能使网站非常安全?我应该使用任何其他 开源以及 Spring Security 以涵盖其他攻击,例如 跨站脚本等。?

    Spring Security 框架不是灵丹妙药。使用它不会神奇地使您的 Web 应用程序 100% 安全。尽管它涵盖了大多数安全漏洞,但我们必须确保以不引入任何安全漏洞的方式编写代码。

    例如:

    在跨站点脚本的情况下,即使您使用 Spring Security,如果您从 HTML 输入框中获取一个值并直接保存它而不对其进行 HTML 编码并将其显示在一个 JSP 文件中,如 ${value} 您将介绍XSS 的可能性。

    【讨论】:

    • 感谢 Shazin,但我没有通过 GET 更改服务器的状态,我只是使用 POST 提交表单,因此 CRSF 令牌永远不会出现在 URL 上。我想要的只是使用 GET 从服务器检索信息,例如带有一些操作的列表,因此用户可以使用 POST 提交操作。这里的问题是页面本身是GET,所以攻击者可以加载它并开源并获取token;所以在这种情况下,我应该将所有页面都保留为 POST !对不对!!
    猜你喜欢
    • 2011-06-18
    • 2020-02-16
    • 2019-04-25
    • 1970-01-01
    • 2014-07-02
    • 2015-12-10
    • 2019-09-08
    • 2014-08-07
    • 2013-05-06
    相关资源
    最近更新 更多