六、HTTP 參數污染 · Web Hacking 101 中文版

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