针对CSRF和XSS的保护（哈希+加密）

Question

保安。今天，任何应用程序如果没有适当的安全性编程--无论是由开发人员使用的框架，还是由开发人员自己编程--都无法在internet上生存。我目前正在开发一个使用承载令牌身份验证的RESTful API，但一直在阅读有关XSS和CSRF攻击的内容。

问题1）从我所读到的内容中，我看到使用基于令牌的身份验证的RESTful API的应用程序容易受到XSS而不是CSRF的攻击，如果令牌存储在浏览器的LocalStorage/SessionStorage中而不是Cookie中。这是因为，为了让CSRF工作，应用程序必须使用Cookie。我说得对吗？

问题2）在使用RESTful API的应用程序中，有一种方法可以防止这两种攻击。我偶然发现了这篇文章。这篇文章的要点是，在用户登录并请求承载令牌时，让服务器也返回一个httponlycookie，该cookiecsrfprotectioncookie。我相信本文中的解决方案非常健壮，提供了强大的保护。同样，我是正确的吗？您的观点是什么？

上面文章中提到的方法要求我将CSRFProtectionCookie持久化到某种数据库中。我不想那样做。我不希望数据库在每次向API发出经过身份验证的请求时都被击中。相反，我能做的是：

登录

1. 用户使用用户名和密码向令牌endpoint发送POST请求
2. 授权服务器验证用户凭据并开始使用某些声明构建JWT。
3. 作为JWT构建的一部分，它还生成一个随机字符串，对其进行散列，并将其作为CSRF声明添加到jwt.
4. 此外，接下来服务器将设置一个httponlycookie，名为xsrf-token，其值是相同的随机字符串，但这次加密了。
5. 将响应返回给浏览器。浏览器获取承载令牌作为响应主体，并设置xsrf-tokencookie。

经过身份验证的请求

问题是的，这消除了将任何内容持久化到数据库的需要（还是这样做了？我是否遗漏了一些漏洞？）。但是在每个用户请求上解密和验证哈希值的开销是多少？是否比数据库I/O的开销更大？此外，任何其他的建议，这种方法或其他方法是欢迎的！

谢谢：）

Answer 1

从我所读到的内容中，我看到，如果令牌存储在浏览器的LocalStorage/SessionStorage中而不是Cookie中，使用RESTful API并使用基于令牌的身份验证的应用程序容易受到XSS而不是CSRF的攻击。这是因为CSRF要工作，应用程序必须使用cookie。我说得对吗？

或多或少正确。只使用cookie进行身份验证且没有任何CSRF保护的应用程序将易受CSRF攻击，因为cookie会自动包含在所有请求中。

但是现在令牌存储在LocalStorage/SessionStorage中，应用程序容易受到XSS攻击。

1. 使用http专用cookie（最好还使用secure-作者没有提到这一点-这可以防止浏览器在http请求上发送cookie，仅发送https请求）作为身份验证令牌。这样，JavaScript就无法读取cookie，从而无法在XSS攻击中获取cookie。
2. 使用会话存储存储CSRF保护令牌。这里的好处是，一些JavaScript代码必须读取该值并将其放入请求中。恶意代码运行在某个第三方、受损的站点上，将无法从本地存储中读取CSRF令牌，因此无法创建有效的请求。

本文还详细介绍了如果静态资源位于不同于RESTendpoint的域中，如何设置跨域头。

然而，你的方法与文章所说的相反。您将身份验证令牌放在localStorage中，并将CSRF令牌放在cookie中。我建议把它倒过来，因为身份验证令牌比CSRF令牌更重要，而且对坏人来说，HTTP专用安全的cookie比LocalStorage更难获得。

你在沿着一条好的道路思考，这里。您所描述的将被称为“无状态CSRF令牌”。

您处理“经过身份验证的请求”的html" target="_blank">方法看起来不错。我不完全确定您是否需要加密CSRF令牌值，但这没有坏处。

这样就不需要将任何东西持久化到数据库中（还是这样做了？我是否漏掉了一些漏洞？）

实际上没有一个特定的框架可以完全防止XSS漏洞，因为它们可以以许多不同的方式表现出来。也就是说，您的web应用程序可以使用content-security-policy标头来帮助防止XSS攻击。CSP头可以用来告诉浏览器允许从哪些域加载资源（例如JavaScript文件）。它甚至可以用来阻止内置JavaScript的运行（这是XSS的主要攻击载体之一）。