【10.21总结】一个渗透测试练习实例——发现未知的漏洞(Race condition)
Write-up地址：Exploiting an unknown vulnerability
这篇文章跟我之前看到的文章不太一样，作者是按照一个练习的方式简单描述了他对一个应用进行渗透测试的过程，其中提到的许多测试虽然没有成功，但是对于像我这样的菜鸟来说还是有很大的启发，事实上在看的过程中我会很疑惑，也可能是因为我之前并不是特别了解逻辑漏洞，而许多bug bounty的write-up中提到的漏洞类型是比较集中的XSS或者CSRF，所以这篇文章让我从另一个角度看待web漏洞。
背景：一个已经经过渗透测试的咨询应用程序
作者首先对应用进行分析，在实现应用功能时的数据流动。之后开始渗透测试，并首先分析可能存在的逻辑漏洞，因为在软件开发或者测试的过程中可能存在没有被考虑到的临界条件。
应用分析：
1. 用户角色：
①咨询顾问：设置一个时间点的咨询费用
# consultant request
POST /set/fee/
{"value": 5, "timing":2}
②客户：预约某咨询顾问的时间，并扣除对应时间点的咨询费用
# client request
POST /consultant_username/book
{"timing":2}
到这里，我也想到一些测试，例如xss，sql注入，把参数值修改为负数或者极大值，设置多个重复的参数，然后开始看下面作者给出的测试：
2. 测试案例：
这里作者提到了九个测试用例，有一些我不太明白，所以直接引用原文了。
① 注入漏洞，例如sql注入，命令注入
② 把content-type和请求数据修改为xml，测试是否存在xml注入
③ Booking consultant’s higher value time slots in less coin
④ Injecting “value” parameter from consultant request and using it in client request
⑤ 在客户的请求中使用两个timing参数
⑥ 在客户请求中把参数设置为{“timing[0]”:2} （这种把参数设置为数组的漏洞我之前也看到过两个，但是没有记录网址）
⑦ 修改HTTP方法，POST -> PUT
⑧ 同时订阅同一个咨询顾问的多个时间点（条件竞争）
⑨ 同时订阅两个不同咨询顾问的时间点（条件竞争）
以上的条件竞争对我来说比较新颖，由于以上测试都失败了，作者对于具体的测试方法也并没有详细介绍，而作者记下来找到的漏洞也是一种条件竞争，所以我其实不是特别明白⑧⑨中的条件竞争漏洞如果真的存在，会是怎样的一种情况。
3. 发现漏洞
之后作者把精力集中在了客户的请求上，由于客户发送的请求中并不包括value，所以如果在客户订阅之前，咨询顾问提高了咨询价格会发生什么？
单个发送请求并没有问题，但是如果使用多线程，按照value值为{5,15,15,5}循环发送咨询顾问请求，客户有50%的可能性会支付更高的咨询费用。
4. 漏洞存在的原因
我对条件竞争这个概念并不陌生，想必大家在学习条件竞争时接触到的模拟案例大多都是订票系统吧，而订票系统不就是一个web应用吗？可是刚看到这个漏洞的时候，我甚至都不理解为什么它会是一个漏洞。
考虑到具体场景，客户已经在订阅提交的页面，而这时候咨询顾问修改了价格，如果应用实现不当，后台在发生客户订阅事件时没有锁定value变量，导致咨询顾问仍然可以对其进行修改，确实会发生客户以更高价格订阅服务的情况。
之前的文章中，作者多是针对一个网站，分析它的各个子域名，对于每个子域名，查看实现其功能时发送的各种请求，分析其中可能的漏洞。然而文章中并没有详细说明作者是怎样找到了最终的漏洞的。
而这篇文章，作者直接从该咨询应用的功能出发，描述了他怎样列出一系列测试案例，最终针对某个测试成功发现漏洞的流程，和之前文章的侧重点不同。
但是有一点是相同的，那就是他们都强调了去分析应用的功能，查看请求历史，分析数据的流动方向，而这篇文章的作者尤其强调了要把更多的时间和精力用于构建smarter的测试案例，这样才能发现漏洞。