使用CSP local存储从CSRF和XSS保护单页应用程序

Question

我有一个单页应用程序，其中包含敏感内容，需要保护。这个问题是针对 XSS 和 CSRF 攻击的。

解释：已经建议在很多地方，例如这里在存储身份验证令牌时在 localStorage 之上使用 cookie。在回答这里的另一个问题时也提供了一个非常好的解释。

基于这些回答，对于受保护的内容，建议使用带有‘http only’和‘secure’选项的cookies，以避免XSS；并且自己实现CSRF保护(类似ASP.NET的防伪令牌)(注意我不是在Asp。net，但是在java栈)。

我认为这些博客和对话有些陈旧，随着时间的推移，场景有所改变。现在有了具有严格策略的Contents-Security-策略标头[CSP]，XSS攻击的风险可以大大降低。此外，现代浏览器很大程度上支持CSP。考虑到CSP的XSS安全性，现在我觉得，使用local存储而不是cookie来避免CSRF是个不错的选择。

问题：您认为使用“LocalStorage CSP（无手动实现）”有什么缺点/安全漏洞吗

多

Cookies[httpOnly and secure]CSRF防伪令牌的“手动”实现？

考虑因素:

除了 CSP 响应标头之外，还可以考虑根据此处的建议仍支持 X-XSS 保护标头。

你可以考虑的网站是HTTPS，有HSTS，HPKP安全标题的实施。

Answer 1

CSP对我来说是一个相当新的概念，但据我所知，我的答案是：全部使用。我会尽力详细说明。

1. CSP相对容易实现。如果您处理的是敏感内容，那么实施它所增加的成本是值得的。它可以在支持它的浏览器上大大提高应用程序的安全性
2. 对于那些能够处理它的人来说，这是一顿免费的午餐——不理解标题的浏览器会忽略它
3. 然而，正因为如此，您需要有所有的标准措施
4. CSP不能阻止CSRF。即使您禁止所有脚本执行，如果没有使用每个请求令牌，CSRF攻击仍然是可能的

Answer 2

我最近在思考一个非常相似的问题——但是我的场景中的差异比你的案例有更大的影响。

具体地说，我在考虑一个OLTP应用程序，它使用可缓存的内容来存储所有HTML，并使用AJAX/SJAX JSON来检索事务数据。我还没有深入考虑使用传统的POST或AJAX/SJAX将事务数据发送回服务器。

对我来说，这种方法的优点(相对于传统的HTML / GET / POST OLTP)是，除了事务性数据之外的所有内容都可以缓存，从而实现了最佳的容量，并且基于预期的使用场景实现了性能优势。

它也是在站点上实现PJAX的网关，从而消除了从本地缓存中检索内容和解析的启动成本。但是我在胡扯一些与你的问题无关的东西。

您的非cookie方法类似地将可缓存内容与数据隔离开来-这并非严格意义上适用于所有单页应用程序，但由于页面级别转换较少，因此净收益并不大。

正如您所说，CSP降低了XSS攻击的可能性和影响，但它并没有消除它——在脚本存储在受害者站点上并向访问者重播的情况下。尽管没有真正的“跨站点”，但这仍然被描述为一种XSS攻击。而且它仍然允许伪造请求指向同一来源。

因此，除非你能完全确信你的CSP永远不会允许不安全的内联，否则我认为你仍然需要某种CSRF保护。Microsoft 解决方案简洁，因为它是无状态的 - 但依赖于单页应用程序的页面不可缓存（这消除了性能优势）。

Answer 3

XSS

是应用程序中的一个漏洞，使得攻击者能够让您的常规访问者未经授权执行第三方控制的javascript。

保护表单，它必须来自过滤所有用户提供的输入（即使它存储在数据库中），然后通过转义在给定上下文中创建问题的所需字符，将其输出到输出的上下文中。

身份验证令牌是XSS攻击的众多潜在目标之一，将它们存储为http_only有助于保护它们，但这还不足以将攻击者拒之门外。

CSRF

跨站点请求伪造本质上是您的应用程序中的一个漏洞，授权用户跟踪例如第三方网站上的链接，从而在不知不觉中对您的应用执行更改。

传统的保护包括生成一个“密钥”,你在一个隐藏的字段中输出一个可以改变表单的“密钥”(并转换一个表单中每个可以改变表单的按钮)。密钥必须经常改变，以使攻击者无法知道、猜测它们等。同时保持足够长的时间，以便用户有时间填写表单。通常情况下，它们可以与会话一起生成，但是您不需要将它们存储在客户端，只需要以每种形式输出它们，并在接受帖子输入之前检查它们是否存在。

使用本地存储来存储CSRF密钥（如果您确定所有访问者都支持它）将是一种可能性，但是如果假设所有浏览器都支持它（它们都会产生CSRF违规），则会增加问题

仅HTTP_

意味着浏览器被指示不要让javascript访问这个cookie。这在一定程度上有助于最大限度地减少XSS攻击对此cookie的访问（但不是攻击者感兴趣的其他内容）

保护

意味着浏览器被指示仅在使用https连接时将此cookie发送到服务器（并且不通过非https连接将其发送到同一服务器（在那里可能会被拦截）。

把它放在一起

将身份验证令牌用作 Cookie，具有https_only和安全选项。如果您确定所有客户端都能够进行本地存储，则可以将CSRF密钥添加到本地存储中，并添加javascript，该密钥将其提取并以各种形式和每个进行更改的按钮发送到服务器。如果您将两个密钥分开，则可以两全其美。但是：您仍然必须检查CSRF密钥是否存在，并且在每个更改任何内容的请求上都有效。

就我个人而言，我觉得这太早了，现在在服务器生成的每种形式中使用传统的CSRF密钥比依赖于对浏览器的假设和/或提供与旧东西相同的回退机制以及维护2种方法要容易得多。

芯片尺寸封装

CSP很好，但目前还不是每个浏览器都有。如果你依靠它来阻止XSS，我会认为它是一种“腰带和吊带”的方法，而不是唯一的解决方案。原因很简单：有一天你负载过大，决定使用CDN…哎呀，现在CDN需要被允许加载图像、脚本等，而现在XSS的大门对该CDN的任何其他用户都是敞开的……也许打开大门的人甚至不认为XSS是他们需要担心的事情。

此外，上下文相关的输出过滤并不是那么难写，它可以让您在任何地方输出任何内容，并让过滤器负责编码（例如，您的URL将在需要的地方进行urlencoded，您的html标签的属性将正确转义，您的文本可以包括