前端安全: 如何防止 XSS 攻击?
分享简介
今天想分享给大家的是 如何防止 XSS 攻击.
为什么想分享的原因是: 感觉大家对前端安全了解不够, 重视不够.
内容是:
什么是 xss, 常见 xss 的类型. 并且通过小游戏来实践.如何去防止 xss 攻击
如何利用 XSS 进行攻击
什么是 XSS 攻击
Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。
XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
XSS 有哪些类型
存储型反射型DOM 型存储型
场景: 用户发表评论, 论坛发帖, 用户私信等
攻击者将恶意的代码, 提交到数据库中.后端服务器, 从数据库中获取的内容拼接成 html, 返回给浏览器用户打开页面, 混入其中的恶意代码被浏览器执行.恶意代码获取浏览器端的关键信息发送给攻击者的服务器
<% @ments.each.do |_c| %><%= ment %><% 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 中的恶意代码并执行。恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作
/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, outerHTMLdocument.writeeval
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))# /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 是我们认为是可以不经过转义直接输出的 /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 的cookiedocument.cookie;
总结
XSS 攻击的类型
存储型反射型dom 型
如何防止 XSS 的攻击
过滤恶意的输入转义输出浏览器限制
实际工作中, 可以直接使用成熟的库.
参考
大部分借鉴: 前端安全系列（一）：如何防止 XSS 攻击？前端安全系列之二：如何防止 CSRF 攻击？Preventing Cross-site Scripting Vulnerabilities When Developing Ruby on Rails Web Applicationsruby on rails securityPrevent Cross-site Scripting Attacks with Rails 2.3.5 and rails_xssUnleashing an Ultimate XSS PolyglotCross_Site_Scripting_Prevention_Cheat_SheetRuby_on_Rails_Cheat_Sheet驱散前端安全梦魇——DOM XSS 典型场景分析与修复指南google app security xssBasics_of_HTTP Data_URIsvue 安全安全 别用 raw 和 html_safeReplace “raw” & “html_safe” with “sanitize” for security reasons #532如果觉得《前端安全: 如何防止 XSS 攻击?》对你有帮助，请点赞、收藏，并留下你的观点哦！
