測試Web應用程序中的競爭條件

轉載自:http://www.freebuf.com/articles/network/107077.html

此篇文章主要介紹了一下什麼是“競爭條件”漏洞以及介紹了一下如何使用Burp來實現該漏洞的利用。

在對一個應用程序進行黑盒/灰盒安全測試時,我們一般都把精力集中在OWASP TOP10上,而很少去測試“競爭條件”(race condition)問題。有一個共識是使用黑盒/灰盒方法進行“競爭條件”漏洞的挖掘是非常不靠譜的,一般都會通過對代碼進行審計來發現此類問題。但是話又說回來了,隨着技術的發展和工具的日趨先進,使用黑盒/灰盒測試方法來實現“競爭條件”漏洞的挖掘的可能性大大增加。

在本篇文章中我們將會對“競爭條件”漏洞是什麼和該類漏洞可能出現的場景進行討論,並且會使用Burp來模擬整個流程。

“競爭條件”是什麼

“競爭條件”發生在多個線程同時訪問同一個共享代碼、變量、文件等沒有進行鎖操作或者同步操作的場景中。

——Wikipedia-computer_science

開發者在進行代碼開發時常常傾向於認爲代碼會以線性的方式執行,而且他們忽視了並行服務器會併發執行多個線程,這就會導致意想不到的結果。

線程同步機制確保兩個及以上的併發進程或線程不同時執行某些特定的程序段,也被稱之爲臨界區(critical section),如果沒有應用好同步技術則會發生“競爭條件”問題。下圖爲3個進程同時訪問一個程序段。

圖片7.png

Java Web應用程序內部

在傳統的客戶端-服務器模型中,瀏覽器會將http請求發送至web服務器,然後呈現從服務器接收到的數據。當用戶嘗試通過瀏覽器向web應用程序發起多個併發請求時,瀏覽器並不會如實照做,下圖爲servlets中的多線程處理。

圖片8.png

設想一個基於Java的web應用運行在Apache Tomcat上,該應用包含一個與Java servlet進行交互的容器組件,這個組件負責servlet的生命週期管理,並且負責將url映射到對應的servlet。當web服務器接收到請求時,它會將該請求轉發給對應的容器,容器將會創建一個線程來處理該請求,創建一個HTTP請求和響應對象,並將這些對象傳遞給一個線程。

在我們假設的場景中,該容器並沒有顧及到線程安全(當一段代碼能夠在多個線程同時訪問時還能保證自由競爭條件,我們就說它是線程安全的,線程安全應該由開發人員來處理)。

攻擊者使用自動化腳本同時向服務器發起多個請求,這會導致容器生成多個線程,而且這些線程是並行執行的,開發人員在進行代碼開發時是很難考慮到這些並行執行的線程將會導致結果的複雜性,所以說線程安全是一個應用必須要滿足的。(在多線程環境下,容器不會創建一個servlet的多個實例,這些servlet成員會共享所有運行的併發的線程。如果開發人員使用servlet成員來執行操作,則會造成“競爭條件”問題。)

案例分析

假設一個銀行應用的場景:一筆交易需要從ACC_Form轉移到ACC_TO。如下爲實現轉賬功能的僞代碼。

 

圖片9.png

在這段僞代碼中,錢從賬戶ACC_From轉移到ACC_TO,應用程序會驗證賬戶是否有足夠的資金用於轉賬。但是通過發送多個併發請求(使用自動化腳本),攻擊者可以實現向ACC_TO轉超過自己餘額的金錢。

這種行爲發生的原因是服務器上的多個線程同時執行,if的判斷條件被多次判定爲真,導致代碼多次執行,這也就導致了“競爭條件”問題,因爲轉賬的錢可能超過了可用餘額。需要注意的是,這種行爲非常依賴於網絡延遲、程序負載等環境變量。

在進行滲透測試時,安全研究人員需要分析整個應用程序並找出應用程序做了哪些限制,以及是否能夠通過同時發送多個請求來繞過這些限制。

使用Burp來找出“競爭條件”問題

滲透測試人員可以使用Burp的intruder功能來實現發送多個併發請求,我們利用上面的僞代碼搭建了一個演示的應用程序。

假設一個客戶將錢從賬戶888轉移到賬戶999:

源賬戶 888 ,餘額:1美元。

目標賬戶 999 ,餘額:29,999美元。

圖片10.png

現在我們嘗試給賬戶999轉賬2美元,但是實際上我們只有1美元。

圖片11.png

程序返回“Transaction Failed”(轉賬失敗),因爲要轉賬的金額超出了我們的餘額。

圖片12.png

我們將轉賬的金額改成1美元,然後發起轉賬請求。正常情況下,源賬戶888的餘額會變成0,目標賬戶999的餘額會變成30,000美金。

漏洞利用

1、截斷轉賬的請求,併發送至intruder中。

圖片13.png

2、進入到“Options”選項中,將線程設置成25(默認爲5),因爲我們要發送很多併發請求。

圖片14.png

3、在“Payloads”選項中選擇“Null payloads” ,因爲我們只需要重複發包即可。

圖片15.png

4、開始發起攻擊並觀察結果,我們可以看到源賬戶的餘額變成了負數:

源賬戶餘額:-2美元

目標賬戶金額:30,002美元

圖片16.png

挑戰

“競爭條件”漏洞有時很難通過黑盒/灰盒的方法來進行挖掘,因爲這個漏洞很受環境因素的影響。比如網絡延遲、服務器的處理能力等。

參考文獻

https://en.wikipedia.org/wiki/Race_condition#Computing

https://en.wikipedia.org/wiki/Thread_safety

https://en.wikipedia.org/wiki/Synchronization_(computer_science)

http://roberto.greyhats.it/pubs/dimva08-web.pdf

http://www.slideshare.net/timtowtdi/1-java-servlets-and-jsp

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章