悟空科技股份有限公司 低權限後台帳號可繞過 RBAC，跨站存取逾 12 萬筆付費使用者敏感資料及管理功能 - HITCON ZeroDay

0. 摘要（Summary）

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

而串聯未授權使用者可匿名建立後台帳號並任意指定 role與後台可被公開發現之漏洞：

• 任意使用者可匿名建立 PB user 帳號，請求中將 role 參數設為空陣列（"role": []），或者不帶 role 參數，即可建立一個未指派任何角色的低權限 PB user 帳號。
• 建立低權限 PB user 帳號後，連上後台管理頁面 https://helper.diyidphoto.com，使用相同帳號密碼即可登入。
• role 參數的值，可影響到後台左側管理控制板（admin panel）的功能顯示與否。
• 透過載入的 HTML 與 JavaScript bundle，可知道後台管理頁面裡的各個路徑、相對應的存取權限（例如roles: ["admin", "tw-service", "jp-service"]）與端點功能。

正常來說，未指派任何角色的低權限 PB user 帳號（"role": []）不應能存取後台資料或執行任何 API。

然而測試後發現，只要知道後台管理頁面裡的路徑/端點，仍可直接跨台灣站與日本站存取應屬於 admin / tw-service / jp-service 的 module 與 API，包括：

• /orders
• /shipping
• /idphoto
• /gallery
• /stats
• /click-stats
• /photos-test
• /redis-test
• /queue-monitor
• /collections
• /free-codes

且多個後端 API 也會回傳真實資料與可操作對應功能，例如：

• 使用者訂單資料，包括其上傳之原始照片、經處理後的證件照、姓名、Email、電話
• 使用者郵寄地址
• 重製碼的列表，與其新增與刪除功能
• 已上傳照片集的照片資料
• GCS bucket 物件之資料與值
• 網站營運統計資料

整體看起來，後台雖在左側管理控制板有依據 role 篩選是否可見相關功能，但後端授權檢查不足，導致低權限帳號仍有能力可跨站執行或存取僅限管理員（admin）或客服（service）角色的後台資料。

可能原因將放在後台身份驗證可被繞過中。

1. 受影響功能（Affected Feature）

• 功能：後台管理頁面與多個僅限管理員或客服角色使用的管理功能

• 存取條件：需要可登入後台的低權限 PB user 帳號（"role": []）

• 主要受影響路徑：

  • /orders
  • /shipping
  • /idphoto
  • /gallery
  • /stats
  • /click-stats
  • /photos-test
  • /redis-test
  • /queue-monitor
  • /collections
  • /free-codes

• 主要影響資料類型：

  • 台日兩站之使用者訂單資料
  • 台日兩站之使用者上傳的原始照片、經處理後的證件照、姓名、Email、電話
  • 台灣站的使用者郵寄地址
  • 台日兩站之使用者的支付細節（payment detail）
  • 台日兩站所使用之重製碼
  • GCS bucket 物件之資料
  • 台日兩站之已上傳照片集的圖片、圖片連結與 token
  • 台日兩站之網站營運統計資料
  • 內部錯誤訊息洩漏

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

• 需要擁有一個可登入 helper.diyidphoto.com 後台的低權限 PB user 帳號（"role": []）。可參考未授權使用者可匿名建立後台帳號並任意指定 role建立。
• 需要知道後台相關功能之路徑，以便登入後經由瀏覽器輸入路徑，或用 Burp Suite 等工具呼叫相關 API。可參考後台可被公開發現。

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

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

步驟 1：建立一個新低權限 PB user 帳號

1. 在 Burp Suite 中的 Repeater，對以下端點發送建立帳號請求，在 body 中填入 email / password 並將 role 欄位設為空陣列：

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

{
  "email": "<Redacted_Email>",
  "password": "<Redacted_Password>",
  "passwordConfirm": "<Redacted_Password>",
  "role": []
}

1. 送出請求後，可在 response 中查看到新建立的 user record，以及 "role": [] 被保存。

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

步驟 2：使用該帳號登入後台管理頁面

1. 在 Burp Suite 的瀏覽器連上 https://helper.diyidphoto.com/login，並填入步驟 1 建立的 email / password 登入（或輸入步驟 1 的 username / password 登入）。

2. 登入後，即可觀察到左側管理控制板未顯示任何功能，而右側則會是訂單查詢（/orders）的相關功能，例如查詢特定日期、特定訂單等。

若稍微留意，可以發現在登入後、或進行接下來的重現步驟操作，左側管理控制板會有一瞬間可看到所有功能，接著未顯示任何功能。

1. 點擊左上角 DIY 旁類似雙彎曲箭頭的按鈕，即可切換台灣站與日本站之後台功能。

步驟 3：直接存取訂單查詢（/orders）功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/orders 進入訂單查詢功能。

2. 依日期或關鍵字查詢訂單，會發現低權限 "role": [] 帳號可讀取訂單相關資料，查看使用者上傳之原始照片、經處理後的證件照、姓名（日本站尤其明顯）、Email、電話（台灣站尤其明顯）。

3. 低權限 "role": [] 帳號可修改使用者資料。

   1. 開另一個無痕網頁連上台灣站 https://diyidphoto.com/zh-tw/ 或日本站 https://jp.diyidphoto.com/，上傳測試圖片，並一路進行到跳轉付款頁面。
   2. 接著在 https://helper.diyidphoto.com/orders 以日期進行訂單查詢。請注意，查詢台灣站訂單應在台灣站後台，與查詢日本站訂單應－點擊類似雙彎曲箭頭的按鈕－切換至日本站後台，否則會查詢不到。
   3. 點擊修改功能，編輯使用者姓名、email或手機（也可三者一起改）並完成修改，即可確認低權限 "role": [] 帳號可進行修改使用者姓名、email與手機等操作。

1. 退款、取消發票、重寄郵件等功能，由於本測試遵循最小影響原則，為避免影響正式環境及商業營運，因此本次未執行該操作，建議在修正漏洞時此類 API 需要一併檢查是否也有越權執行等相關問題。

2. 藉由後台可被公開發現與 Burp Suite 的 Proxy 頁籤中的 HTTP history 可發現，本路徑之相關 API 功能如以下：

步驟 4：直接存取郵寄管理（/shipping）功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/shipping 進入郵寄管理功能。

2. 可發現低權限 "role": [] 帳號可讀取當日郵寄資料，包括使用者姓名、電話、地址等高敏感資訊，也可點擊查詢郵遞區號功能以進行查詢。

這裡值得注意的是：

• 日本站後台的管理控制板並沒有 /shipping 功能，而若在日本站後台進入 /shipping 會看見台灣站的郵寄資料。
• 點擊「查詢郵遞區號」功能後，由 Burp Suite 可見使用者之地址資料被送往第三方 zip5.5432.tw 進行郵遞區號查詢，經測試後暫時排除第三方寫入郵遞區號時造成 XSS 等相關漏洞。
• 「標示為已郵寄功能」可能影響到商業營運，因此本次未執行該操作，建議在修正漏洞時一併檢查此功能是否也有越權執行等相關問題。

1. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，本路徑之相關 API 功能如以下：

步驟 5：直接存取快洗證件照（/idphoto）功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/idphoto 進入快洗證件照功能。

2. 依日期或關鍵字查詢訂單，會發現低權限 "role": [] 帳號可讀取訂單相關資料，包括使用者之證件照。

• 日本站後台的管理控制板並沒有 /idphoto 功能，而若在日本站後台進入 /idphoto 會看見與台灣站相同的資料。
• 對訂單點擊「更多」再點擊「支付細節」，可查看該訂單之支付詳細資料（包括Email、Phone等資訊），而裡面也有「申請退款」與「作廢發票」功能；這兩者功能可能影響到商業營運，因此本次未執行該操作，建議在修正漏洞時此類 API 需要一併檢查是否也有越權執行等相關問題。
• 對訂單點擊「更多」再點擊「完整分析」，可查看該訂單的照片之 AI 分析數據。
• 「重設列印」功能可能影響到商業營運，因此本次未執行該操作，建議在修正漏洞時此類 API 需要一併檢查是否也有越權執行等相關問題。

這裡值得注意的是：

• 根據 /idphoto 此端點的可見資料，會發現照片量相對不多且皆集中在非假日（週六日）上傳，看起來像是仍在測試中。

• 在訂單的「支付細節」裡，有一個資料欄位是 RequestJSON，點擊查看數據，可發現 webhook 參數中可見 https://qkidphoto.goqoo.com/complete?order_id=...&token=... 這連結。

  • 透過 Google dork site:qkidphoto.goqoo.com 進行查詢，未發現該網域的公開索引結果。

• 另一個無痕網頁連上 https://qkidphoto.goqoo.com 這網址，上傳測試圖片，並一路進行到付款頁面。

  • 藉由 Burp Suite 的 HTTP history 可發現，此網址的圖片上傳方式與台灣站 https://diyidphoto.com/zh-tw/ 和日本站 https://jp.diyidphoto.com/ 不同。

  • https://qkidphoto.goqoo.com 是使用 POST multipart/form-data 作為方法

  • https://diyidphoto.com/zh-tw/ 和 https://jp.diyidphoto.com/ 是使用 WebSocket 作為方法

  • 因此，https://qkidphoto.goqoo.com 比較像 https://diy.goqoo.com.tw/QKPhoto/Chi/MainMenu.php 相關端點（例如 /QKPhoto/Chi/UploadFile6.php?ano=... 或 /QKPhoto/Chi/UploadFile7.php?ano=... ，詳細路徑可見訂單流程參數存在 IDOR） 所用之方式

• 詳細比較 https://qkidphoto.goqoo.com 與 https://diy.goqoo.com.tw/QKPhoto/Chi/MainMenu.php 相關端點的行為差異，會發現：

  • https://qkidphoto.goqoo.com在上傳圖片時會給一組不可預測、或難以預測之 order_id 與 token，此行為像是 https://diyidphoto.com/zh-tw/ 和 https://jp.diyidphoto.com/

  • 但 https://qkidphoto.goqoo.com 之 OrderID 為 8 碼，台日兩站 OrderID 為 7 碼

  • https://diy.goqoo.com.tw/QKPhoto/Chi/MainMenu.php 相關端點會給遞增且可預測之 ano / AlbumNo 參數（因而造成 IDOR）

  • 因此推測 https://qkidphoto.goqoo.com 這網址可能是為了修正 IDOR 漏洞、或將其融進後台系統中而開發

1. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，本路徑之相關 API 功能如以下：

步驟 6：直接存取已上傳照片集（/gallery）功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/gallery 進入已上傳照片集功能。

2. 可發現低權限 "role": [] 帳號可讀取當日使用者上傳之原始照片與經處理後的照片。

這裡值得注意的是：

• 台灣站 https://diyidphoto.com/zh-tw/ 和日本站 https://jp.diyidphoto.com/ 上傳的照片都會出現在此，因此 /gallery 端點可能保存了兩站的照片內容。
• 未付款訂單會被標註綠字的準備付款標籤，可被用於未付款訂單存取控制不一致與日本站資料保存情形可能與常見問題不一致。

1. 調整日期，即可發現低權限 "role": [] 帳號可讀取調整的日期的照片。

2. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，本路徑之相關 API 功能如以下：

步驟 7：直接存取數據統計(/stats) 與點擊統計 (/click-stats)功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/stats 進入數據統計功能，即可發現低權限 "role": [] 帳號可讀取網站營運統計資料，且可使用相關功能，例如調整日期、免費/付費、日/月/年、台灣站/日本站，獲取更詳細的網站營運統計數據。

2. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/click-stats 進入點擊統計功能，即可發現低權限 "role": [] 帳號可讀取日本站重製碼的點擊統計資料，且可使用相關功能，例如調整日期區間獲取更詳細的日本站重製碼統計數據。

1. 日本站後台的管理控制板沒有 /stats 與 /click-stats 功能。

2. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，以上兩者路徑之相關 API 功能如以下：

訂單統計（/stats）

JP share-code 點擊統計（/click-stats）

步驟 8：直接存取照片測試（/photos-test）功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/photos-test 進入照片測試功能。

2. 可發現低權限 "role": [] 帳號可讀取 / 進入列出的資料夾，其中包括 anime 與 diyidphoto 等。

3. 進入任一資料夾，點擊「探索此目錄下的檔案」功能，會發現低權限 "role": [] 帳號可列出該資料夾內的檔案內容；而就目前測試結果，幾乎都是後台的測試照片。

1. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，本路徑之相關 API 功能如以下：

這裡值得注意的是：

• 端點 /api/unit-test/list-files/ 的 Response 中含有 GCS bucket 物件之資料與值，包括以下：

  • Bucket
  • Name
  • ContentType
  • Owner
  • Size
  • ContentEncoding
  • ContentDisposition
  • MD5
  • CRC32C
  • MediaLink
  • Metadata
  • Generation
  • StorageClass
  • Created / Deleted / Updated
  • CustomerKeySHA256
  • Etag
  • CustomTime

其中，雖不能直接由 MediaLink 之連結 https://storage.googleapis.com/download/storage/v1/b/... 直接讀取圖片，但可透過 https://helper.diyidphoto.com/api/unit-test/img/ 加上 Name 之路徑，即可以低權限 "role": [] 帳號查看該圖片。

步驟 9：直接存取 Redis 測試(/redis-test)功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/redis-test 進入 Redis 測試功能。

2. 可發現低權限 "role": [] 帳號可進入，且在 Queue Key 欄位輸入值，其會顯示在 Redis Preview 上；但本測試採最低限度，因此沒有按下「送出請求」按鈕，建議在修正漏洞時此類 API 需要一併檢查是否也有越權執行等相關問題。

1. 藉由後台可被公開發現可發現，本路徑之相關 API 功能包含以下：

步驟 10：直接存取佇列監控(/queue-monitor)功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/queue-monitor 進入佇列監控功能。

2. 可發現低權限 "role": [] 帳號可進入，並監控以下 6 個 queue：

• diyTW
• diyJP
• detectTW
• detectBoca
• relight
• photocutter

1. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，本路徑之相關 API 功能包含以下：

步驟 11：直接存取集合管理(/collections)功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/collections 進入集合管理功能，即可發現：

• 會直接跳出錯誤訊息 獲取集合列表失敗: Error 1146 (42S02): Table 'diyidphoto.prod_collections' doesn't exist。
• 點擊「新增集合」功能，填妥相關資訊並點擊確認建立後，也會跳出錯誤訊息建立集合失敗：Error 1146 （42S02）：Table 'diyidphoto.prod_collections' doesn't exist。
• 此狀況無論是 "role": [] 或 role:["admin"] 皆會發生，因此暫時推測這可能是網站後台頁面並未使用此功能、或使用其它方式以替代此功能而產生的結果。

1. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，本路徑之相關 API 功能包含以下：

步驟 12：直接存取新增重製碼（/free-codes）功能

1. 在登入狀態下，在瀏覽器的網址列輸入 https://helper.diyidphoto.com/free-codes 進入新增重製碼功能。

2. 可發現低權限 "role": [] 帳號可讀取所有重製碼清單。

3. 點擊「產生重製碼」，即可新增一個重製碼；在該重製碼的操作欄位有一個垃圾桶 icon，點擊後按確認，即可將該重製碼刪除。此行為證明低權限 "role": [] 帳號可使用產生及刪除重製碼功能。

這裡值得注意的是，台日兩站後台應是共用相同重製碼清單，因為無論在哪一站新增或刪除重製碼，另一站皆會出現或消失該重製碼。

1. 藉由後台可被公開發現與 Burp Suite 的 HTTP history 可發現，本路徑之相關 API 功能如以下：

4. 預期行為（Expected Behavior）

低權限帳號不應能存取任何僅限管理員或客服角色使用的後台資料與功能，也不應能呼叫相關 API。伺服器應拒絕此類未經授權的請求，並回傳 401 Unauthorized 或 403 Forbidden。

5. 實際行為（Actual Behavior）

即使帳號為低權限 "role": []，仍可跨站別存取及操作多個後台 API 與管理功能，包括讀取敏感資料，以及修改使用者資料、產生與刪除重製碼等操作，顯示後台未落實伺服器端 RBAC 與授權檢查。

6. 影響（Impact）

此問題使低權限帳號未經授權即可存取/操作台日兩站後台之使用者高敏感資料、後台功能及網站營運統計資訊，可能風險包括：

• 台日兩站之使用者高敏感個資外洩，包括原始照片、證件照、郵寄地址、聯絡方式與付款方式等
• 網站重製碼外洩或被濫用
• 後台營運統計資料外洩
• GCS bucket 物件結構與其資料外洩
• 攻擊者利用後台資料進一步串聯其它漏洞或擴大攻擊面

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

問題可能是後端未確實實施 RBAC （server-side RBAC enforcement），整體授權模型（authorization model）不完整。

可能原因包括：

1. 後端 API 沒有在每個端點強制檢查 role，且高敏感資料沒有進行回應最小化（response minimization）或去識別化等操作
2. 沒有預設直接拒絕 role 為空、缺少或未知的情況
3. 前端 route / menu / button gating－例如管理控制面板（admin panel）－被當成主要安全邊界，卻未考慮其被繞過的狀況
4. 後台將 role、pb_role、active_site 等資訊當成授權標準，但這些參數的來源沒有被嚴格檢查與保護

8. 嚴重性評估（Severity Assessment）

嚴重（Critical）

理由：

• 低權限 "role": [] 帳號可跨站別存取及操作多個原應僅限管理員或客服角色使用的後台功能，包括讀取高度敏感資料、修改使用者資料，以及新增與刪除重製碼
• 影響範圍橫跨台日兩站，且影響資料多元，包括使用者訂單、郵寄功能、使用者上傳之原始照片與經網站處理後的證件照、payment 資料、網站重製碼、GCS bucket 物件與網站營運統計資料等
• 問題發生在後台管理系統，理應有嚴格的角色與站別限制

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]