使用CSP + localStorage保护CSRF和XSS的单页面应用程序 [英] Securing Single-page-application from CSRF and XSS using CSP + localStorage

问题描述

我有一个单页应用程序，具有敏感内容，需要保护。这个问题特别针对XSS和CSRF攻击提供保护。

I have a single page application, having sensitive content, and needs to be secured. This question is specific with securing against XSS and CSRF attacks.

说明：有人建议使用很多地方，例如这里在localStorage上使用cookies，同时存储身份验证令牌。另一个问题还提供了一个非常好的解释此处。

Explanation: It has been suggested many places, for example here to use cookies on top of localStorage while storing the auth-token. A very nice explanation is also provided in answer of another question here.

根据这些答案，对于安全内容，建议使用带有'httpOnly'和'secure'选项的cookie来避免XSS;并实施CSRF保护（如 asp.net中的反伪造令牌）（注意我不是在Asp .net上，而是在java堆栈上）。

Based on these answers, for secured contents, it is suggested to use cookies with ‘httpOnly’ and ‘secure’ options to avoid XSS; and implement CSRF protection by ourselves (something like anti-forgery-token in asp.net) (Note that I am not on Asp .net, but at java stack).

认为这些博客和对话有些陈旧，而且随着时间的推移，情景有所改变。现在有了严格的内容 - 安全政策标题[CSP] ，XSS攻击的风险可能是最小化。此外，CSP还在现代浏览器中受到很大支持。考虑到使用CSP的XSS安全性，现在我觉得，使用localStorage而不是cookie来避免CSRF是一个不错的选择。

Thought these blog and conversation are somewhat old, and with time, the scenario has changed somewhat. Now with Contents-Security-Policy header [CSP] with strict policy, risk of XSS attack can be minimized significantly. Also CSP is largely supported in modern-age browsers. Considering XSS security with CSP, now I feel, it is good option to use localStorage instead of cookies to avoid CSRF.

问题：你是否想想使用LocalStorage + CSP（无手动实现）的任何不利/安全漏洞

Question: Do you think of any disadvantage/security loophole for using "LocalStorage + CSP (no manual implementation)"

超过

Cookie [http只有和安全] +手动实施CSRF反伪造令牌？

Cookies [httpOnly and secure] + "Manual" implementation of CSRF anti-forgery-token?

代价：

除了CSP响应标头之外，您还可以考虑按照此处。

In addition to CSP response header, you can consider that X-XSS-Protection header is still supported as per suggestion over here.

您可以认为该网站是HTTPS，已经实施了HSTS，HPKP安全标头。

You can consider the site is HTTPS, have having implementation of HSTS, HPKP security headers.

推荐答案

XSS

是漏洞在您的应用程序中，允许攻击者让您的常规访问者无理由执行n第三方控制的javascript。

Is a vulnerability in your application that allows attackers to have your regular visitors unwarranted execution of 3rd party controlled javascript.

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

The protection form that has to come from filtering all user supplied input (even if it's stored in a database) before outputting it in the context of the output by escaping the needed characters that create the problem in the given context.

身份验证令牌是XSS攻击的许多潜在目标之一，并将它们存储为http_only有助于保护他们，但远远不足以阻止攻击者。

Authentication tokens are one of the many potential targets of a XSS attack, and storing them as http_only helps in protecting them, but it is by far not enough to keep attackers out.

CSRF

跨站点请求伪造本质上是您的应用程序中的漏洞，其中授权用户遵循例如链接第三方网站，使他们在不知不觉中对您的应用程序执行更改。

Cross site request forgery is essentially a vulnerability in your application where an authorised user follows a link on e.g. a 3rd party website that makes them unknowingly execute a change on your application.

传统保护涉及生成一个密钥，您可以在每个可以进行更改的表单中的隐藏字段中输出（并转换每个更改的按钮）形式与所述保护）。
密钥必须经常更改，以便攻击者无法知道它们，猜测它们等等，同时它保持足够长的时间，以便用户有时间填写表单。
通常它们可以与会话一起生成，但是您不会将它们存储在客户端上，只在每个表单中输出它们并在接受帖子输入之前检查它们是否在那里。

The traditional protection involves generating a "key" that you output in a hidden field in every form that can make a change (and convert every button that makes a change in a form with said protection). The key has to change often enough so that an attacker cannot know them, guess them etc. while it stays long enough the same that the user has time to fill out the form. Typically they can be generated along with a session, but you do NOT store them on the client, only output them in every form and check they are there before accepting the input of a post.

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

Using local storage to store that CSRF key (if you are sure all your visitors support it) would be a possibility but you add problems if the assumption that all browsers support it is not true (they'll all generate CSRF violations)

HTTP_ONLY

表示浏览器被指示不允许javascript访问此cookie。
这有助于最大限度地减少XSS攻击对此cookie的访问（但不会影响攻击者感兴趣的其他内容）

Means the browser is instructed to not let javascript access to this cookie. This helps somewhat to minimise access by XSS attacks to this cookie (but not to other things of interest to the attacker)

安全

表示浏览器被指示仅在使用https连接时将此cookie发送到服务器（而不是在非https连接上将其发送到同一服务器） （可以在途中截获）。

Means the browser is instructed to only send this cookie to the server when using a https connection (and not also send it on a non-https connection to the same server (where it could be intercepted along the way).

将它组合在一起

使用身份验证令牌作为cookie，使用https_only和安全选项。
如果您确定所有客户端都能够本地存储，您可以将CSRF密钥添加到本地存储并添加提取它并发送它的JavaScript以各种形式和每个进行更改的按钮连接到服务器。如果你将两个密钥分开，你就可以获得两全其美的效果。
但是你还是要检查CSRF密钥是否存在并且每个密钥都有效请求更改任何内容。

Use the authentication token as a cookie, with https_only and secure options. If you are sure all your clients are capable of local storage, you can add a CSRF key to local storage and add javascript that extracts it and sends it to the server in every form and on every button that makes a change. If you keep both keys separate you get the best of both worlds. BUT: you still have to check the CSRF key to be present and valid on every request that changes anything.

我个人认为这是t很快，只需在服务器生成的每种形式中使用传统的CSRF密钥，现在比依赖关于浏览器的假设和/或提供与旧东西相同并且必须维护2种方法的回退机制更容易。

Personally I feel this is too soon, and just using a traditional CSRF key in every form generated by the server is for now easier than having to rely on assumptions about browsers and/or providing fallback mechanisms that do the same as the old thing and having to maintain 2 methods.

CSP

CSP很不错，但到目前为止还没有出现在每个浏览器中那里。如果你依靠它来阻止XSS，我会认为它是一种腰带和吊带的方法，而不是唯一的解决方案。原因很简单：有一天你会得到太多的负载并决定使用CDN ......现在需要允许CDN加载图像，脚本等等。现在XSS门对该CDN的任何其他用户开放。 ..也许那个开门的人甚至不认为XSS是他们需要担心的事情。

CSP is nice, but by far not in every browser out there. And if you rely on it to stop XSS, I'd consider it as a "belt and suspenders" approach, not as the only solution. The reason is simple enough: someday you get too much load and decide to a a CDN ... oops now the CDN needs to be allowed to load images, scripts etc. and now the XSS door is open to any other user of that CDN ... Maybe the one opening that door didn't even consider XSS as something they would need to worry about.

此外，上下文敏感的输出过滤并不难写，并且它使任何地方输出几乎任何东西更安全，并让过滤器负责编码（例如，你的URL将在需要的地方进行urlencoded，你的html标签的属性得到适当的转义，你的文字可以包括&和<不必担心任何事情。

Moreover context-sensitive output filtering isn't that hard to write and and it makes it much safer to output just about anything anywhere and have the filters take care of encoding (e.g. you URLs would get urlencoded where needed, your html tags' attributes get properly escaped and your text can include & and < without having to worry about anything anymore.

这篇关于使用CSP + localStorage保护CSRF和XSS的单页面应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！