前端安全: 如何防止 XSS 攻击?

分享简介

今天想分享给大家的是 如何防止 XSS 攻击.
为什么想分享的原因是: 感觉大家对前端安全了解不够, 重视不够.

内容是:

• 什么是 xss, 常见 xss 的类型. 并且通过小游戏来实践.
• 如何去防止 xss 攻击

如何利用 XSS 进行攻击

什么是 XSS 攻击

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。

XSS 有哪些类型

• 存储型
• 反射型
• DOM 型

存储型

场景: 用户发表评论, 论坛发帖, 用户私信等

• 攻击者将恶意的代码, 提交到数据库中.
• 后端服务器, 从数据库中获取的内容拼接成 html, 返回给浏览器
• 用户打开页面, 混入其中的恶意代码被浏览器执行.
• 恶意代码获取浏览器端的关键信息发送给攻击者的服务器

<% @post.comments.each.do |_c| %>
  <%= _c.comment %>
<% end %>

<%= link_to "Personal Website", @user.website %>

反射型

场景: 网站搜索, 分享链接, 恶意邮件等

反射型 XSS 漏洞常见于通过 URL 传递参数的功能。
由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。

• 攻击者构造出特殊的 URL，其中包含恶意代码。
• 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
• 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
• 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

http://xxx/search?keyword=<script>alert('XSS');</script>

<input type="text" value="<%= params[:keyword] %>">
<button>搜索</button>
<div>
  您搜索的关键词是：<%= params[:keyword] %>
</div>

DOM 型

场景: 网站搜索, 分享链接, 恶意邮件等

DOM 型其实算上反射型的一种.
DOM XSS 是由于浏览器解析机制导致的漏洞，服务器不参与，而存储型与反射型都需要服务器响应参与.

• 攻击者构造出特殊的 URL，其中包含恶意代码。
• 用户打开带有恶意代码的 URL。
• 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
• 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作

https://www.abc.com/hello#<img%20src=""%20onerror="alert('xss')">

<div id="box"></div>

<script>
  var hash = window.location.hash.slice(1);
  var box = document.getElementById('box');
  box.innerHTML = unescape(hash);
</script>

容易出现 xss 漏洞的 js 方法

• innerHTML, outerHTML
• document.write
• eval

XSS 小游戏

xss-game 讲前三个就够了

如何防止 XSS 攻击

XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。

防止的方式有:

• 过滤恶意的输入
• 转义输出
  • 纯前端渲染
  • 服务端渲染(模板渲染)
• 通过浏览器的限制

过滤恶意输入

前端过滤不靠谱, 主要还是由后端去处理. 并且过滤恶意输入适用范围有限.
适用于: 明确的输入类型，例如数字、URL、电话号码、邮件地址等等内容

例如: 5 < 7, 在数据库中存储成了 5 < 7

• 通过页面拼接 html 是可以的
• 通过 ajax 返回 json 对象, 直接会是 5 < 7, 不能够直接用户计算字符串长度, 展示标题等等

输入侧过滤能够在某些情况下解决特定的 XSS 问题，但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。

既然输入过滤并非完全可靠，我们就要通过防止浏览器执行恶意代码来防范 XSS。
方式有 2 种

• 转义输出
• 通过浏览器限制

转义输出

• 纯前端渲染
• 服务端渲染

纯前端渲染

在纯前端渲染中(例如 vue 项目)

Vue 的安全措施 中,提到 vue 的模板渲染, 默认提供转义; (v-html不会转义), 并且框架内部会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。

<h1>{{ userProvidedString }}</h1>

如果 userProvidedString 是 <script>alert('hi');</script>, 则它会被转义成为如下 HTML：

<script>alert("hi")</script>

但是, 注意 url 的问题, vue 不会处理.
我们可以使用sanitize-url进行处理;

<!-- 如果 evil_url 的值是 javascript:alert('xss') -->
<a :href="evil_url"></a>

服务端渲染

但对于性能要求高，或有 SEO 需求的页面，我们仍然要面对拼接 HTML 的问题。

rails security中提及到了sanitize.
它可以强有效地避免 xss 攻击.

tags = %w(a acronym b strong i em li ul ol h1 h2 h3 h4 h5 h6 blockquote br cite sub sup ins p)
s = sanitize(user_input, tags: tags, attributes: %w(href title))

# https://edgeguides.rubyonrails.org/3_0_release_notes.html#action-view
# You no longer need to call h(string) to escape HTML output, it is on by default in all view templates. If you want the unescaped string, call raw(string).

<%= name %>

<%= h(name) %>

#  html_safe 是我们认为是可以不经过转义直接输出的 https://groups.google.com/g/rubyonrails-core/c/T9N5wexIg80?pli=1
<%= name.html_safe %>

浏览器限制

CSP

Content Security Policy (简称 CPS)可以限制代码的执行.
只加载限定域名下 js 文件, 并同时不执行行内的 js 代码.

http-only

JavaScript document.cookie API 无法访问带有 HttpOnly 属性的 cookie；
此类 Cookie 仅作用于服务器。例如，持久化服务器端会话的 Cookie 不需要对 JavaScript 可用，而应具有 HttpOnly 属性。此预防措施有助于缓解跨站点脚本（XSS）攻击。

// 无法获取到设置 http-only 的cookie
document.cookie;

总结

XSS 攻击的类型

• 存储型
• 反射型
• dom 型

如何防止 XSS 的攻击

• 过滤恶意的输入
• 转义输出
• 浏览器限制

实际工作中, 可以直接使用成熟的库.

参考

• 大部分借鉴: 前端安全系列（一）：如何防止 XSS 攻击？
• 前端安全系列之二：如何防止 CSRF 攻击？
• Preventing Cross-site Scripting Vulnerabilities When Developing Ruby on Rails Web Applications
• ruby on rails security
• Prevent Cross-site Scripting Attacks with Rails 2.3.5 and rails_xss
• Unleashing an Ultimate XSS Polyglot
• Cross_Site_Scripting_Prevention_Cheat_Sheet
• Ruby_on_Rails_Cheat_Sheet
• 驱散前端安全梦魇——DOM XSS 典型场景分析与修复指南
• google app security xss
• Basics_of_HTTP Data_URIs
• vue 安全
• 安全 别用 raw 和 html_safe
• Replace “raw” & “html_safe” with “sanitize” for security reasons #532