日韩欧美人妻无码精品白浆,夜夜嗨AV免费入口,国产欧美官网在线看,高校回应聋哑女生因长相完美被质疑

前言

今天來看一個比較有意思的漏洞-HTTP報頭攻擊，也就是host頭攻擊。在我們的印象中host頭是我們所要訪問的域名，默認是不可控的，因為一旦改變我們就不能正確訪問目標地址。其實不然，在某些情況下，改變了host頭依然可以訪問目標。那么host頭在某些情況下也是我們可以控制的輸入，這也就為host頭攻擊提供了可能。

由于本人水平有限，文章中可能會出現(xiàn)一些錯誤，歡迎各位大佬指正，感激不盡。如果有什么好的想法也歡迎交流~~

什么是 HTTP Host 頭？

重新再來認識一下什么是host頭。

從 HTTP/1.1 開始，HTTP Host 頭是一個必需的請求頭，其指定了客戶端想要訪問的域名。例如我們訪問百度，發(fā)送的請求如下，會包含一個host頭。

HTTP頭的作用

當我們在瀏覽器中輸入一個網(wǎng)址時，首先會根據(jù)網(wǎng)址進行DNS解析，找到對應的IP地址，然后將請求發(fā)送到對應的IP地址。

我理解的域名與host頭其實并不是一個概念，域名是我們在瀏覽器中輸入要訪問的地址，而host頭是數(shù)據(jù)包中的一個值。

那么什么地方會用到http頭呢？

1）虛擬主機根據(jù)HTTP頭訪問具體的業(yè)務。目前由于IPV4的地址已經耗盡，所以越來越多的應用對應同一個公網(wǎng)IP，這種情況下，就需要根據(jù)HTTP頭來判斷具體需要訪問那個業(yè)務。

2）通過代理訪問后端組件。域名的IP解析到代理的公網(wǎng)IP，然后代理在根據(jù)HTTP頭來分配到具體的后端組件。我們經常使用的CDN也可以認為是這種情況。

HTTP頭是否可以修改

答案當然是可以修改的，如下面在burp里面可以直接修改host頭，修改host頭以后還可以正常訪問應用。

如下圖，修改以后還可以正常訪問

HTTP頭攻擊

HTTP Host 頭攻擊會利用以不安全的方式處理 Host 頭的漏洞網(wǎng)站。如果服務器隱式信任 Host 標頭，且未能正確驗證或轉義它，則攻擊者可能會使用此輸入來注入有害的有效負載，以操縱服務器端的行為。將有害負載直接注入到 Host 頭的攻擊通常稱為 "Host header injection"（主機頭注入攻擊）。

上面我們已經了解到就算改變了HTTP報頭也是可以正常訪問到應用的，那么如果后端使用HTTP報頭，并且沒有做過濾，那么就有可能造成危害。

HTTP報頭可能得攻擊場景

HTTP報頭攻擊可能存在以下的利用場景

1）重置密碼或者注冊用戶登場景發(fā)送重置鏈接取HTTP報頭的值

2）根據(jù)host頭限制一些資源的訪問

3）系統(tǒng)啟用了web緩存功能，可以利用web緩存投毒

4）根據(jù)host頭進行路由（基于路由的SSRF）

在portswigger上有關于http host攻擊的專題，如下：

鏈接：https://portswigger.net/web-security/all-labs#http-request-smuggling

類似密碼重置場景攻擊

幾乎所有需要登錄的網(wǎng)站都實現(xiàn)了下面的場景。下面以密碼重置來簡要概述這個場景

• 用戶輸入用戶名或電子郵件地址，然后提交密碼重置請求。

• 網(wǎng)站檢查該用戶是否存在，然后生成一個臨時的、唯一的、高熵的 token 令牌，并在后端將該令牌與用戶的帳戶相關聯(lián)。

• 網(wǎng)站向用戶發(fā)送一封包含重置密碼鏈接的電子郵件。用戶的 token 令牌作為 query 參數(shù)包含在相應的 URL 中，如 https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j。

• 當用戶訪問此 URL 時，網(wǎng)站會檢查所提供的 token 令牌是否有效，并使用它來確定要重置的帳戶。如果一切正常，用戶就可以設置新密碼了。最后，token 令牌被銷毀。

與其他一些方法相比，這個過程足夠簡單并且相對安全。然而，它的安全性依賴于這樣一個前提：只有目標用戶才能訪問他們的電子郵件收件箱，從而使用他們的 token 令牌。而密碼重置中毒就是一種竊取此 token 令牌以更改其他用戶密碼的方法。

這里有一個問題，如果我們拿到這個鏈接就可以修改用戶的密碼，而token是動態(tài)生成的，我們一般是無法獲取的。如果這個鏈接是根據(jù)host生成的，則給我們拿到這個鏈接提供了一種可能。如下：

如何構造一個密碼重置中毒攻擊

如果發(fā)送給用戶的 URL 是基于可控制的輸入（例如 Host 頭）動態(tài)生成的，則可以構造如下所示的密碼重置中毒攻擊：

1. 攻擊者根據(jù)需要獲取受害者的電子郵件地址或用戶名，并代表受害者提交密碼重置請求，但是這個請求被修改了 Host 頭，以指向他們控制的域。我們假設使用的是 evil-user.net 。

2. 受害者收到了網(wǎng)站發(fā)送的真實的密碼重置電子郵件，其中包含一個重置密碼的鏈接，以及與他們的帳戶相關聯(lián)的 token 令牌。但是，URL 中的域名指向了攻擊者的服務器：https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j 。

3. 如果受害者點擊了此鏈接，則密碼重置的 token 令牌將被傳遞到攻擊者的服務器。

4. 攻擊者現(xiàn)在可以訪問網(wǎng)站的真實 URL ，并使用盜取的受害者的 token 令牌，將用戶的密碼重置為自己的密碼，然后就可以登錄到用戶的帳戶了。

在真正的攻擊中，攻擊者可能會偽造一個假的警告通知來提高受害者點擊鏈接的概率。

即使不能控制密碼重置的鏈接，有時也可以使用 Host 頭將 HTML 注入到敏感的電子郵件中。請注意，電子郵件客戶端通常不執(zhí)行 JavaScript ，但其他 HTML 注入技術如懸掛標記攻擊可能仍然適用。

PortSwigger靶場測試

在這里添加用戶名，然后攔截數(shù)據(jù)包，將數(shù)據(jù)包改成你的exploit server。

然后當用戶訪問了這個鏈接以后，你就可以去查看你的exploit server的log日志，可以發(fā)現(xiàn)重啟密碼的鏈接

在瀏覽器中用原來的域名訪問這個重置密碼鏈接

跳出重置密碼的頁面

根據(jù)host限制資源的訪問

有時處于安全的考慮，會把某些功能限制成只能特定的IP或者host頭訪問，那么通過修改host頭就可能繞過這個限制。

portswigger靶場：https://portswigger.net/web-security/host-header/exploiting/lab-host-header-authentication-bypass

訪問robots.txt發(fā)現(xiàn)存在admin頁面，直接訪問顯示拒絕

將host頭改成localhost可能正常訪問

在實際的利用中，往往需要fuzz host頭的內容。

web緩存投毒

當存在Host頭攻擊的web站點不存在密碼重置的功能等場景時，由于不可能驅使用戶去抓包修改Host頭，該漏洞就顯得沒有什么作用。

但是，如果目標站點使用Web緩存，則可以通過緩存投毒給其他用戶提供帶有病毒的緩存響應。此時的Host頭攻擊漏洞轉變?yōu)轭愃芚SS存儲型類的漏洞。要構造Web緩存投毒攻擊：

• 需要尋找映射到其他用戶請求的緩存鍵；

• 下一步則是緩存此惡意響應；

• 然后，此惡意緩存將提供給嘗試訪問受影響頁面的所有用戶。

下面結合portswigger上的實驗來看一下

鏈接：https://portswigger.net/web-security/host-header/exploiting/lab-host-header-web-cache-poisoning-via-ambiguous-requests

打開這個實驗，可以看到，添加一個host頭，會返回在響應中，而且啟用了web緩存功能，那么我們可以將host頭替換成我們服務上同名的文件：/resources/js/tracking.js

如下

多請求幾次，使此請求被緩存下來

此時，其它用戶再去訪問該鏈接，就會訪問到這個已經緩存的頁面，也就是可以造成類似于xss的漏洞。

基于host頭進行路由

有的應用會根據(jù)host頭進行路由，那么在這種情況下，我們可以通過改變host頭來訪問內網(wǎng)的應用，也就是常說的SSRF。

這可能需要知道內部系統(tǒng)的IP地址（私有地址），一般可以通過信息收集或者Fuzz來判斷有效的私有IP地址（如枚舉192.168.1.1/16）

接下來還是看一下portswigger上面的實驗

鏈接：https://portswigger.net/web-security/host-header/exploiting/lab-host-header-routing-based-ssrf

該實驗已知內網(wǎng)中存在admin頁面并且通過host頭進行路由

直接訪問顯示404

爆破內網(wǎng)IP嘗試訪問

成功訪問到內網(wǎng)應用

?

在portswigger還有一個實驗，校驗了host頭的值，只要修改host的值就會拒絕服務，此時可以將host頭放到path中，如下面這種

GET http://evil.web-security-academy.net/ HTTP/1.1

HTTP host頭繞過

有時我們發(fā)現(xiàn)修改host頭時會受到限制，可以通過下面的方式進行繞過

1）檢查限制是否有缺陷，例如沒有限制端口號，只會驗證是否以允許的子域結尾等等

2）注入多個host頭

如果服務器端會將第二個Host頭優(yōu)先于第一個Host頭，就會覆蓋掉它的值，然后中轉組件會因為第一個Host頭指定了正確的目標而照常轉發(fā)這個請求包，這樣就能保證它可以順利到達服務器。

GET /example HTTP/1.1Host: vulnerable.comHost: evil.com

3）提供絕對URL

GET https://evil.com/ HTTP/1.1Host: vulnerable.com

4）注入覆蓋Host頭的字段

與Host頭功能相近的字段，如X-Forwarded-Host、X-Forwarded-For等，這些有時候是默認開啟的。

GET /example HTTP/1.1Host: vulnerable-website.comX-Forwarded-Host: attack-stuff

諸如此類，還有其他的字段：

• X-HostX-Forwarded-ServerX-HTTP-Host-OverrideForwarded

5）添加縮進或者換行

當一些站點block帶有多個Host頭的請求時，可以通過添加縮進字符的HTTP頭來繞過

GET /example HTTP/1.1 Host: attack-stuffHost: vulnerable-website.comHTTP Host頭攻擊防護

最簡單的方法是避免在服務器端代碼中使用前端獲取的host頭。

其他方法包括：

正確配置絕對域名URL

當必須使用絕對域名URL時，應在配置文件中手動指定當前域的URL，并引用配置的值，而不是從HTTP的Host頭中獲取。這種方法可防止密碼重置的緩存投毒。 白名單校驗Host頭的域

如果必須使用Host頭，需要正確校驗它的合法性。這包括允許的域，并使用白名單校驗它，以及拒絕或重定向對無法識別的主機請求。這包括但不僅限于單個web應用程序、負載均衡以及反向代理設備上。

不支持主機頭覆蓋

確保不適用與Host頭功能相近的字段，如X-Forwarded-Host、X-Forwarded-For等，這些有時候是默認開啟的。

總結

上面簡要介紹了一下HTTP報頭攻擊以及實際可能存在的場景，在實際的測試中遇到的比較少，常規(guī)漏洞已經不多見的情況下，可以多測一下這方面的漏洞。

參考鏈接

https://blog.csdn.net/angry_program/article/details/109034421

https://www.freebuf.com/articles/web/375432.html

閱讀原文：原文鏈接