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

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

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

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

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

常见的攻击手段

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

1. 任意文件上传

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

2. 点击劫持

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

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

3. XSS攻击

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

4. SQL注入

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

5. Dos攻击(拒绝服务)

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

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

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

防范手段

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

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

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

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

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

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

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

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

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

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

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-TypeX-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-PolicyMDN Link Type

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

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

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

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

11. 定期审查npm依赖

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

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

12. 分离你的应用

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

相同的原理可以应用于前端。 例如,一个Web应用可以分为公共部分,身份验证部分和后台管理部分,每个应用都托管在单独的子域中,例如 https://public.example.comhttps://users.example.comhttps://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篇前端文章,大家有兴趣的话关注一下,我们一起交流前端知识~

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

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章