嘉義市購物節存取控制缺失導致可未授權存取

Vulnerability Overview

ZDID: ZD-2026-00919
發信 Vendor: 嘉義市政府
Title: 嘉義市購物節存取控制缺失導致可未授權存取
Introduction: 無需驗證，任何人可用 ID 查詢他人積分、登錄狀況，並取得表單 CSRF、Nonce Token，造成未授權存取與資訊洩露。

處理狀態

目前狀態

公開

Last Update : 2026/09/13

新提交
已審核
已通報
未回報修補狀況
未複測
公開

處理歷程

2026/07/14 15:26:05 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:27:55 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:30:06 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:32:42 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:37:54 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:40:42 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:43:20 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:45:43 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 15:46:03 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 17:22:38 : 新提交 (由 Aaron 更新此狀態)
2026/07/14 17:23:48 : 新提交 (由 Aaron 更新此狀態)
2026/07/16 10:52:32 : 審核完成 (由 HITCON ZeroDay 服務團隊更新此狀態)
2026/07/23 16:45:17 : 審核完成 (由 HITCON ZeroDay 服務團隊更新此狀態)
2026/07/23 16:45:17 : 修補中 (由 HITCON ZeroDay 服務團隊更新此狀態)
2026/07/23 16:45:17 : 修補中 (由 HITCON ZeroDay 服務團隊更新此狀態)
2026/09/13 03:00:06 : 公開 (由 HITCON ZeroDay 平台自動更新)

詳細資料

ZDID：ZD-2026-00919
通報者：Aaronnnnnnn_ (Aaron)
風險：中
類型：存取控制缺陷 (Broken Access Control)

參考資料

攻擊者可經由該漏洞取得、修改、刪除系統中的其他使用者的資料，或連線至高權限使用者的頁面。

OWASP Top 10 - 2017 A5 - Broken Access Control
https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control

CWE-284: Improper Access Control
https://cwe.mitre.org/data/definitions/284.html

(本欄位資訊由系統根據漏洞類別自動產生，做為漏洞參考資料。)

敘述

簡述

invoiceRegisterForm_crud 端點（涵蓋一般檢視與 _mode=edit 編輯兩種模式）僅以 URL 參數中的 LINE userId 作為身分依據，後端未驗證請求者是否已登入或持有合法 Session。任何裝置在未登入狀態下，只要取得目標使用者的 lineID 或記錄 ID，即可直接讀取其個人資料與發票登錄紀錄；編輯模式甚至會回傳完整表單內容與提交所需的防偽權杖，前端雖有登入檢查，但屬於「先給資料、後跳轉畫面」的機制，並未真正阻擋資料外洩。

漏洞描述

該系統的 invoiceRegisterForm_crud 端點僅以 URL 查詢參數中的 LINE userId（lineID）或記錄 ID 作為身分依據，未於後端驗證請求者的實際登入狀態或 Session。任何持有此網址者，無論裝置、IP、是否登入，皆可直接讀取對應使用者的個人資料；若帶入 _mode=edit 參數，甚至可取得完整的編輯表單內容，包含已預填的真實資料與提交所需的CSRF Token、Nonce Token。

該編輯頁面雖然內嵌 LINE LIFF SDK 並有登入檢查邏輯，但其運作方式是：後端先完整回傳資料與表單，前端 JavaScript 才事後檢查 liff.isLoggedIn()，未登入才將畫面導向他處。這代表驗證僅存在於前端，資料外洩在伺服器回應當下即已發生；若請求不執行 JavaScript（例如以 curl 發送），會直接取得完整回應內容，不會有任何跳轉行為。此為「前端驗證掩蓋後端缺陷」的典型案例。

重現步驟

前提環境

使用與原瀏覽環境不同的裝置或網路（例如更換 Wi-Fi / 改用行動網路）
不登入 LINE、不攜帶任何 Cookie 或 Session Token
使用全新無痕視窗，或直接以 curl 發送請求（不帶任何 header）

步驟一：直接發送未授權請求（檢視模式）

這裡的ID不是一般加好友的ID，而是LIFF 辨識用的LINE ID

curl -v "https://chiayi888-2026.bitlly.co/web/userview/travelAdvisory/view/_/invoiceRegisterForm_crud?lineID={自行帶入自己的}"

步驟二：直接發送未授權請求（編輯模式）

這個步驟的ID需要從第一步驟的html裡面拿到發票的ID。

curl -s "https://chiayi888-2026.bitlly.co/web/userview/travelAdvisory/view/_/invoiceRegisterForm_crud?_mode=edit&id={自行帶入發票ID}" -o response.html

步驟三：觀察回應

記錄 HTTP status code（預期為 200 OK，而非導向登入頁的 302 或拒絕存取的 401 / 403）
確認 response body 是否包含個資欄位（姓名、發票資料等）
於編輯模式的回應中，確認表單欄位是否已預填真實資料（而非空白表單），並確認是否包含 CSRF Token、Nonce Token 等欄位

步驟四：查看編輯頁面的程式碼

在編輯頁面檢查LIFF是否登入，若未登入則跳轉，但html資料已送到用戶端。

修補建議

1. 後端應驗證當前請求的 Session / Token 所屬使用者，是否與欲存取資料的 `lineID` 相符，而非僅憑 URL 參數放行
2. 避免將可用於身分辨識的識別碼（如 LINE userId）直接暴露於 URL 查詢字串
3. 改用具時效性、可撤銷的 Session Token 取代固定不變的使用者 ID 作為存取憑證
4. 針對 `_crud` 類型路由，逐一檢查 Create / Read / Update / Delete 各操作是否皆有獨立且正確的身分驗證與授權檢查
5. 編輯類端點應在**後端回傳資料前**先行驗證身分，不應仰賴前端 JavaScript（如 LIFF SDK 的 `isLoggedIn()` 檢查）作為唯一的存取控制手段
6. 檢視回應內容是否不必要地暴露 CSRF Token 等防偽資訊給未驗證身分的請求者