用HTML和JavaScript模拟XSS攻击

HTML文件:

<!DOCTYPE html>
<html>
<meta charset="utf-8">
<title></title>
<body>
<form method="post">
<input type="text" name="input"/>
<input type="submit" onclick="onSubmit(input.value)" value="提交"/>
</form>
</body>
<!-- <script src="./xss.js"></script> -->

</html>
<script>

function onSubmit(value) {
document.write(value)
console.log(value)
}
</script>

然后在网页中的 input 框输入普通字符串:

image-20201029175836887

网页上显示正常字符串 123

接着输入 JavaScript 代码:<script>alert('XSS攻击')</script>

image-20201029180138872

提交之后显示:

image-20201029180209237

打开调试页面:

image-20201029180342204

甚至可以从远端加载 JavaScript 文件进行攻击,我这里加载的是同级目录下的 xss.js 文件:

// xss.js
let i = 5
while(i > 1){
alert('反射型XSS攻击')
i--
}

输入框中输入 <script src="./xss.js"></script>,提交后会显示4次警告框:

image-20201029180755869

XSS 注入的方法

  • HTML 内嵌文本中,以 script 标签注入代码
  • 在内联 JavaScript 中,拼接的数据突破了原本的限制
  • 在标签属性中,恶意内容包含引号,突破属性值的限制,注入其他属性或标签
  • 在标签的 href 、src 属性中,包含 javascript:可执行代码
  • onload onerror onclick等事件中,注入不受控制的代码
  • background-image:url("javascript:..."); 的代码(新版本浏览器已经可以防范)
  • 在 style 属性和标签中,包含类似 expression(...) 的 CSS 表达式代码(新版本浏览器已经可以防范)

XSS 攻击分类

  • 存储型

    攻击步骤:

    1. 攻击者将恶意代码提交到目标网站的数据库中。
    2. 用户打开目标网站时,网站服务端将恶意代码从数据库取出,拼接在 HTML 中返回给浏览器。
    3. 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

    常见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等

  • 反射型

    攻击步骤:

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

    常见于通过 URL 传递参数的功能,如网站搜索、跳转等

  • DOM 型

    攻击步骤:

    1. 攻击者构造出特殊的 URL,其中包含恶意代码。

    2. 用户打开带有恶意代码的 URL。

    3. 用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行

    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

DOM 型 XSS 跟前两种 XSS 的区别:DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。

XSS 攻击防范

XSS 攻击的本质是:恶意代码未经过滤,与正常的代码混在一起被执行,由于直接在终端执行,所以能够直接获取用户信息,或者利用这些信息冒充用户发起请求

来源:

  • 来自用户的 UGC 信息
  • 来自第三方的链接
  • URL 参数
  • POST 参数
  • Referer (可能来自不可信的来源)
  • Cookie (可能来自其他子域注入)

大致过程为:攻击者提交恶意代码,浏览器执行恶意代码

前端过滤用户输入

一旦绕过前端过滤,直接构造请求,就无法防范

后端过滤用户输入
  1. 用户的输入内容可能同时提供给前端和客户端,而一旦经过了 escapeHTML(),客户端显示的内容就变成了乱码( 5 < 7 )。

  2. 在前端中,不同的位置所需的编码也不同。

    • 5 < 7 作为 HTML 拼接页面时,可以正常显示:
    <div title="comment">5 &lt; 7</div>
    • 5 < 7 通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示,也不能直接用于内容长度计算。不能用于标题、alert 等。

所以,输入侧过滤能够在某些情况下解决特定的 XSS 问题,但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。但对于数字、url、电话邮件地址等可以进行过滤。

防止浏览器执行恶意代码

存储型和反射型 XSS 攻击

  • 纯前端渲染

    明确告诉浏览器下面的内容是文本(.innerText),还是属性(.setAttribute),样式(.style

    无法预防 DOM 型 XSS 漏洞 (onloadonerrorhref:javascript:xxx

  • HTML 转义

    采用转移策略,对特殊字符进行转义。转义库:org.owasp.encoder

DOM 型 XSS 攻击

小心使用.innerHTML.outerHTMLdocument.write(),尽量用 .textContentsetAttribute()

  • 如果用 Vue/React 技术栈,并且不使用 v-html/dangerouslySetInnerHTML 功能,就在前端 render 阶段避免 innerHTMLouterHTML 的 XSS 隐患

其他防范方法

Content Security Policy

严格的 CSP 在 XSS 的防范中可以起到以下的作用:

  • 禁止加载外域代码,防止复杂的攻击逻辑。
  • 禁止外域提交,网站被攻击后,用户的数据不会泄露到外域。
  • 禁止内联脚本执行(规则较严格,目前发现 GitHub 使用)。
  • 禁止未授权的脚本执行(新特性,Google Map 移动版在使用)。
  • 合理使用上报可以及时发现 XSS,利于尽快修复问题。
输入内容长度控制

对于不受信任的输入,都应该限定一个合理的长度。虽然无法完全防止 XSS 发生,但可以增加 XSS 攻击的难度。

禁止 JavaScript 读取敏感 Cookie,让攻击者注入后无法取得 Cookie。

验证码

防止脚本冒充用户。

XSS 漏洞检测

  • 手动检测

    jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

    在输入框中提交或者拼接到 url 参数上进行检测

  • 自动扫描