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的測試案例，這樣才能發現漏洞。