CSRF攻击是否适用于API？

Question

特别是，我正在编写一个Django RESTful API来支持iOS应用程序，每当我编写处理POST请求的方法时，我都会继续使用Django的CSRF保护。

我的理解是iOS管理的cookie不会被应用程序共享，这意味着我的会话cookie是安全的，没有其他应用程序可以使用它们。这是真的？如果是这样，我可以将所有API函数标记为CSRF免除吗？

Answer 1

这不是CSRF的目的。 CSRF旨在防止将数据直接发布到您的站点。换句话说，客户必须实际发布已批准的路径，即查看表单页面，填写表单，提交数据。

API几乎排除了CSRF，因为它的全部目的通常是允许第三方实体访问和操作您网站上的数据（CSRF中的“跨站点”）。所以，是的，我认为通常任何API视图都应该是CSRF豁免。但是， 仍应遵循最佳做法，并使用某种形式的身份验证（例如OAuth）保护实际进行更改的每个API端点。

Answer 2

CSRF攻击依赖于将cookie与所有请求一起隐式发送到特定域。如果您的API端点不允许基于cookie的身份验证，那么您应该很好。

即使您使用基于cookie的身份验证，您的Cookie也是安全的，因为iOS apps do not share cookies。但是，除非您通过要求不寻常的用户代理标头故意阻止Web浏览器，否则另一方可以构建使用您的API的基于浏览器的应用程序，如果您的API支持基于cookie的身份验证，该应用程序将容易受到CSRF攻击不适用CSRF保护。

Answer 3

如果您还使用API​​来支持网站，它们确实适用。

在这种情况下，您仍然需要某种形式的CSRF保护，以防止有人在其他网站中嵌入请求，以对经过身份验证的用户的帐户产生偷渡效果。

Chrome似乎默认拒绝跨源POST请求（其他浏览器可能不那么严格），但允许GET请求跨域，因此您必须确保API中的任何GET请求都没有副作用。

Answer 4

当前接受的答案（2012年5月）大多是正确的，除非您使用基于会话的身份验证。还值得一提的是CORS的作用。

简单的情况是您访问foo.com并且网站执行Javascript以向api.com/users/123发出基于AJAX的DELETE请求，并最终代表您删除该用户。现在，由于CORS，这并不总是可行的 - 浏览器会阻止foo.com向api.com发出请求，除非api.com明确列入白名单foo.com。这也假设您使用基于会话的身份验证API，而不是基于令牌的身份验证。在基于会话的身份验证中，登录到api.com的任何用户都可以在他们保持登录状态时执行请求。如果您具有基于令牌的身份验证（每个请求必须使用包含HTTP Authorization标头的请求来制作认证令牌）然后你是安全的。基于会话的身份验证通过cookie隐式发送身份验证令牌。

稍微糟糕的情况是，如果您的一个受信任的CORS域遭到入侵 - 比如说您有一个不清理Javascript的表单，并且用户设法通过该表单将JS注入您的站点。如果您使用基于会话的身份验证，则访问该页面的经过身份验证的用户将看到Javascript运行并发出API请求。如果您对API使用基于会话的身份验证，这可能是灾难性的，非常可能。

Answer 5

根据DRF documentation, API只要服务器使用经过身份验证的会话（而不是每次都要求密码），就容易受到CSRF攻击

解决方案是

1. 确保“安全”的HTTP操作，例如GET，HEAD和 OPTIONS不能用于更改任何服务器端状态。
2. 确保任何“不安全”的HTTP操作（例如POST，PUT，PATCH和DELETE始终需要有效的CSRF令牌。