仅使用“application/json”的AJAX POST请求是否需要CSRF令牌？

Question

如果我理解正确，如果您只允许来自“AJAX”（实际上是AJAJ）表单的application/json，那么就不需要CSRF令牌，对吗？

如果有人尝试使用一些巧妙的POST到iFrame hack从另一个页面发布表单，它将会是application/x-www-form-urlencoded，您可以立即将其丢弃。

如果有人尝试使用AJAJ发布表单，只有当OPTIONS具有允许它的CORS标头时才会成功。

结论：除非使用CORS，否则在使用application/json而不是application/x-www-form-urlencoded时，您将免于CSRF攻击。

还有其他任何我没有考虑到的矛盾之处吗？

- coolaj86

Answer 1

看一下这个Sec.SE问题和答案。简而言之: 目前来说你是正确的，但是依赖这种行为可能不是一个好主意，所以还是要使用 tokens。

- Michael

Answer 2

2022更新

许多事情已经改变 - 比如fetch更好地控制请求。

是的，它仍然很危险

可以做一个跨站点JSON POST，包括Cookie。

(攻击者无法看到响应，但他们可以成功发送POST)

默认情况下需要使用CSRF。

是的，很容易缓解

Same-Site Cookies

现在有一个same-site cookie option。正确使用此选项使得完全不需要使用CSRF令牌。

API Tokens

完全放弃Cookies，采用每个请求的API令牌，例如标准化的JWT，将使CSRF攻击无法发生。

最好的方法是将令牌路由与Cookie路由分开处理，如：

• /api/account/xxxx 用于经过身份验证的 JSON API。
• /api/assets/xxxx 用于 <img src="xxxx" /> 和其他不应在 URL 中包含令牌的资源，因此必须依靠 cookie。

- coolaj86

---

有一种情况下，同站点 cookie 可能无法保护您，这种情况比您想象的要常见一些：如果您允许其他服务托管在您网站的子域上，例如 helpdesk.mydomain.com - 并且您担心这些第三方供应商可能存在自己的安全漏洞。更多相关信息请参见此处：https://simonwillison.net/2021/Aug/3/samesite/#consider-subdomains - Simon Willison