[ 目录 ]
0×00 前言
0×01 xss渗透测试基本思路
0×02 一次黑盒的xss渗透测试
0×03 一次白盒的xss渗透测试
0×04 总结
0×00 前言
在web蓬勃发展的今天，xss毫无疑问已经变成最“流行”的漏洞，我曾经在安全公司的渗透测试报告里看到列为数十的高危xss漏洞，也看到越来越多的安 全研究人员将目标投向xss攻击，发现100个甚至1000个之上的xss，
黑盒和白盒的渗透基本思路
。xss变得如此流行的原因我猜测有几点，首先输入输出是一个应用程序最基本的 交互，一个提供服务的应用程序可以不操作数据库，可以不与系统交互，但是肯定会将程序的处理结果返回给浏览器，加上程序员如果意识不到位，就必然发生 xss，对于一个互联网公司，这两方面的因素加起来就会导致这个漏洞数量就非常可观，所以可以经常见到互联网公司如腾讯，新浪，百度，搜狐等等的xss漏 洞报告。但是，在谈论xss的时候往往大家都会说这是一个xss漏洞，而不会提到这是个什么类型的xss漏洞，甚至这是个什么场景下的xss漏洞，包括有效的攻击 方式上都不会去提，即使提到也是一些传说的危害譬如蠕虫，譬如挂马，譬如窃取用户信息，乃至钓鱼攻击。甚至由于种种原因，大家往往关注漏洞两个字甚于前面 的xss。作为安全研究人员，这是一种不负责任的行为，这种行为的后果就是网络安全淡化为web安全，web安全淡化为xss，而xss淡化为 alert()，总有一天程序员会不再信任我们，真正的威胁依然停留在系统里。这方面也有国际上的原因，太多的安全研究人员将重点放在xss的研究上，我 不知道是否是国外的安全水平已经达到如此需要关注xss的水平，尽管xss是最普遍的漏洞，但是从 的利用程度上来看远远不如一个命令执行，一个文件上 传漏洞来得实在。我相信Google已经达到这水平，但那只是Google，不是我们。
我这里不想谈论如何防范xss漏洞，如果在你的系统里发现1000个之上的xss，那你就应该停止寻找更多的xss而该去想想如何从根源上杜绝xss，即 使杜绝不了xss那也应该想想xss在这里是不是有什么可预见的风险，如果有的话那有什么方式可以将xss的危害弱化乃至一段时期内可以接受的程度。作为 一个 实用主义者，我这里将描述一次xss渗透测试的简单思想以及实现，与学院派不同，渗透测试不能只是说说而已，必须真实的获取自己想要的东西才可以 是成功。
0×01 xss渗透测试基本思路
在谈论具体的xss攻击之前，我们一定要清楚地知道我们的xss所处的位置在哪以及我们的xss的类型，也就是我上面说的xss攻击场景。反射型的xss 比起持久型的xss来效果是不同的，访问量大的xss点与访问量小的xss点是不同的，发生在http://www.google.com和发生在 https://www.google.com的xss点是不同的（你应该知道为什么不同），发生在前台的xss点与发生在后台的xss点同样不同。分析 应用程序我们可以很快确认我们的xss点的场景，这在开放的程序里比较好确认，后面我们将讲述如何在一个黑盒的环境下分析出攻击的场景，
电脑资料
《黑盒和白盒的渗透基本思路》(https://www.unjs.com)。在确认好xss点的场景之后，我们可以根据我们的目的来决定后续的攻击方向和思路。如果发生的点是一个持久型的并且访问量比较大，你可以依据自己的喜好是 否来引起一次混乱；如果你有幸发现发生的点是在管理员的后台或者你可以通过某些方式和管理员的后台进行交互，那么你可以考虑是否需要通过窃取管理员的 cookie来尝试进入后台，到目前为止，窃取cookie依然是最有效的攻击方式，尽管某些xss攻击平台可以演示很炫的攻击效果（前提是你的目标会在 一个页面停留2个小时，这种情况比较少发生）；如果发生的点是一款开源的或者所有数据请求你都可以分析的程序，你可以考虑利用xss做一些数据提交，但是 前提是依赖于你的xss点发生的场景；或者大气点，有浏览器0day的直接上浏览器0day吧，成本有点高，看收获值不值得了，目前为止貌似这么说的比这 么做的多：）
攻击方向和思路确定之后后面的就是一些常规的体力活了，编写攻击代码，获取最终想要的东西，但是这过程可能并不是一帆风顺，甚至需要反复的调试攻击代码以保证最终的效果跟预期的一致。
0×02 一次黑盒的xss渗透测试
因为某些原因我们很想测试下国内一个比较有名的评论网站，我们简单测试常规的安全漏洞之后我们没有发现什么有意思的如SQL注射之类的安全漏洞，甚至我们 还没有办法找到它的后台，但是我们发现了他们的一个xss漏洞，比较悲观的是这是一个反射型的xss漏洞，所以我们不能直接把他页面黑了（如果是持久类型 的xss，攻击目的就是破坏或者测试的话就可以考虑这么做，当然，如果是为了YY也是可以的）。我们不要YY，我们要shell。通过对站点的分析我们发 现系统有个投稿功能，通过审核之后就可以发表。既然会有审核那么就意味着应该有后台之类的东西，同时我们实际上获得了一个和管理员交互的平台，因为我们写 的内容他们肯定会看。于是我们将编写好的xss exploit url写到文章里，并且声称在他们的站点内发现了一个黄色的文章。这个xss exploit url会请求我的某个php文件，这个文件将记录所有请求的referer，cookie，ip，浏览器类型和当前的location。等待几十分钟之 后，我们顺利获得了这些基础信息，但是我们发现这里的location和referer只能获得我们的xss exploit url，这跟我们希望获得的管理员后台并不一致。分析管理员在后台的操作我们大概可以知道他是点击连接来访问这个url的，那么我们是可以获得 opener窗口的一些信息的，包括location等等。在获得location之后我们还是很失望，这只是一个内容展现的窗口，并不是后台的真正管理 的地址，后台应该是有一个iframe类的东西，于是我们再次通过top.location获得后台的地址，这次对了，在我们的面前出现了后台登陆的地 址，后面的利用窃取的cookie进入后台很可行哦：）但是我们在尝试利用cookie进入后台时依然出了问题，我们的cookie看起来并不有效，这是 为什么呢？后来几次测试之后才发现程序做了cdn，我们访问到的登录地址并不是cookie所在的服务器，做了个host之后我们顺利登录进后台，后台界 面出来的一瞬间让人感觉真是幸福：）后面的就简单，找后台的上传，传webshell，涂首页：）
很明显，在这样一个场景下如果说到xss来做蠕虫肯定是不现实的，对于一个评论网站来说钓鱼也没有什么实际意义，对一个连用户机制都没有或者有用户机制但 是用户交互比较低的应用程序来说偷取用户cookie同样也没有价值。而真正攻击的过程中也不是简单的说说那么容易，应用程序有很多机会可以防止这种攻击 的发生，包括cookie和ip绑定，cookie做httponly，后台设置登录ip限制等等（不要跟我说那些看起来很神仙可以反弹的xss工具，这 就跟物理学里面的理想环境里的实验一样不靠谱）。