前端安全: 如何防止 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

你可能感兴趣的:(前端从看懂到看开,javascript,安全,前端,xss)