3.1　服務(wù)器端HPP

在服務(wù)器端HPP中，嘗試給服務(wù)器端發(fā)送非預(yù)期信息來讓服務(wù)器端代碼返回非預(yù)期的結(jié)果。在第1章中討論過，當(dāng)你發(fā)送一個(gè)請(qǐng)求到一個(gè)網(wǎng)站時(shí)，網(wǎng)站服務(wù)器端會(huì)處理該請(qǐng)求并且返回結(jié)果。在某些情況下，服務(wù)器端不僅返回一個(gè)網(wǎng)頁，同時(shí)還會(huì)根據(jù)從URL獲取到的信息運(yùn)行一些代碼。這部分代碼只會(huì)在服務(wù)器端運(yùn)行，所以對(duì)你來說基本上是不可見的，也就是說，你可以看到發(fā)送的信息和返回的結(jié)果，但是這中間運(yùn)行的代碼你是看不到的。因此，你只能推斷這期間發(fā)生的事情。因?yàn)槟憧床坏椒?wù)器端的代碼結(jié)構(gòu)，所以服務(wù)器端HPP取決于你如何確定存在潛在漏洞點(diǎn)的參數(shù)并進(jìn)行試驗(yàn)。

讓我們看一個(gè)例子：如果銀行通過網(wǎng)站接收URL參數(shù)發(fā)起轉(zhuǎn)賬，可能會(huì)造成服務(wù)器端HPP漏洞。想象一下如果你可以通過輸入三個(gè)URL參數(shù)from、to、amount來進(jìn)行轉(zhuǎn)賬，每個(gè)參數(shù)按順序指定：from指定要從中進(jìn)行轉(zhuǎn)賬的賬號(hào)，to指定要轉(zhuǎn)入的賬號(hào)，amount指定要轉(zhuǎn)賬的金額。以下URL表示從12345賬戶轉(zhuǎn)賬5000美元到67890賬戶：

銀行可能會(huì)假設(shè)它只可能接收一個(gè)from參數(shù)，但是如果你提交兩個(gè)參數(shù)會(huì)發(fā)生什么？就像下面這個(gè)URL一樣：

這個(gè)URL最初的結(jié)構(gòu)組成和第一個(gè)示例一樣，只是多加了一個(gè)額外的from參數(shù)以表示另一個(gè)發(fā)送賬戶ABCDEF。在這種情況下，攻擊者可以發(fā)送這個(gè)額外的參數(shù)，希望可以令程序用第一個(gè)from參數(shù)做轉(zhuǎn)賬驗(yàn)證，使用第二個(gè)from參數(shù)從賬戶ABCDEF提取資金。所以，如果銀行信任它接收到的最后一個(gè)from參數(shù)，攻擊者就可以利用一個(gè)不是他們自己的賬戶來執(zhí)行轉(zhuǎn)賬操作——不再從12345的賬戶向67890的賬戶轉(zhuǎn)賬5000美元，取而代之的是，服務(wù)器端代碼會(huì)使用第二個(gè)參數(shù)從ABCDEF賬戶轉(zhuǎn)賬給67890賬戶。

當(dāng)服務(wù)器接收到多個(gè)具有相同名稱的參數(shù)時(shí)，它可以通過多種方式進(jìn)行響應(yīng)。例如，PHP和Apache取參數(shù)的最后一次賦值，Apache Tomcat取參數(shù)的第一次賦值，ASP和IIS取該參數(shù)的所有賦值，等等。研究人員Luca Carettoni和Stefano di Paolo在App Sec EU 09大會(huì)上詳細(xì)介紹了服務(wù)器端技術(shù)之間的許多差異，該內(nèi)容現(xiàn)在可在OWASP網(wǎng)站上找到，網(wǎng)址為https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf（請(qǐng)參閱該網(wǎng)站中的幻燈片9）。因此，沒有哪一個(gè)單獨(dú)的驗(yàn)證程序可以保證能同時(shí)處理好多個(gè)相同名稱的參數(shù)提交操作，發(fā)現(xiàn)HPP漏洞時(shí)，你需要做一些試驗(yàn)來確認(rèn)你所測(cè)試的網(wǎng)站是如何運(yùn)作的。

銀行的例子使用了顯而易見的參數(shù)。但是有時(shí)HPP漏洞是由服務(wù)器端產(chǎn)生的，這些代碼是無法直接觀察到的。例如，假設(shè)你的銀行決定修改其處理轉(zhuǎn)賬的方式，并更改其后端代碼，從而在URL中不包含from參數(shù)。這次，銀行將使用兩個(gè)參數(shù)，一個(gè)參數(shù)代表轉(zhuǎn)賬的目的賬戶，另一個(gè)參數(shù)代表轉(zhuǎn)賬金額。轉(zhuǎn)賬源賬戶將由服務(wù)器端設(shè)置，你看不到該賬戶。一個(gè)示例鏈接可能如下所示：

通常，我們很難看懂服務(wù)器端代碼，但是對(duì)于本例而言，我們知道銀行服務(wù)器端的Ruby代碼如下所示（明顯存在冗余）：

該代碼創(chuàng)建了兩個(gè)函數(shù)：prepare_transfer和transfer_money。prepare_transfer函數(shù)采用一個(gè)名為params?的數(shù)組，該數(shù)組包含URL中的to和amount參數(shù)。該數(shù)組賦值為[67890,5000]，其中數(shù)組值夾在方括號(hào)之間，并且每個(gè)值都用逗號(hào)分隔。函數(shù)的第一行?將代碼前面定義的用戶賬戶信息添加到數(shù)組的末尾。我們最后在params中得到[67890,5000,12345]數(shù)組，然后將params傳遞給transfer_money函數(shù)?。請(qǐng)注意，與參數(shù)不同，數(shù)組不是鍵值對(duì)組合，因此代碼始終按順序包含數(shù)組的每一個(gè)值：第一個(gè)值是轉(zhuǎn)賬目的賬戶，第二個(gè)值是轉(zhuǎn)賬金額，最后一個(gè)值是轉(zhuǎn)賬源賬戶。在transfer_money函數(shù)中，由于函數(shù)將每個(gè)數(shù)組值賦值給變量，因此值的順序變得很明顯。由于數(shù)組位置從0開始編號(hào)，因此params[0]訪問數(shù)組中第一個(gè)位置的值（在這種情況下為67890），并將其分配給?處變量。其他值也依次分配給?和?處變量。然后，將變量名傳遞到此代碼段中未顯示的transfer函數(shù)，該函數(shù)接受值并進(jìn)行轉(zhuǎn)賬。

理想情況下，URL參數(shù)將始終按照代碼期望的方式進(jìn)行格式化。但是，攻擊者可以通過將from的值傳遞給params來更改此邏輯的結(jié)果，例如以下URL：

在這種情況下，from參數(shù)也包含在傳遞給prepare_transfer函數(shù)的params數(shù)組中。因此，數(shù)組的值將為[67890,5000,ABCDEF]，在?處代碼將用戶賬戶賦值之后，數(shù)組變?yōu)閇67890,5000,ABCDEF,12345]。結(jié)果是，在prepare_transfer中調(diào)用transfer_money函數(shù)時(shí)，from變量將從params數(shù)組的第三個(gè)參數(shù)賦值，雖然期望獲取的user.account值為12345，但實(shí)際上將獲取到攻擊者傳遞的值A(chǔ)BCDEF?。