米桃安全漏洞讲堂系列第2期：XSS跨站脚本攻击漏洞
一、一次钓鱼攻击引发的反制
某日，安全团队收到监控预警，有外部人员使用钓鱼邮件对公司内部人员进行信息诈骗。安全团队立即开始分析事件进程。
攻击者以劳动补贴名义群发邮件，诱导内部员工扫描二维码，进而填写个人信息、银行卡等敏感内容。
安全团队立即开始对邮件进行溯源。
首先，扫描该二维码，跳转到钓鱼邮件域名为
https://4z3ichiecr.512kasmdkasijdiashdjdfdfpewkpxxxxxxxxxx.cn/okok168
ip地址为：
150.129.123.123（香港服务器）
经测试，该钓鱼邮件页面中前端页面存在跨站脚本攻击漏洞，利用该漏洞，安全团队进行反钓鱼试验。等待钓鱼平台管理人员上线。
经过一天的等待，终于有了突破，钓鱼平台人员上线，我方通过预埋的跨站脚本攻击漏洞获取了网站后台管理员账号cookie信息。顺利登录该后端平台。
登录后确认该平台为攻击来源，确认受害者信息、范围、金额，并锁定后台人员登录ip、身份等信息。完成溯源工作。为后续法律方面推进工作提供了有利支持。
上述钓鱼反制的关键角色，就是本文要讲述的主角：跨站脚本攻击漏洞。
二、跨站脚本攻击漏洞原理（XSS）
2.1 漏洞原理
跨站脚本攻击（Cross Site Scripting，以下简称XSS）。
本应缩写为CSS，但由于CSS（Cascading Style Sheets，层叠样式脚本）重名，所以更名为XSS。
XSS（跨站脚本攻击）是指攻击者在网页中嵌入客户端脚本(如JavaScript)，当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的。比如获取用户的Cookie，导航到恶意网站，携带木马等。
2.2 漏洞类型分类
XSS漏洞可分为三类。
- 反射型XSS
跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码一般不存储到服务端。 - 存储型XSS
这是利用起来最方便的跨站类型，跨站代码存储于服务端（比如数据库中）。用户每次访问相应的页面，客户端均会执行一次XSS攻击语句。属于危害较严重的漏洞。 - DOM型XSS
—种基于DOM的跨站，这是客户端脚本自身解析不正确导致的安全问题。DOM XSS 是由于浏览器解析机制导致的漏洞，服务器不参与，而存储型与反射型都需要服务器响应参与。
2.3 漏洞危害
XSS漏洞的危害不仅局限于弹窗这种骚扰方式，按危害发生位置来划分，可分为客户端、服务端两类。总结如下，
客户端危害：
- 窃取cookie（包括ip、ua等）
- 自动转发邮件
- 放马（webshell）
- 刷流量
服务端危害：
- 劫持后台
- 篡改页面
- 蠕虫传播
- 内网扫描
通过以下两个例子，说明XSS的危害性。
2.4 XSS漏洞案例
案例一、使用XSS漏洞成功登录某后台系统
某业务系统，机器人客服对话功能中，允许攻击者输入XSS攻击代码，如以及它的各种变体：
<script>alert(document.cookie)</script>
<script>alert(1)</script>
<ScRipt>alert(1)</script>
%3Cscript%3Ealert(1)%3C/script%3E
<script x=1>alert(1)</script x=1>
<script>confirm(1)</script>
<svg/onload=alert`1`>
"--><Svg/Onload=alert(1)>
'";alert(1);x="'
<img src=alert(1)>
<sc<script>ript>alert(/1/)</script>
<javascript:alert(1)>;
变体XSS攻击语句，主要是针对服务端防护不全的场景。绕过XSS防护的方式包括：
1、html标签、JavaScript事件尝试； 2、大小写绕过，如后，页面弹出警告框，则该页面存在XSS漏洞。如下：
存储型跨站脚本攻击测试方法与反射型类似，区别在于存储型跨站脚本攻击的检测内容主要是Web应用程序向用户提供的可添加新内容并持久存储的Web表单。通过对每个可能存在攻击点的Web表单插入攻击字符串，进行检测。
3.2 XSS进阶利用——XSS打码平台
对于有经验的攻击者，通常使用XSS打码平台实施攻击。XSS平台，通常可以记录访问的url，访问时的cookie等。稍微复杂的功能，可能还会记录键盘输入，获取页面源码，截取网页屏幕等。
相应的功能可在平台进行定制，例如，
勾选相应模块后，系统会自动生成各种类型的攻击语句（结合上述绕过思路）。
攻击者将相应的语句嵌入被攻击平台，静等后台受害者上线即可。以下为攻击者成功获取用户信息的界面。
3.3 自动化漏洞检测方案
除了手工测试外，企业也可采用自动化漏洞扫描方案。
- DAST黑盒扫描。动态应用安全测试，黑盒测试。可输入扫描目标，配置登录信息后，启动扫描XSS漏洞。如Xray、AWVS等。
- IAST扫描。交互式应用程序安全测试。可在测试阶段，由测试人员执行，工具被动系统XSS漏洞。
- SAST扫描。源代码扫描。白盒工具。从源码层面扫描不规范的写法，提示XSS漏洞风险。
四、防御措施
企业作为信息平台提供方，如何防御跨站脚本漏洞，可以从XSS漏洞的攻击流程入手。
完整的XSS攻击流程包括五步。攻击者发现XSS漏洞——构造攻击代码，植入功能点——被害人主动或被动访问功能——前端（浏览器）执行代码——获取受害人信息如cookie。
从攻击流程判断，平台方可以从XSS攻击语句的输入、输出阶段进行介入，打断攻击流程，完成攻击防御。
跨站脚本攻击漏洞防御总体思路可总结为：输入过滤，输出编码。
4.1 输入过滤（过滤器、黑名单、白名单）
4.1.1 事件标签过滤
XSS攻击语句多为HTML、JavaScript事件标签。可通过过滤标签的方式，破坏攻击者构造的攻击语句。
- 过滤HTML标签或转义特殊字符
如过滤", "illegal!");
XssFilterSample1("userdata", "legal!");
}
public void testEncode1() {
XssHtmlEncodeSample1("", "<script>alert(123)</script>");
XssHtmlAttributeEncodeSample1("javascript:alert(123)", "javascripta;alert 123 ");
UrlEncodeSample1("alert(123)" , "%3Csciprt%3Ealert%28123%29%3C%2Falert%3E");
UnicodeEncodeSample1("var a = 1;", "var\\u0020a\\u0020\\u003d\\u00201\\u003b");
CSSEncodeSample1("back-ground:url", "\\000062\\000061\\000063\\00006b\\00002d\\000067\\000072\\00006f\\000075\\00006e\\000064\\00003a\\000075\\000072\\00006c");
}
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
4.3 浏览器前端XSS防护设置
除了上述从后端源码层面的XSS防护。还可以从浏览器（前端）层面进行相关安全配置，实现XSS防护。具体如下。
4.3.1 cookie增加HttpOnly属性（同源策略）
建议如果网站基于cookie而非服务器端的验证，建议加上HttpOnly，当然，目前这个属性还不属于任何一个标准，也不是所有的浏览器支持，设置cookie的代码：
response.setHeader("SET-COOKIE","user=" + request.getParameter("cookie") + "; HttpOnly");
本段代码设置了http only属性，攻击者无法通过Javascript 中的document.cookie语句获取用户Cookie信息。
4.3.2 设置X-XSS-Protection属性
该属性被所有的主流浏览器默认开启。X-XSS-Protection，即XSS保护属性，是设置在响应头中目的是用来防范XSS攻击的。在检查到XSS攻击时，停止渲染页面。
4.3.3 开启CSP网页安全策略
CSP是网页安全策略(Content Security Policy)的缩写。
开启策略后可以起到以下作用：
- 禁止加载外域代码，防止复杂的攻击逻辑；
- 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域；
- 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）；
- 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）；
- 合理使用上报可以及时发现 XSS，利于尽快修复问题。
五、总结展望
本文结合实际使用案例，简要讲述了跨站脚本攻击漏洞XSS的原理、危害、测试方法及防御措施。
XSS漏洞形成的根本原因是，用户过分信任网站，放任来自浏览器地址栏代表的那个网站代码在自己本地任意执行。如果没有浏览器的安全机制限制，XSS代码可以在用户浏览器为所欲为。
对于XSS的防御，更多的是客户端侧的任务。故业界有人戏称"CSRF是服务端程序员的锅，XSS是客户端程序员的锅"。
系列往期链接
米桃安全漏洞讲堂系列第1期：SQL注入漏洞