[译]让Web应用更安全的13个小技巧

无论你是React、Angular、Vue.js，还是原生JavaScript开发者，你的代码都有可能成为黑客眼中的猎物。

作为一个前端开发者，我们可能更加关注性能、SEO、UI/UX，往往会忽视安全问题。

当你了解了大型框架是如何让你对xss攻击保持开放态度时，也许你会感觉到很意外。例如，React中的dangerouslySetInnerHTML或者Angular中的bypassSecurityTrust都是一些高危操作。

我们需要记住，就安全而言，前端现在和后端、DevOps一样承担着相同的职责。前端也可能遭受到成千上万的恶意攻击。

常见的攻击手段

让我们来了解一下常见的攻击类型有哪些。

1. 任意文件上传

这种攻击方式是将恶意文件上传到服务器中并执行，从而攻击系统。攻击包括：文件系统或者数据库超载、完全接管系统、将攻击转发到后端系统或者简单的破坏。

2. 点击劫持

这是一种诱导用户点击非本站网页或元素的攻击方式。这种攻击可能导致用户在不经意之间提供证书或者敏感信息，下载恶意软件，访问恶意网页，在线购买产品或者被偷偷转移资产。

译者注：简单的说就是在用户观看到的网站上覆盖一层透明的恶意网站，诱导用户点击恶意网站上的按钮来触发攻击行为

3. XSS攻击

这是一种将恶意脚本JS脚本注入到网页中的攻击方式。网站上的缺陷使这些攻击得以成功并广泛传播。

4. SQL注入

这是一种通过用户输入将恶意的SQL注入到数据库中，进而破坏数据库的攻击方式。

5. Dos攻击（拒绝服务）

这是一种通过流量轰炸服务器，导致正常的用户无法正常访问服务器的攻击方式。

6. 中间人攻击或者会话劫持

这是一种拦截客户端和服务端之间的通信，从中窃取用户的密码、账号或者任何个人详细信息的攻击方式。

防范手段

攻击者将会不遗余力的在前端寻找安全漏洞，在本文中，我们将看到一些编写前端代码时安全相关的最佳实践。

1. 严格的限制用户的输入（第一个攻击点）

应该始终严格的对待用户输入，避免诸如SQL注入、点击劫持等等。因此，在将用户输入发送到服务端之前，校验并过滤用户输入是很重要的。

可以通过删除或替换危险的字符来过滤数据，例如，使用白名单并转义输入的数据。

但是，我意识到过滤和编码用户输入并不是一件容易的事，因此我们可以使用以下开源库：

• DOMPurify.仅仅使用一个函数就可以过滤用户的输入。同时，也支持自定义的规则，并且支持在HTML5、SVG、MathML中使用。
• secure-filters. 它提供方法去过滤HTML、JavaScript、内联CSS等等。当你想利用用户的输入生成JavaScript或者CSS时，这个库特别好用。

如果是文件上传，请务必检查文件类型并且使用文件过滤功能仅允许某些文件类型上传。

2. 注意隐藏保存浏览器内存中的数据或字段

如果我们利用type="hidden"来隐藏页面中敏感数据，或者把他们放到浏览器的localStorage、sessionStorage、cookies时，我们需要谨慎的考虑这些数据是否安全。

攻击者可以轻松访问添加到浏览器中的所有内容。攻击者可以打开开发工具并更改所有保存在内存中的变量。如果你根据localStorage、sessionStorage、cookies中的值隐藏了身份验证界面，该怎么办？

像ZapProxy这样的工具，可以在攻击者找到注入脚本的方法后，将这些值暴露给攻击者，然后攻击者可以使用它们进行进一步的攻击。

因此，避免使用type="hidden"，避免将密钥、身份验证令牌等尽可能多的存到浏览器的内存中。

3. 使用CSP

永远不要相信服务器返回的所有内容，在Http header中定义一个强大的CSP策略，仅仅允许受信任的内容在浏览器中执行。

最好有一个白名单列表，即使攻击者注入了脚本，该脚本和白名单不匹配，它也不会执行。

举个例子:

// header
content-security-policy: script-src ‘self’ https://apis.xyz.com

这里定义我们的Web应用仅仅信任https://apis.xyz.com和本身域名的脚本。对于其他域名的资源都会在控制台中报错。

注意：强大CSP策略也没办法解决内联脚本执行的问题，因此xss攻击仍然存在。

你可以在MDN网站上阅读更详细CSP说明。

译者注：不仅可以在header中设置csp规则，你也可以在meta标签中设置。

4. 开启XSS保护模式

如果攻击者通过某种方式在用户输入中插入攻击代码，我们可以通过"X-XSS-Protection": "1; mode=block"来告诉浏览器阻止响应。

大多数现代浏览器默认情况下都启用了XSS保护模式，但仍建议添加X-XSS-Protection。 这有助于提高不支持CSP的旧版浏览器的安全性。

5. 避免典型的XSS错误

Dom API innerHTML经常被用作XSS攻击的入口。例如：

document.querySelector('.tagline').innerHTML = nameFromQueryString

任何攻击者都可以使用上面的代码行注入恶意代码。

大家可以考虑使用textContent来代替innerHTML，避免直接生成HTML。如果你不生成HTML，那就不会有JavaScript插入到页面中，即使你可以在页面中看到攻击代码，但是，什么也不会发生。

密切关注Trusted Types(MDN地址)，这是由google程序员开发出来的，旨在防范所有基于DOM的XSS攻击的方案。

在React.js中，dangerouslySetInnerHTML可能产生和innerHTML类似的影响。

注意：不要直接将用户输入做了innerHTML的值，尽量使用textContent。

另外，我们应该正常的设置http响应头Content-Type和X-Content-Type-Options。例如，请勿将JSON数据编码成text/HTML，以免意外执行。

6. 禁用IFrame嵌入

禁用iframe可以帮助我们免受点击劫持攻击。我们应该在header中添加"X-Frame-Options": "DENY" ，来禁止浏览器在页面中渲染iframe。

我们也可以使用CSP指令frame-ancestors，它可以更好的控制我们的页面可以被哪些父页面通过iframe的形式来嵌套展示。

7. 通用的错误提示

类似"您的密码有误"这样的提示对用户很友好，同时，他对攻击者也很友好。他们可以通过服务端返回的错误信息来判断他下一步需要进行什么样的攻击。

当处理用户的账号、邮件、个人信息时，我们应该尝试使用一些模棱两可的错误提示，类似“错误的登陆信息”。

8. 使用验证码

在对外的公共服务（登陆、注册）上使用验证码。验证码的目的在于帮助我们区分真人和机器人，并且也可以阻止DoS攻击。

9. 设置Referrer-Policy

当我们使用<a>标签或者超链接引导用户离开我们的网站时，确保你在请求header里面添加了"Referrer-Policy": "no-referrer"，或者在<a>标签中添加了rel="noopener" 或rel="noreferrer"属性。

当我们不设置header或者rel属性时，目标网站就可以获取到一些用户相关的数据。

译者注：rel=noopener保证跳转过去的网站无法通过window.opener窃取原来网页的信息。rel=noreferrer作用是防止将引用者信息传递到目标网站。上面提到的策略大家可以去mdn上了解一下MDN Referrer-Policy、MDN Link Type

10. 限制浏览器的功能或者API

就像CSP可以限制可信的资源域名一样，我们也可以限制浏览器提供哪些能力给我们用。我们可以利用http header中的Feature-Policy字段来限制使用浏览器提供的功能。

提示：禁用一切你不使用的功能

译者注：Feature-Policy是一个实验中的header属性，目前在chrome浏览器中的兼容性尚可，IE和Safari都不支持。具体可以在MDN Feature-Policy中了解。

11. 定期审查npm依赖

经常跑一下npm audit来获取存在漏洞的npm包列表，升级他们避免一些安全问题。

GitHub现在会标记出哪些存在漏洞的依赖。我们也可以使用Snyk来自动检查你的源码，并且自动升级版本号。

12. 分离你的应用

与后端一样，我们也拥有微服务架构，其中，将单一的Web应用转变为多个小型前端应用的聚合，每个小型前端应用可以单独运行。

相同的原理可以应用于前端。 例如，一个Web应用可以分为公共部分，身份验证部分和后台管理部分，每个应用都托管在单独的子域中，例如https://public.example.com、https://users.example.com和https://admin.example.com。这将减少web应用中的漏洞。

注意：适当的分隔还可以防止应用程序公共部分出现XSS漏洞，从而防止它自动破坏用户信息。

13. 尽量避免使用第三方服务

一行代码就可以使用类似Google Analytics的第三方服务，同时，也可能会给你的应用带来漏洞。想一想这些第三方服务脚本被篡改的情况。

拥有一套健全的CSP策略很重要。大多数第三方服务都有定义的CSP指令，因此请务必添加它们。

同样，如果可能的话，请确保给你的script标签都加上integrity属性。子资源完整性功能（SRI）可以验证脚本的hash值，并确保其未被篡改。

<script src= "https://example.com/example-framework.js" integrity= "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..." crossorigin= "anonymous" ></script>

译者注：将使用base64编码过后的文件哈希值写入你所引用的 <script> 或 <link> 标签的 integrity 属性值中即可启用子资源完整性校验功能。

仔细考虑自动填充字段

存储在浏览器的自动填充里面的用户个人数据对用户和攻击者都很方便。

攻击者添加了第三方的脚本，利用浏览器的自动填充来提取用户的邮箱地址去构建追踪标识。他们可以使用这些信息建立用户浏览历史记录配置文件，然后将其出售给坏人。

我们许多人甚至都不知道他们的浏览器自动填充功能存储了哪些信息。

提示：禁止将敏感信息自动填入表单

译者注：MDN中也有一个web安全相关的专题，大家有兴趣可以关注一下MDN web security

关于我

我是一个莫得感情的代码搬运工，每周会更新1至2篇前端相关的文章，有兴趣的老铁可以扫描下面的二维码关注或者直接微信搜索前端补习班关注。

精通前端很难，让我们来一起补补课吧！

好啦，翻译完毕啦， 原文链接在此。