具有 CSRF 和 XSS 保护的无状态 REST API

Question

有可能保护无状态REST API免受XSS和CSRF攻击吗？

目前，我使用存储在secure/httpOnly cookie中的JWT令牌进行无状态身份验证。这应该可以保护API免受最常见的XSS攻击：使用XSS注入的JavaScript窃取Cookie并将其发送给攻击者。

然而，这并不能保护API免受CSRF攻击，在这种攻击中，攻击者会欺骗经过身份验证的用户跟踪特定web API调用的链接，从而代表受害者执行不利的交易。我如何在不引入服务器端状态的情况下保护API免受这种攻击？

此外，在以下情况下，XSS 漏洞是否真的允许 CSRF 类型攻击：注入的 JavaScript 将从客户端状态、DOM 或浏览器存储中检索 CSRF 令牌，并准备对服务器的恶意 ajax 调用。浏览器仍会自动包含同一来源请求的 httpOnly cookie。除了首先防止XSS漏洞之外，有没有办法保护它？

Answer 1

您可以生成一个令牌（例如 UUID）并将其放入 jwt 令牌中，然后将其发送回客户端。然后，客户端在标头中的每个请求期间发送它。然后，服务器可以比较标头中的令牌和 jwt 令牌中的令牌，以确保请求来自被姨妈化的客户端。

Answer 2

第一个问题是关于在没有服务器端状态的情况下防止CSRF。无状态防伪令牌的当前方法是双重提交 cookie 模式。

CSRF攻击依赖于浏览器自动将API自己的cookie发送回给它，而不管请求来自何处。攻击者没有或不需要访问cookie内容。他们只需要诱骗用户加载恶意超文本标记语言。双cookie模式增加了一项新要求：攻击者必须知道并单独发送防伪cookie的内容。

攻击者可以用自己的方法覆盖防伪cookie。因此，您可能希望针对这种方法进行一些额外的安全强化。特别是HMAC在防伪令牌上签名，防止令牌被替换。使用HSTS和< code>__Host cookie前缀来确保传输安全和正确的cookie范围。以及让客户端在自定义报头中提供防伪令牌。

自定义标头确保请求必须从JS发送，因为基于HTML标记的CSRF攻击无法设置自定义标头。从JS发送也会触发附加保护。对于跨源请求，它会触发浏览器上的SOP和服务器上的CORS验证。服务器还可以执行基本的Origin验证。

关于CSRF攻击的范围，这里有一个来自OWASP CSRF链接顶部的说明。

强迫受害者检索数据对攻击者没有好处，因为攻击者没有收到响应，而受害者会。因此，CSRF 攻击以状态更改请求为目标。

是的，XSS攻击可能会以这种方式发生。一旦恶意脚本被加载到JS中，它就可以自由使用Javascript可访问的任何内容。包括应用程序代码/内存、浏览器存储和cookie。即使Http比如说cookie不可读，它们仍然可以在请求中发送。非目标攻击可能会在流行框架使用的位置寻找关键数据。并且可能会尝试探测服务器上流行/可发现的API框架。有针对性的攻击意味着攻击者研究了您的系统并为其制作了一个自定义的有效负载。

XSS的主要载体是未整理的外部数据(用户输入、数据库值等)。).为了预防XSS，请查看OWASP的这些指南。值得注意的是，前端框架，如Angular，React，Svelte，Vue等都内置了XSS保护。因为它们在呈现数据之前对数据进行净化。示例:攻击者在输入中输入一个HTML字符串。当稍后显示时，这些框架对字符串进行HTML编码。因此，左右尖括号被替换为< code >

XSS攻击也可能来自外部资源。也许是一个妥协的CDN或NPM脚本。如果您部署的代码依赖于NPM库，请格外注意NPM审计警告。一种攻击模式是附加一个小型加载程序(更容易被忽略)，它将在运行时获取攻击负载。CSP政策有助于防止这种情况。指定一个允许的资源列表——你的应用资产和API URLs并阻止所有其他资源。CSP还可以防止数据泄露。

对于对API的攻击，您还可以使用服务器端缓解措施。基于IP的限制/临时禁令、异常活动灰色列表和警报等。

对于特别敏感的操作，一种策略是使用升级的授权。这可以采取要求用户重新进行身份验证或使用第二个因素（如一次性密码）的形式。这可以阻止自动攻击，因为它需要主动用户干预。

为了减轻攻击者使用现有的升级授权（也可能在cookie或应用程序内存中），它们可以有短暂的过期时间，并仅限于特定操作。更进一步，可以对批准的操作相关数据进行签名。这将防止恶意脚本重用升级来执行具有不同数据的相同类型的操作。更进一步，这些敏感操作可以是幂等的。因此，如果攻击者确实重新发送了已经执行的操作，它们不会在系统中引起任何额外的更改。

试着设计你的系统，使其尽可能地让黑客感到无趣。使用可信的外部服务满足敏感需求，如信用卡和凭证。理想情况下（从安全角度来看），黑客攻击风险将减少到数据破坏/丢失。因此，在发生违约的最坏情况下，它不会产生什么长期影响。而且可以使用常规做法（包括例行测试的备份）来恢复它。然后针对所使用的特定攻击添加了进一步的缓解措施。

在用户对用户的交互中特别小心。因为这为黑客增加了更多的目标和枢轴点——你的用户群。最有安全意识的眼睛应该放在这些碎片上。不仅适用于用户对用户 XSS 攻击等技术危险，还适用于社会危险。人性的弱点是最广为人知的，也是最容易利用的。

最后，投资于在您的情况下风险/后果较低的缓解措施是没有意义的。因此，不要将此处的所有内容都作为需求清单。无论如何，这不是一个完整的列表。首先关注您最大的风险。定期重新评估。