我们可以在报头请求中设置一个定制的CSRF令牌来生成CSRF PoC吗？

Question

我试图为我发现的CSRF问题创建一个PoC。请求在请求头中包含CSRF令牌，问题是服务器端只检查令牌是否可用，而不检查它是否属于当前用户会话。

我试图通过设置一个自定义头来使用我的令牌(因为服务器不验证CSRF令牌)来使用我的令牌覆盖CSRF令牌，从而使用XmlHttpRequest创建CSRF令牌，但由于CORS，这将被阻塞。

POST /endpoint
HEADER_CSRF: ANY_CSRF_TOKEN  <--- accept any other CSRF token 
...

是否有一种方法可以实现CSRF PoC而不因CORS而被阻塞？

Answer 1

只是想看看我的理解：

• 站点需要一个自定义的标题(即使它不检查值)
• 该站点不允许您以任何其他方式传递反CSRF令牌(例如，body、URL等)。
• 该站点要么根本不允许CORS，要么它的CORS策略不允许第三方站点设置有关的标头。

都是对的吗？如果是的话：

您还没有发现任何CSRF问题；该站点不容易受到CSRF!

的攻击。

这实际上是我最喜欢的减轻CSRF的方法之一。

• 它需要最低限度的逻辑:只要检查头是否存在，就不需要对它做任何事情。
• 它不需要服务器端状态；实际值与此无关。
• 它不需要任何特殊的配置；默认的CORS策略已经强制执行我们想要的行为。
• 它确实需要客户端脚本(以添加标头)对所有状态改变的请求到服务器，但这是常见的当今(例如，无记名令牌或图形an )，并且不像承载令牌，实际的身份验证令牌可以存储在一个HttpOnly cookie中，为XSS提供了一个小的缓解。
• 它并不特别脆弱；服务器需要更改其CORS配置，以允许第三方站点使用-凭据请求并设置有问题的标头，这是很多错误配置的原因。
• 它不依赖于新的浏览器行为，如SameSite cookie标志；太旧的浏览器将无法工作，因为它太老了，根本不支持CORS请求，这两者都是故障安全的，而且非常旧。
• 它不容易受到来自子域、纯文本HTTP或SameSite经常使用的不同端口的攻击；所有这些都是不同的来源，需要一个CORS请求，并带有预运行前的请求。

顺便提一句，飞行前的要求是关键。只是不允许CORS请求DOES而不是阻止CSRF；攻击者可以发送非CORS跨站点请求(使用Fetch API，或者只使用自动提交的HTML form元素)或非预置的(“简单”) CORS请求，即使服务器用相当于“嘿，这是不允许的！”的CORS响应。服务器也可能仍然正常地处理请求。即使在有证书的(包含cookie的)请求中也会发生这种情况；设置withCredentials=true并不会使CORS请求需要预运行，并且提交表单时会自动包含cookie。阻止浏览器发送请求的唯一方法是拒绝可以在不预先执行任务的情况下发出的请求。

尽管如此，除了自定义头之外，还有其他几种方法可以这样做：

• 您可以要求内容类型不同于允许简单(非预置)请求的类型(纯文本、url编码形式、mime多部分)。当然，application/json是通常的选择。请注意，这意味着完全验证Content标头值；仅仅要求Content标头包含字符串" JSON“(在简单请求中可以欺骗)是不够的，绝对不能仅仅将主体解析为JSON。
• 您可以要求HTTP谓词(方法)不是简单请求(GET、HEAD、POST)所允许的内容。