我应该在Rest API端点上使用CSRF保护吗？

#1 楼

我原本的目标不是自我回答，但经过更多阅读后，我想出了一个我认为是全面的答案，这也解释了为什么有些人可能仍然对REST端点上的CSRF保护感兴趣。

没有cookie =没有CSRF

就这么简单。浏览器发送cookie和所有请求。 CSRF攻击取决于此行为。如果您不使用Cookie，并且不依赖Cookie进行身份验证，那么绝对没有CSRF攻击的空间，也没有理由进行CSRF保护。如果您有cookie，尤其是将它们用于身份验证，则需要CSRF保护。如果您仅想知道“我的API端点需要CSRF保护吗？”您可以在这里停下来并留下答案。否则，细节将摆在魔鬼面前。

对paj28的提示：虽然cookie是CSRF攻击的主要攻击媒介，但是如果您使用HTTP /基本身份验证，则也容易受到攻击。更一般而言，如果浏览器能够自动传递应用程序的登录凭据，则CSRF很重要。以我的经验，cookie是用于使CSRF发生的最常用技术，但是使用其他一些身份验证方法也可能导致相同的漏洞。

REST =无状态

如果您问某人“什么是REST”，您将获得讨论各种不同属性的各种答案。您可以看到很多，因为有人在堆栈溢出时问了这个问题：https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming

我一直依赖的REST的一个特性是它是无状态的。应用程序本身具有状态。如果您无法将数据存储在某个地方的数据库中，则您的应用程序将受到很大限制。但是，在这种情况下，无状态具有非常具体且重要的意义：REST应用程序不会跟踪客户端应用程序的状态。如果您正在使用会话，那么（几乎可以肯定）您正在跟踪客户端状态，并且您不是REST完整的应用程序。因此，使用通过cookie跟踪的会话（特别是用于登录）的应用程序不是REST-full应用程序（IMO），并且即使看起来像REST应用程序，也肯定容易受到CSRF攻击。

我认为值得一提的是，客户端无状态对于REST应用程序很重要的一个原因是，中间人缓存响应的能力也是REST范式的理想组成部分。只要应用程序正在跟踪客户端状态，就无法进行缓存。永远不需要会话，不需要Cookie，因此永远不需要CSRF安全性。但是，至少有一个用例仍然喜欢使用cookie：持久登录。

考虑一个典型的客户端（在这种情况下为浏览器，而不是移动设备）Web应用程序。从登录开始，登录使用REST API来验证用户凭据，作为回报，将获得一个令牌来授权将来的请求。对于单页应用程序，您可以只将该令牌保留在内存中，但是这样做会在用户关闭页面时有效地注销用户。因此，最好将状态保存在比单个浏览器会话持续时间更长的地方。本地存储是一种选择，但也容易受到XSS攻击：成功的XSS攻击可能导致攻击者获取您的登录令牌并将其发送给攻击者，以供其自行决定。因此，我看到一些建议使用Cookie来存储登录令牌。使用cookie可以设置仅http标志，这将阻止应用程序在设置cookie后读取它。结果，在发生XSS攻击时，攻击者仍可以代表您拨打电话，但他们无法一起摆脱授权令牌。 Cookie的这种使用不会直接违反REST的无状态要求，因为服务器仍未跟踪客户端状态。我只是在cookie中而不是在标题中查找身份验证凭据。应用程序来平衡各种安全性和可用性问题。我个人会尝试避免将cookie与REST API一起使用，但是很可能仍然有理由使用它们。无论哪种方式，总的答案都很简单：如果您使用Cookie（或浏览器可以自动执行的其他身份验证方法），则需要CSRF保护。如果您不使用Cookie，那么您就不会使用。

#2 楼

“浏览器无法自动提供身份验证凭据，即使通过某种方式被诱骗访问了API端点也是如此”


使用集成的Windows / Kerberos身份验证的专用网络上要小心。在这种情况下，如果配置为这样做，浏览器将自动提供凭据（kerberos或NTLM令牌）。

#3 楼

是否需要CSRF保护取决于两个因素：-

请求是否在执行状态更改操作（与REST API无状态性不同）-状态更改操作是将更改以下内容的任何操作应用程序的状态..例如删除某物，添加某物，更新某物。这些是应用程序将用来更改用户支持状态的操作。所有“发帖”请求和一些“获取”请求将属于此类别。 REST API可以更改状态。

浏览器是否提供了身份验证（不限于cookie）-CSRF之所以发生，是因为浏览器在请求中包含了身份验证信息，而不管请求是否由请求者启动。用户或其他打开的标签页。因此，浏览器可以自行包含信息的任何身份验证都需要CSRF保护。这包括基于cookie的会话和基本身份验证。

对于属于以上2类的所有请求，都需要CSRF保护。

#4 楼

我要在其他答案中添加的一件事是，仅在所涉及的Cookie的域和路径中才需要CSRF保护。或换一种说法：

授权！=身份验证
Cookies ==身份验证
令牌==授权

这与持久性登录的实现有关（您的第3点）。如果您将cookie附加到login.example.com（托管登录UI和/authorize端点），则可以每隔几分钟运行一次隐式OAuth流，而无需重新登录（例如，没有密码对话框）。客户端可以继续将获取的访问令牌发送给api.example.com，而无需CSRF，因为不会将cookie发送到该主机。但是您的登录/身份验证服务器最好是防弹的（并受CSRF保护）。

#5 楼

Rest API终结点与其他请求有一个非常重要的区别：它们特别是无状态的，绝不接受/使用cookie或会话中的数据。


如果这是定义“ REST API”的方式，则不可能使用CSRF。 CSRF，也称为“会议骑马” [citation]，如果没有要“骑马”的会议，显然将不起作用。

#6 楼

答：如果将令牌存储在localStorage中，并使用JS将其附加到您的请求中，它将自动保证CSRF保护（根据攻击的性质）

附录：
使用仅HTTP的cookie而不是localStorage更为安全（在XSS的情况下，使用CSRF保护的方式似乎会产生问题）：实际上并非如此。对于通过漏洞利用XSS来控制您网站上JS的攻击者来说，这只会变得更加困难。 br />
XSS是应用程序级别的漏洞，但可以通过使用声明限制令牌的功能（将其限制在最低限度内）来减轻其影响

#7 楼

我想补充一些对现有答案的特定警告。尽管Conor认为Cookie是沿着所有请求发送的本地存储身份验证数据的唯一形式是正确的，但它们并不是网站使用的本地存储身份验证数据的唯一形式。这意味着，如果站点决定将其JWT /会话令牌保留在LocalStorage或SessionStorage之类的内容中，则有时仍可以通过javascript自动将其删除，然后在无需用户交互的情况下使用它们。这意味着有时仍然可以通过将用户重定向到与域匹配的前端URI（然后发送凭据）来“一旦删除”来执行CSRF攻击。如果您已经反映了XSS，则可以通过更直接的方式来完成此操作，但是在某些情况下，这是不必要的，并且这些页面和脚本已经存在。 REST API；无论前端与之交互的端点上都没有令牌。