在上一篇的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所能夠造成的其他危害。
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小分享