前端常见的安全问题汇总

发表于 更新于 分类于
本文字数： 1.5k 阅读时长 ≈ 3 分钟

背景

最近安全部门的小伙伴提了一个前端安全的漏洞，想到前端开发过程中有时候往往追求开发效率，忽略掉一些安全问题，以下简单总结一些自己遇到过的以及一些常见的攻击手段，以自查自省。

XSS

回到安全部门提出的漏洞，场景还原如下：
这是一个老项目，展示文章用，页面路由为 http://xxx/article/:id?these-are-queries，node 层收到这个 url 后，返回返回该文章 html，内容则包括了【推荐文章】， 而推荐文章的链接则是根据 url 的值来的，仅变化 id。此时如果在 url 上的 query 上构造一段恶意脚本，然后引导用户打开，那么用户打开页面后就会运行该恶意脚本。
上述正是一个典型的 XSS 攻击，定义如下：

XSS是跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

XSS 的本质是信任了某些不安全的输入，导致恶意代码混入正常代码，进而发生的攻击行为。常见的不安全输入有：

  1. 上面提到的 url 参数，这种需要诱导用户取点击
  2. 用户输入的内容，比如用户发表评论
  3. 第三方的链接等

防范的方法通常是：对用户输入内容和服务端返回内容进行过滤和转译。

CSRF

CSRF 攻击常见的过程如下：

  1. 用户登录你的网站，产生登录凭证，如 cookie
  2. 用户被诱导登录到恶意网站
  3. 恶意网站携带刚刚在浏览器产生的凭证向你的服务器发送一个恶意请求
  4. 你的服务器无法识别是否恶意请求，请求完成，用户受害。

与上面提到的 XSS 攻击有个明显的区别在于：CSRF 攻击发生在恶意网站，而不是被攻击的网站。而这也使得攻击者并不能获取到受害者的登录凭证，仅仅只能使用。
防范的方法通常是：

  1. 请求 url 添加 token 或者是在 http 请求头自定义属性进行验证
  2. 同源检测，通过解析 请求头中的 referer 判断请求来源
  3. Samesite，Google 起草了一份草案来改进 HTTP 协议，为 Set-Cookie 响应头新增 Samesite 属性，用于标明 Cookie 是否能作用于其他网站，目前兼容性还不是很好。

Iframe

当我们使用 iframe 加载第三方网站时，第三方网站可以对我们的网站执行恶意操作，如操作DOM，加载 js 等。
防范的方法是通过设置 sandbox 属性控制 iframe 的操作权限。

opener

我们在通常通过以下写法在 新 tab 下打开链接：

1. <a target='_blank' href='new-site.com'>
2. window.open('new-site.com')

上述两种写法的问题在于， new-site.com 是可以通过 window.opener 来拿到源页面的 window 对象，进而进行恶意操作。
防范的方法通常是：

1. <a target="_blank" href="new-site.com" rel="noopener noreferrer nofollow">a标签跳转url</a>
2. function openurl(url) {
    var newTab = window.open();
    newTab.opener = null;
    newTab.location = url;
}
参考