ChatGPT-Next-Web漏洞利用分析（CVE-2023-49785）

1. 漏洞介紹

日常網上衝浪，突然粗看以爲是有關Chat-GPT的CVE披露出來了，但是仔細一看原來是ChatGPT-Next-Web的漏洞。漏洞描述大致如下：（如果有自己搭建了還沒更新的速速修復升級防止被人利用，2.11.3已經出來了）

NextChat，也稱爲 ChatGPT-Next-Web，是與 ChatGPT 一起使用的跨平臺聊天用戶界面。 2.11.2 及之前的版本容易受到服務器端請求僞造和跨站點腳本攻擊的影響。2024年3月，互聯網上披露CVE-2023-49785,攻擊者可在無需登陸的情況下構造惡意請求造成SSRF，造成敏感信息泄漏等。

 

2. 漏洞分析

定位到漏洞代碼：app/api/cors/[...path]/route.ts：

也就是大致如下內容：

import { NextRequest, NextResponse } from "next/server";
​
async function handle(
  req: NextRequest,
  { params }: { params: { path: string[] } },
) {
  if (req.method === "OPTIONS") {
    return NextResponse.json({ body: "OK" }, { status: 200 });
  }
​
  const [protocol, ...subpath] = params.path;
  const targetUrl = `${protocol}://${subpath.join("/")}`;
​
  const method = req.headers.get("method") ?? undefined;
  const shouldNotHaveBody = ["get", "head"].includes(
    method?.toLowerCase() ?? "",
  );
​
  const fetchOptions: RequestInit = {
    headers: {
      authorization: req.headers.get("authorization") ?? "",
    },
    body: shouldNotHaveBody ? null : req.body,
    method,
    // @ts-ignore
    duplex: "half",
  };
​
  const fetchResult = await fetch(targetUrl, fetchOptions);
​
  console.log("[Any Proxy]", targetUrl, {
    status: fetchResult.status,
    statusText: fetchResult.statusText,
  });
​
  return fetchResult;
}

在這段代碼中，這裏沒有做任何的安全防護。params.path 是通過請求參數傳入的，這意味着用戶可以控制請求的路徑部分。這個路徑部分會被直接拼接到一個新的 URL 中，並在後續的代碼中被用於發起請求，以繞過訪問控制、訪問內部系統或執行其他攻擊。

舉個例子，當你訪問 /api/cors/https/baidu.com 時，請求將被路由到這段代碼中。在這裏，protocol 將被設置爲 https，subpath 將被設置爲 ['baidu.com']。然後，這兩部分將被拼接成 https://baidu.com，作爲目標 URL。接下來，根據代碼的邏輯，將會使用 fetch 發起一個對 https://baidu.com 的請求。這個請求的方法和請求體等信息將根據原始請求中的信息進行配置，然後將響應返回給客戶端。

我們驗證一下，果然存在。

至於披露着所說的反射型XSS，則完全是因爲這裏是用的fetch發包，fetch方法也支持 data 協議,且對後續的參數沒有過濾限制導致的，所以我們通過參數拼接如下即可實現：

/api/cors/data:text%2fhtml;base64,PHNjcmlwdD5hbGVydCgiQ1ZFLTIwMjMtNDk3ODUiKTwvc2NyaXB0Pg==%23

3. 總結

沒想到一個64.5k star 的項目之前居然對SSRF一點防護都沒有做。

/api/cors 端點作爲一個開放代理的設計，允許未經身份驗證的用戶通過它發送任意的 HTTP 請求。這個端點似乎是爲了支持將客戶端聊天數據保存到 WebDAV 服務器而添加的。

【---- 幫助網安學習，以下所有學習資料免費領！領取資料加 we~@x：dctintin，備註 “開源中國” 獲取！】

① 網安學習成長路徑思維導圖
② 60 + 網安經典常用工具包
③ 100+SRC 漏洞分析報告
④ 150 + 網安攻防實戰技術電子書
⑤ 最權威 CISSP 認證考試指南 + 題庫
⑥ 超 1800 頁 CTF 實戰技巧手冊
⑦ 最新網安大廠面試題合集（含答案）
⑧ APP 客戶端安全檢測指南（安卓 + IOS）

我查看了最新的源代碼：

具體的官方修復思路如下：

1. 移除開放代理端點：最終修復方案中，移除了原始的開放代理端點/api/cors。

2. 替換爲特定用途的端點：取而代之的是添加了兩個新的端點/api/upstash和/api/webdav，這些端點具有特定的用途，分別用於與 Upstash 和 WebDAV 服務進行集成。這種替換的方式限制了端點的功能範圍，並提供了更專門化的功能，有助於減少系統的安全風險。

3. 增加安全驗證和限制：

   1. /api/upstash

      1. 限制目標URL：修復代碼首先通過檢查請求參數中的endpoint來限制目標URL。它要求目標URL必須是以.upstash.io結尾的有效URL，這樣就限制了請求只能發送到特定的Upstash服務。

      2. 限制請求方法：修復代碼還對請求中的操作類型進行了限制。它只允許get和set兩種操作類型的請求，如果請求的操作類型不是這兩種之一，則會返回403 Forbidden響應。

   2. /api/webdav

      1. 請求方法限制： 修復代碼只允許特定的HTTP請求方法，包括MKCOL、GET和PUT。對於其他不允許的請求方法，如POST等，會返回403 Forbidden響應。

      2. 目標路徑驗證： 修復代碼對於不同的請求方法，會對目標路徑進行不同的驗證：

         • 對於MKCOL請求，只允許請求目標路徑爲指定的folder，如果請求的目標路徑不是以指定的folder結尾，則返回403 Forbidden響應。

         • 對於GET請求，只允許請求目標路徑爲指定的fileName，如果請求的目標路徑不是以指定的fileName結尾，則返回403 Forbidden響應。

         • 對於PUT請求，同樣只允許請求目標路徑爲指定的fileName，如果請求的目標路徑不是以指定的fileName結尾，則返回403 Forbidden響應。