使用自定义所需的 HTTP 标头作为 API 的 CSRF 保护方法是否安全？答案

【问题标题】：Is it safe to use a custom required HTTP header as a protection method from the CSRF for an API?使用自定义所需的 HTTP 标头作为 API 的 CSRF 保护方法是否安全？
【发布时间】：2017-12-25 09:59:24
【问题描述】：

我有一个为 SPA 构建的 JSON API，它只接受带有“Accept: application/json”标头的请求。所以在浏览器中提交如下表单会导致“Not Acceptable”。 HTTP 错误。

<form method="POST" action="https://api.example.domain/resource">
    <input type="password" name="password" value="CSRF">
    <input type="submit" value="Click!">
</form>

这是否意味着 API 对 CSRF 类型的攻击具有免疫力，还是我遗漏了什么？

【问题讨论】：

标签： json rest api security csrf

【解决方案1】：

它应该是相当安全的，但 API 仍有可能存在漏洞。

如果攻击者可以在网站中找到 XSS 漏洞，他可以使用 JavaScript 添加标头：Accept: application/json，然后执行 CSRF 攻击。

因此，推荐依赖一些 JavaScript 无法设置的标头，因为它们在“禁止”标头列表中，只有浏览器可以修改它们，因此这里不能使用 XSS 漏洞。

您将在 OWASP 中找到更多信息：https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

【讨论】：

您好 Jorge，感谢您分享的精彩文章。那么，如果 REST API 将 Access-Control-Allow-Origin: https://domain.name 标头设置到每个响应中，我是否还应该检查 Origin 和 Referer 标头，否则就足够了吗？
对我来说似乎已经足够了。但是，为您的 Web 应用程序添加安全性的最佳方法是遵循 OWASP 指南。即使您认为它已经足够安全，您也可能会遗漏一些东西。所以，我建议你仍然使用Origin 或Referer 标头，甚至是同步器令牌

【解决方案2】：

我认为它不安全，因为您不能一次实施所有预防方法。当然，添加 CORS 支持、HTTP Only 标志和其他方法可能会阻止您被黑客入侵，但您并不完全安全。

我认为与其通过实施所有预防方法重新发明轮子，不如使用现有的标准包装器或中间件来防止对您的应用程序的 CSRF 攻击。这些代码比你能做的更好地清理输入。

您可以使用最好的（我最喜欢的包装器之一）https://github.com/ring-clojure/ring-anti-forgery 来防止 CSRF 攻击。如果您将 node 用于后端目的，这里是另一个最好的中间件，https://github.com/expressjs/csurf。

我不会说自己编写整个代码来防止 CSRF 攻击是不可能的，但我认为使用现有标准代码片段并专注于开发功能的聪明方法将节省更多时间。

【讨论】：

嗨 Rewanth，感谢您的回答。它的主要问题是前端应用程序是一个绝对独立的应用程序，所以我不能使用这个解决方案（后端的 CSRF 令牌隐藏字段注入），因为后端不呈现前端 HTML，它只提供 REST API。