六、HTTP 參數(shù)污染
作者：Peter Yaworski
譯者：飛龍
協(xié)議：CC BY-NC-SA 4.0
描述
HTTP 參數(shù)污染，或者 HPP，在網(wǎng)站接受用戶輸入，將其用于生成發(fā)往其它系統(tǒng)的 HTTP 請求，并且不校驗用戶輸出的時候發(fā)生。它以兩種方式產(chǎn)生，通過服務器（后端）或者通過客戶端。
在 StackExchange 上，SilverlightFox 提供了一個 HPP 服務端攻擊的不錯的例子。假設我們擁有以下站點：https://www.example.com/transferMoney.php，它可以通過 POST 方法訪問，帶有以下參數(shù)：
amount=1000&fromAccount=12345
當應用處理請求時，它生成自己的發(fā)往其它后端系統(tǒng)的 POST 請求，這實際上會使用固定的toAccount參數(shù)來處理事務。
分離后端 URL：https://backend.example/doTransfer.php
分離后端參數(shù)：toAccount=9876&amount=1000&fromAccount=12345
現(xiàn)在，如果在提供了重復的參數(shù)時，后端僅僅接受最后一個參數(shù)，并且假設攻擊者修改了發(fā)往網(wǎng)站的 POST 請求來提交toAccount參數(shù)，像這樣：
amount=1000&fromAccount=12345&toAccount=99999
存在 HPP 漏洞的站點就會將請求轉(zhuǎn)發(fā)給另一個后端系統(tǒng)，像這樣：
toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999
這里，由惡意用戶提交的第二個toAccount參數(shù)，會覆蓋后端請求，并將錢轉(zhuǎn)賬給惡意用戶調(diào)教得賬戶（99999）而不是由系統(tǒng)設置的預期賬戶（9876）。
如果攻擊者打算修改它們自己的請求，并且由漏洞系統(tǒng)處理，這非常實用。但是如果攻擊者可以從另一個攢點生產(chǎn)鏈接，并且誘使用戶無意中提交惡意請求，并帶有由攻擊者附加的額外參數(shù)，它也可以對攻擊者更加實用一些。
另一方面，HPP 客戶端涉及到向鏈接和其它src屬性注入額外的參數(shù)。在 OWASP 的一個例子中，假設我們擁有下列代碼：
<? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?> <a href="/page.php?action=view&par='.<?=$val?>.'">View Me!</a>
它從 URL 接受par的值，確保它是安全的，并從中創(chuàng)建鏈接?，F(xiàn)在，如果攻擊者提交了：
http://host/page.php?par=123%26action=edit
產(chǎn)生的鏈接可能為：
<a href="/page.php?action=view&par=123&action=edit">View Me!</a>
這會導致應用接受編輯操作而不是查看操作。
HPP 服務端和客戶端都依賴于所使用的的后端技術(shù)，以及在收到多個名稱相同的參數(shù)時，它的行為如何。例如，PHP/Apache 使用最后一個參數(shù)，Apache Tomcat 使用第一個參數(shù)，ASP/IIS 使用所有參數(shù)，以及其他。所以，沒有可用于提交多個同名參數(shù)的單一保險的處理方式，發(fā)現(xiàn) HPP 需要一些經(jīng)驗來確認你所測試的站點如何工作。
示例
1. HackerOne 社交分享按鈕
難度：低
URL：https://hackerone.com/blog/introducing-signal-and-impact
報告鏈接；https://hackerone.com/reports/105953
報告日期：2015.12.18
獎金：$500
描述：HackerOne 包含鏈接，用于在知名社交媒體站點上分享內(nèi)容，例如 Twitter，F(xiàn)ackbook，以及其他。這些社交媒體的鏈接包含用于社交媒體鏈接的特定參數(shù)。
攻擊者可以將另一個 URL 參數(shù)追加到鏈接中，并讓其指向任何他們所選的站點。HackerOne 將其包含在發(fā)往社交媒體站點的 POST 請求中，因而導致了非預期的行為。這就是漏洞所在。
漏洞報告中所用的示例是將 URL：
https://hackerone.com/blog/introducing-signal
修改為：
https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov
要注意額外的參數(shù)u。如果惡意更新的鏈接有 HackerOne 訪客點擊，嘗試通過社交媒體鏈接分享內(nèi)容，惡意鏈接就變?yōu)椋?/p>
這里，最后的參數(shù)u就會擁有比第一個更高的優(yōu)先級，之后會用于 Fackbook 的發(fā)布。在 Twitter 上發(fā)布時，建議的默認文本也會改變：
重要結(jié)論
當網(wǎng)站接受內(nèi)容，并且似乎要和其他 Web 服務連接時，例如社交媒體站點，一定要尋找機會。
這些情況下，被提交的內(nèi)容可能在沒有合理安全檢查的情況下傳遞。
2. Twitter 取消訂閱提醒
難度：低
URL：twitter.com
報告鏈接：http://www.merttasci.com/blog/twitter-hpp-vulnerability
報告日期：2015.8.23
獎金：$700
描述：
2015 年 8 頁，黑客 Mert Tasci 在取消接收 Twitter 的提醒時，注意到一個有趣的 URL。
https://twitter.com/i/u?t=1&cn=bWV&sig=657&iid=F6542&uid=1134885524&nid=22+26
（我在書里面把它縮短了一些）。你注意到參數(shù) UID 了嘛？這碰巧是你的 Twitter 賬戶 UID?，F(xiàn)在，要注意，他做了我認為多數(shù)黑客都會做的事情，他嘗試將 UID 修改為其它用戶，沒有其它事情。Twitter 返回了錯誤。
考慮到其他人可能已經(jīng)放棄了，Mert 添加了第二個 UID 參數(shù)，所以 URL 看起來是這樣：
https://twitter.com/i/u?iid=F6542&uid=2321301342&uid=1134885524&nid=22+26
然后就成功了。他設法取消訂閱了其它用戶的郵件提醒。這就說明，Twitter 存在 HPP 取消訂閱的漏洞。
重要結(jié)論
通過一段簡短的描述，Mert 的努力展示了堅持和知識的重要性。如果它在測試另一個作為唯一參數(shù)的 UID 之后，遠離了這個漏洞，或者它根本不知道 HPP 類型漏洞，他就不會收到 $700 的獎金。
同時，要保持關(guān)注參數(shù)，類似 UID，它們包含在 HTTP 請求中，因為我在研究過程中見過很多報告，它們涉及到操縱參數(shù)的值，并且 Web 應用做出了非預期的行為。
3. Twitter Web Intents
難度：低
URL：twitter.com
報告鏈接：https://ericrafaloff.com/parameter-tampering-attack-on-twitter-web-intents
報告日期：2015.11
獎金：未知
描述：
根據(jù)它們的文檔，Twitter Web Intents，提供了彈出優(yōu)化的數(shù)據(jù)流，用于處理 Tweets & Twitter 用戶：發(fā)推、回復、轉(zhuǎn)發(fā)、喜歡和關(guān)注。它使用戶能夠在你的站點上下文中，和 Twitter 的內(nèi)容交互，而不需要離開頁面或者授權(quán)新的應用來交互。這里是它的一個示例：
Twitter Intent
充分測試之后，黑客 Eric Rafaloff 發(fā)現(xiàn)，全部四個 Intent 類型：關(guān)注用戶、喜歡推文、轉(zhuǎn)發(fā)和發(fā)推，都存在 HPP 漏洞。
根據(jù)他的博文，如果 Eric 創(chuàng)建帶有兩個screen_name參數(shù)的 URL：
https://twitter.com/intent/follow?screen_name=twitter&scnreen_name=erictest3
Twitter 會通過讓第二個screen_name比第一個優(yōu)先，來處理這個請求。根據(jù) Eric，Web 表單類似這樣：
<form class="follow " id="follow_btn_form" action="/intent/follow?screen_name=er\ icrtest3" method="post"> <input type="hidden" name="authenticity_token" value="...">
<input type="hidden" name="screen_name" value="twitter">
<input type="hidden" name="profile_id" value="783214">
<button class="button" type="submit">
<b></b><strong>Follow</strong>
</button>
</form>
受害者會看到在一個screen_name中定義的用戶資料，twutter，但是點擊按鈕后，它們會關(guān)注erictest3。
與之類似，當展現(xiàn) intent 用于喜歡時，Eric 發(fā)現(xiàn)它能夠包含screen_name參數(shù)，雖然它和喜歡這個推文毫無關(guān)系，例如：
https://twitter.com/intent/like?tweet_id=6616252302978211845&screen_name=erictest3
喜歡這個推文會向受害者展示正確的用戶資料，但是點擊“關(guān)注”之后，它仍然會關(guān)注erictest3。
重要結(jié)論
這個類似于之前的 Twitter UID 漏洞。不出意料，當一個站點存在 HPP 漏洞時，它就可能是更廣泛的系統(tǒng)化問題的指標。有時如果你找到了類似的漏洞，它值得花時間來整體探索該平臺，來看看是否存在其它可以利用相似行為的地方。這個例子中，就像上面的 UID，Twitter 接受用戶標識，
screen_name，它基于后端邏輯易受 HPP 攻擊。
總結(jié)
HTTP 參數(shù)污染的風險實際上取決于后端所執(zhí)行的操作，以及被污染的參數(shù)提交到了哪里。
發(fā)現(xiàn)這些類型的漏洞實際上取決于經(jīng)驗，比其他漏洞尤甚，因為網(wǎng)站的后端行為可能對于黑客來說是黑盒。常常，作為一個黑客，對于后端在接收了你的輸入之后進行了什么操作，你需要擁有非常細微的洞察力。
通過嘗試和錯誤，你可能能夠發(fā)現(xiàn)一些情況，其中站點和其它服務器通信，之后開始測試參數(shù)污染。社交媒體鏈接通常是一個不錯的第一步，但是要記住保持挖掘，并且當你測試類似 UID 的參數(shù)替換時，要想到 HPP。
