前端安全: 如何防止 XSS 攻击?
前端安全: 如何防止 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=
<input type="text" value="<%= params[:keyword] %>">
<button>搜索</button>
<div>
您搜索的关键词是：<%= params[:keyword] %>
DOM 型
场景: 网站搜索, 分享链接, 恶意邮件等
DOM 型其实算上反射型的一种.
DOM XSS 是由于浏览器解析机制导致的漏洞，服务器不参与，而存储型与反射型都需要服务器响应参与.
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- 用户打开带有恶意代码的 URL。
- 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作
https://www.abc.com/hello#
<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 是 , 则它会被转义成为如下 HTML：
<script>alert("hi")</script>
但是, 注意 url 的问题, vue 不会处理.
我们可以使用sanitize-url进行处理;
<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