前言

在上一篇的HTTP請求走私之後，已經知道HTTP Header也可以被拿來利用，這篇會更直接的透過Header本身實現攻擊。

正文

簡略介紹

當Web應用程式使用且信任來自User所發送的Request Header時，就可能導致HTTP Header Injection，並trigger其他Attack vector，用一個簡單的例子說明這種狀況:

網站有個X-forwarded-for Header，並且沒有檢查安全性，而且直接顯示在網頁上，這時候構造一個Request:

GET /myip HTTP/1.1
Host: example.com
User-Agent: Chrome...
x-forwarded-for: 1.1.1.1<script>alert("XSS")</script>

網站收到請求並Response時，就會出現一個彈出式視窗並寫著"XSS"的字樣，這只是一個基本的利用方法。下面講述HTTP Header Injection所能夠造成的其他危害。

Attack Vector

SQL Injection via HTTP Header Injection

若網站的資料庫使用不安全的方法，引入了Request Header作為資料，例如使用剛剛講過的X-forwarded-for紀錄使用者IP;使用Refer蒐集使用者從哪裡連結到目前的網頁;使用cookie驗證使用者等等。若是我們在Header中寫入了SQL語法，就可以達成SQL Injection的效果，但因為本系列(和本章)不會特別討論SQL Injection因此就不多談(之後會有代替SQL Injection的ORM Injection)

Host Header Injection

Host Heaeder指定User要訪問的domain，例如我們瀏覽google.com時，就會發出這種Request:

GET / HTTP/1.1
Host: google.com
...

而某些網站以不安全的方式處理Host Header的值，在沒有正確驗證的情況下，就會引發HTTP Host Header Injection，這可以拿來做像是Web Cache Poison，SSRF等的攻擊。

攻擊者可以透過更改requset中的Host Header的value(Host需與IP分離，否則更改Host header會導致request發送到不同的IP address)，去檢查網站的Host Header使用上是否有問題，例如某些網站可能在省略port(因為使用預設)的情況下parse Host Header，因此可透過在port的位置寫入惡意內容。

GET / HTTP/1.1
Host: example.com:<payload>
...

寫入重複的Host Header、在Host Header之前放［space],[tab]等等的，導致Web Server在判別優先級時誤判

GET / HTTP/1.1
Host: example.com
Host: <payload>

GET / HTTP/1.1
Host: example.com
[tab] Host: <payload>

或是使用在上一篇的Case Study中的方法，寫入絕對路徑的URL:

GET http://example.com/ HTTP/1.1
Host: <payload>

註:<payload>可能是attacker的service或是一些用於攻擊的exploit。依情況而定

以上這些還有很多不同的變種，雖然HTTP Header Injection並不常見，但仍是需要注意的安全問題，它可以用來trigger或結合其他攻擊，像是Password reset poison，Web Cache Poison、bypass一些防禦/認證、SSRF等等。

下篇預告: 中場休息，OSCP小分享