http线程并发测试-化无为有的漏洞挖掘 jmter
https://bbs.ichunqiu.com/thread-24241-1-1.html
前言: 其实很早的时候就想研究这个HTTP线程并发测试了,但是一直在做其他的事情就给耽搁了。 一个坑: 为什么我要科普下面的东西呢?因为笔者在搞这些东西的时候也给搞混淆了,所以还是要理清自己的思路,稍微看看这些东西就行,不需要你们去细懂,随便你们自己也可以直接忽略这一段。 并发: 在操作系统中,是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行。其中两种并发关系分别是同步和互斥 按照我们的生活案例来解释就是: 正常请求:用户A在一个网站上提款,发送了提款请求,后台显示一条提款请求,审核了然后顺利提到了。 并发请求:用户A在一个网站上提款,同步发送了多个提款请求,后台显示多条提款请求,审核了然后顺利的提到了几倍的bounty。
互斥:
进程间相互排斥的使用临界资源的现象,就叫互斥。
同步:
进程之间的关系不是相互排斥临界资源的关系,而是相互依赖的关系。进一步的说明:就是前一个进程的输出作为后一个进程的输入,当第一个进程没有输出时第二个进程必须等待。具有同步关系的一组并发进程相互发送的信息称为消息或事件。其中并发又有伪并发和真并发,伪并发是指单核处理器的并发,真并发是指多核处理器的并发。
并行:
Parallelism,即并行,指两个或两个以上事件(或线程)在同一时刻发生,是真正意义上的不同事件或线程在同一时刻,在不同CPU资源呢上(多核),同时执行。
并行,不存在像并发那样竞争,等待的概念。
图中,A,B,C都在同时运行(微观,宏观)。
多线程:
异步:
异步和同步是相对的,同步就是顺序执行,执行完一个再执行下一个,需要等待、协调运行。异步就是彼此独立,在等待某事件的过程中继续做自己的事,不需要等待这一事件完成后再工作。线程就是实现异步的一个方式。异步是让调用方法的主线程不需要同步等待另一线程的完成,从而可以让主线程干其它的事情。异步和多线程并不是一个同等关系,异步是最终目的,多线程只是我们实现异步的一种手段。异步是当一个调用请求发送给被调用者,而调用者不用等待其结果的返回而可以做其它的事情。实现异步可以采用多线程技术或则交给另外的进程来处理。
举个例子:普通B/S模式(同步)AJAX技术(异步)
同步:提交请求->等待服务器处理->处理完毕返回 这个期间客户端浏览器不能干任何事,例如:你叫我去吃饭,我听到了就和你去吃饭;如果没有听到,你就不停的叫,直到我告诉你听到了,才一起去吃饭。
异步: 请求通过事件触发->服务器处理(这是浏览器仍然可以作其他事情)->处理完毕。例如:你叫我,然后自己去吃饭,我得到消息后可能立即走,也可能等到下班才去吃饭。
所以,要我请你吃饭就用同步的方法,要请我吃饭就用异步的方法,这样你可以省钱。
请求方式,分为GET与POST:
GET方式:
POST方式:
挖掘方法
那么了解完这些东西,我们注重点是并发。
如何挖掘并发呢?
据我所知的测试工具有两款:JMeter与LoadRunner
JMeter视图:
LoadRunner视图:
笔者这里使用JMeter 这款工具。
一般我们寻找挖掘的位置:
1.支付
2.提款
3.退款
4.还款等功能。
那么相信大家已经知道要找什么类型的网站:购物、金融网站。
那么到底是哪里出现了问题导致的呢?
我们来看看正常逻辑的处理:
逻辑处理流程表面上来看是没有任何问题的,但是我们可以想象一下:
如果一个客户同时有两次提款的请求,一次提款成功但未扣除金额,另一次提款在第一次提款的基础下扣除了金额,而后台是收到了两次提款请求。
当客户的金额只有500元的时候,同时发送多个500元提款请求,但是没有一个请求走到扣除用户金额的位置,多次提款都可以成功,并且后台审核的时候并没发现什么异常
有些童鞋可能就会问了,为什么” 一次提款成功但未扣除金额”?
其实就是处理速度的问题,数据库的处理速度跟不上用户的请求速度,就有可能存在这样的漏洞。
实战挖掘
定向目标挖掘,使用HTTP多线程数并发测试下www.qq.com的状态:
再来测试下某某网站(这里称之为A网站) 其实这个网站相对还是很安全的:
可以看到两者之间的差距,A网站明显其的并发承受能力要低于qq.com(类似于压力测试)。
首先要测试这个网站要先有账号和账号里要有钱,这时候就比较尴尬了,还好找到了一个撞库接口:
撞出来好几个终于找到一个有钱的用户了:
那我们可以使用JMeter来测试下申请提现这个点,首先使用Burpsuite抓一个提款的包:
但是不要放出去,打开JMeter->右击测试计划->创建线程组:
这里我设置线程数为50,Ramp-Up设置为0,其他的默认不填写
然后右击线程组->创建HTTP请求:
设置HTTP请求:
因为我们是在个人中心,如果没有Cookie肯定是发送不了这个请求报文的没,所以要创建一个HTTP Cookie管理器:
配置好相对应的cookie,如果你不知道怎么配置,可以对应Firebug的Cookie来设置:
最后添加一个监视器,这里我使用察看结果树,方便我们查看具体情况:
最后的最后,你才成了那个最好的人
直接点击发送:
察看结果树:
见证历史一刻来了,我们来看看到底有没有成功:
但是居然只有一条??
是不是有什么地方没设置好?然后花了一些的时间来研究这个网站哪个时间点最忙,发现并没有什么卵用,于是利用了小小DDoS攻击+并发请求,在取消退款的时候进行了并发测试:
途中等待了好久,网站反应贼慢,还好老天不负有心人:
最后我们可以看到 成功的”刷了一波money”:
不过不要干违法的事情哦!!!
漏洞详情已经转告相应厂商,目前网站业务已经下线维护中。
最后:
安全始于人,漏洞始于人,没有绝对的安全!
米斯特安全团队招收长期混迹于漏洞平台、SRC的大佬。
另外我们的线下培训重新招生了:
https://zhuanlan.zhihu.com/p/27579084?group_id=863037455245377536
欢迎大家,欢迎大佬!
本文章只用于技术交流,严禁用于非法行为和破坏行为,否则造成的一切法律责任与本人无关。
|