Security 为什么要允许客户端关闭XSRF保护？

不久前，我在工作中使用的一个软件中遇到了一个选项，通过在客户端包含一个特殊的HTTP头值来关闭XSRF服务器端保护。因此，我想知道：

• 这怎么不是一个安全漏洞
• 为什么要实现安全功能并允许客户端关闭它？我是否缺少一个用例

我怀疑我目前对XSRF保护的了解，因为我们在工作中无法达成共识，我决定在这里发表我的担忧

---

该产品是竹子，他们公开报告的选择。我在这里的一个老答案中首先提到了这一点：。

我想把问题转过来：为什么要实现安全功能，然后让用户打开它们？这是一种适用于安全性的选择模式，您可以在任何地方找到，例如，实际上没有人强制2FA，即使它是一种巨大的安全改进

---

如果XSRF是基于会话的，并且您使用同一应用程序运行多个选项卡，并且您被迫在其中一个选项卡中重新验证，那么您通常会获得一个新的XSRF令牌。其他选项卡可能不再通过XSRF检查，有丢失未保存工作的风险。可能还有其他类似的情况

---

有时在安全性和可用性之间会进行权衡，在这种情况下，它们会使安全性成为默认值，并让遇到问题的人承担知情的风险。

还有其他方法来缓解XSRF。因此，如果cookie不是一个选项（可能客户端不支持cookie），您可能希望禁用此cookie解决方案

缓解XSRF的其他一些方法：

状态变量（Auth0使用它）-客户端将生成一个加密强随机nonce，并随每个请求一起传递，服务器将随响应一起回显该nonce，从而允许客户端验证该nonce。这一点在本书中有解释

始终检查referer头并仅在referer是受信任域时接受请求。如果referer头不存在或是非白名单域，只需拒绝请求即可。当使用SSL/TLS时，通常会出现引用者。登录页（主要是信息性的，不包含登录表单或任何安全内容）可能不会太轻松​并允许缺少referer标头的请求

---

我可以理解允许服务器在每个API的基础上关闭它。但是允许客户端关闭它是一个非常糟糕的主意…这和不在那里一样好。我认为这是可以的唯一原因是向后兼容性。可能有一个旧版本的客户端依赖这种方式来缓解CSRF，而新的客户端依赖于这种方式ts使用新版本，并关闭旧版本（但必须使用其中一个）。

“其他选项卡可能不再通过XSRF检查”他们如何知道是否跳过检查？顺便说一句，这就是为什么通过cookie设置xsrf令牌是一个坏主意。标题告诉他们是否应该跳过检查。如果xsrf令牌与会话cookie相关，则当会话cookie更改时，xsrf检查将失败。仅在cookie中设置xsrf令牌是毫无意义的，但是你在Node.js中有一个csurf中间件，它有一个令牌和一个必须对应的cookie，这是一个在无状态环境中有意义的实现。“头告诉他们是否应该跳过检查”等等，tabs提交的是一个请求头，而不是他们可以检查的响应头。尽管如此，我仍然不知道他们会如何决定在请求中提供XSRF令牌，或者干脆使用“不检查”。我还发现与2FA的类比是不正确的：“实际上没有人强制2FA”。这里的问题是，为什么一旦启用2FA，您就可以通过提供预定义的值来绕过它，比如“0000”“还有其他方法来缓解XSRF”问题是为什么一开始就允许存在这样的方法？“这个cookie解决方案”它不仅是cookie本身，还可以通过（另一个）头工作。