【10.21總結】一個滲透測試練習例項——發現未知的漏洞(Race condition)
Write-up地址：ofollow,noindex" target="_blank">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 fromconsultant request and using it inclient request
⑤ 在客戶的請求中使用兩個timing引數
⑥ 在客戶請求中把引數設定為{“timing[0]”:2} （這種把引數設定為陣列的漏洞我之前也看到過兩個，但是沒有記錄網址）
⑦ 修改HTTP方法，POST -> PUT
⑧ 同時訂閱同一個諮詢顧問的多個時間點（條件競爭）
⑨ 同時訂閱兩個不同諮詢顧問的時間點（條件競爭）
以上的條件競爭對我來說比較新穎，由於以上測試都失敗了，作者對於具體的測試方法也並沒有詳細介紹，而作者記下來找到的漏洞也是一種條件競爭，所以我其實不是特別明白⑧⑨中的條件競爭漏洞如果真的存在，會是怎樣的一種情況。
3. 發現漏洞
之後作者把精力集中在了客戶的請求上，由於客戶傳送的請求中並不包括value，所以如果在客戶訂閱之前，諮詢顧問提高了諮詢價格會發生什麼？
單個傳送請求並沒有問題，但是如果使用多執行緒，按照value值為{5,15,15,5}迴圈傳送諮詢顧問請求，客戶有50%的可能性會支付更高的諮詢費用。
4. 漏洞存在的原因
我對條件競爭這個概念並不陌生，想必大家在學習條件競爭時接觸到的模擬案例大多都是訂票系統吧，而訂票系統不就是一個web應用嗎？可是剛看到這個漏洞的時候，我甚至都不理解為什麼它會是一個漏洞。
考慮到具體場景，客戶已經在訂閱提交的頁面，而這時候諮詢顧問修改了價格，如果應用實現不當，後臺在發生客戶訂閱事件時沒有鎖定value變數，導致諮詢顧問仍然可以對其進行修改，確實會發生客戶以更高價格訂閱服務的情況。
之前的文章中，作者多是針對一個網站，分析它的各個子域名，對於每個子域名，檢視實現其功能時傳送的各種請求，分析其中可能的漏洞。然而文章中並沒有詳細說明作者是怎樣找到了最終的漏洞的。
而這篇文章，作者直接從該諮詢應用的功能出發，描述了他怎樣列出一系列測試案例，最終針對某個測試成功發現漏洞的流程，和之前文章的側重點不同。
但是有一點是相同的，那就是他們都強調了去分析應用的功能，檢視請求歷史，分析資料的流動方向，而這篇文章的作者尤其強調了要把更多的時間和精力用於構建smarter的測試案例，這樣才能發現漏洞。