登入後弱點掃描是什麼？Authenticated Scan 的帳號、Session、角色與安全測試完整指南

先講結論：Authenticated Scan 不是「有登入」就算完成

匿名掃描器從公開入口探索網站，能檢查登入頁、公開表單、靜態資源與不需身分的 API；但使用者個人資料、訂單、內部後台、管理功能與多數商業流程通常都位於登入後。若只掃公開區域，報告可能很乾淨，實際上卻只是沒有進入風險最集中的應用範圍。

登入後掃描的第一個成果不是更多弱點，而是可證明的覆蓋：哪一個帳號以哪一種角色登入、Session 在什麼時間有效、走過哪些 Route 與 API、嘗試過哪些不應允許的操作，以及哪些流程因安全或業務限制沒有測試。只有這些證據完整，弱點數量才有解讀價值。

因此成熟做法會把 Authenticated Scan 當成受控的安全測試工作流。它包含書面授權、帳號與資料準備、登入與 Session 健康檢查、角色化探索、負向授權驗證、副作用限制、證據去識別化、修復與複驗；其中任何一環缺失，都可能造成漏掃、誤判或營運事故。

• 先定義可掃資產、帳號、角色、租戶、時間窗與禁止操作
• 登入後持續確認 Session 與權限仍有效，不以 HTTP 200 當成成功
• 正向測試確認本人可做的事，負向測試確認他人、他租戶或低權限角色不能做
• 測試資料、通知、付款、刪除與外部整合必須有明確隔離或阻擋
• 報告同時呈現弱點、覆蓋、限制、證據與可重現的修復驗證方式

匿名掃描與登入後掃描看見的攻擊面有什麼不同？

兩者不是互斥方案。匿名掃描模擬未取得帳號的外部攻擊者，登入後掃描則模擬已取得合法低權限身分、受邀使用者、內部成員或遭接管帳號後能觸及的範圍。完整檢測通常先建立匿名基線，再逐角色執行登入後測試，最後比較不同身分看到的 Route、物件與動作。

登入後覆蓋不只多了頁面數。當請求帶有 Cookie、Bearer Token 或其他身分資訊，應用會載入特定使用者、組織與租戶資料，也會開放建立、修改、匯出、邀請、審核等動作。這些以物件關係與業務狀態為核心的風險，往往無法從登入頁外推。

登入後掃描能證明什麼？又不能證明什麼？

它能證明的是：在指定時間、環境、帳號、角色、資料與工具設定下，測試流程成功抵達的範圍，以及其中觀察到的弱點。它不能證明所有角色、所有狀態、所有租戶、所有 API 或所有業務邏輯都安全；未覆蓋與無法驗證的部分必須明列，而不是被零弱點數隱藏。

自動化特別適合重複檢查輸入點、回應、Cookie、Header、常見注入與已知配置問題，也能協助發現可疑的權限差異。但需要業務意圖才能判斷的流程，例如誰能核准退款、哪種合約可跨部門檢視、停用員工的歷史資料應保留到何時，仍需要安全人員與系統 Owner 共同定義預期結果。

第一道安全控制：先取得書面授權並建立範圍表

登入後掃描會執行比匿名掃描更接近真實使用者的操作，可能建立資料、觸發通知、佔用額度或呼叫第三方服務。開始前應由資產或服務 Owner 明確授權目標網域、API、環境、來源 IP、測試帳號、允許方法、時間窗、速率、聯絡人、停止條件與資料處理方式。NIST SP 800-115 也將規劃、執行、分析與緩解視為完整技術安全評估的一部分。

授權不能只寫『可以掃網站』。若 SSO 會跳到外部 IdP、頁面嵌入付款或客服服務、API 連到另一個網域，掃描器可能自動跟隨連結進入第三方範圍。應建立 Allowlist 與 Denylist，預設不對未明確列入的主機送出主動測試。

正式環境還是測試環境？依目標與副作用分層

測試環境便於準備帳號、覆蓋角色與控制副作用，但只有在版本、設定、功能旗標、身分整合、資料模型與網路邊界接近正式環境時，結果才有代表性。正式環境能驗證真實部署與控制，卻必須採用更保守的 Payload、速率與操作範圍。

實務上可分三層：在 CI 或隔離環境做廣泛主動測試；在類正式環境做完整登入、角色、租戶與業務流程；在正式環境做低風險驗證、配置觀測與經核准的精準複驗。不要為了方便在測試環境關閉 WAF、MFA 或授權檢查後，仍把結果當成正式風險結論。

帳號矩陣怎麼設計？至少要能比較人、角色與租戶

只提供一個 Administrator 帳號，是登入後掃描最常見也最嚴重的設計缺陷。它或許能讓工具抵達較多頁面，卻無法驗證一般使用者是否能越權，也無法區分功能本來就允許，還是授權檢查缺失。

最低可用矩陣通常包含同角色兩個帳號，用來交換物件 ID 驗證水平越權；至少一組高低權限角色，用來驗證垂直越權；若為 SaaS 或共享平台，再加入另一租戶的同角色帳號，驗證租戶隔離。高敏感系統還應準備停用、鎖定、權限剛變更與邀請尚未完成等生命週期狀態。

為什麼不能只用 Super Admin？最小權限才看得見邊界

OWASP Authorization Cheat Sheet 建議最小權限、預設拒絕，並在每一個請求驗證權限。掃描若只用最高權限帳號，幾乎所有成功回應都可能是預期行為，工具沒有足夠對照組判斷越權；同時帳號一旦外洩或 Payload 失控，影響範圍也最大。

應以低權限帳號作為主要掃描身分，管理者帳號只用於確實需要的後台範圍，並設定更嚴格的 Endpoint Allowlist。若某功能只能由極高權限角色執行，也應為掃描建立專用角色，只授予必要範圍，而不是共用日常營運的真實管理者。

• 每個掃描帳號只授予該次測試需要的最小權限
• 不同角色使用獨立 Scan Profile、Cookie Jar 與報告標籤
• 管理者測試限制可修改設定、成員、金鑰與整合的端點
• 測試前後比對權限，避免掃描期間發生 Privilege Drift
• 測試結束立即停用或回收帳號、Session、Token 與 API Key

測試資料與副作用：先定義什麼可以建立、修改與刪除

登入後爬行器會尋找表單、按鈕與 API；如果沒有副作用控制，可能送出邀請、發布內容、刪除資料、重設密碼、建立訂單、呼叫簡訊或消耗第三方額度。『使用測試帳號』不等於操作就是安全的，因為測試帳號仍可能連到真實租戶、通知管道與帳務系統。

最安全做法是建立可辨識的合成資料集與專用測試租戶，將郵件、簡訊、付款、Webhook 與外部整合指向 Sandbox 或 Sink。若正式環境無法完全隔離，使用唯讀模式與 URL／方法 Denylist，對必要寫入採用精準案例而非自動探索。

先盤點登入機制：表單、SSO、MFA、API Token 與 mTLS

掃描器能否建立身分，取決於實際登入流程。傳統表單可能只需提交帳密並擷取 Cookie；SPA 常由前端呼叫 API 取得 Token；OIDC 或 SAML 會跨站導向 IdP；MFA 可能需要 TOTP、Push、Passkey 或裝置綁定；API 也可能使用 OAuth Client Credentials、API Key 或 mTLS。每種機制的自動化方式與安全邊界不同。

不要透過停用 MFA、繞過 CAPTCHA 或在前端硬塞 Token 來『讓掃描跑起來』。應由 IAM 與安全團隊建立經核准的測試路徑，例如測試 IdP、專用 Conditional Access Policy、受限來源 IP、短效測試 Token 或人工登入後安全移交 Session。任何例外都要限時、限範圍、可稽核並在測試後撤銷。

Session 健康檢查是必要 Gate：不要把登入頁當成已登入頁

掃描器最危險的靜默失敗，是 Session 過期後被導回登入頁，卻因回應仍是 200 OK 而繼續執行。最後任務顯示完成，實際大部分時間都在重複掃登入畫面。健康檢查必須確認內容與身分，而不只是 Status Code。

每次開始、定期執行與敏感階段前，都應呼叫穩定的 Auth Check，例如 `/me` 或登入後專屬頁面，驗證使用者 ID、角色、租戶與預期標記；同時設定失敗指紋，例如登入表單、SSO Redirect、`401`、`403` 或匿名導覽。健康檢查失敗時應暫停、重新登入並隔離失效期間的結果。

Cookie 與 Token 要怎麼保存、更新與隔離？

OWASP 指出 Session ID 或 Token 在有效期間近似於使用者完成的最強驗證，因此掃描憑證與 Session 都應視為 Secret。每個帳號使用獨立 Cookie Jar；儲存時加密；限制可讀取的掃描節點與人員；傳輸全程使用 TLS；Log、截圖、HAR 與報告不得保留完整 Cookie、Authorization Header、Refresh Token 或 API Key。

若應用在登入、重新驗證或權限提升後輪替 Session，掃描流程必須接收新值而不能固定重播舊 Cookie。若 Access Token 需要 Refresh，應在受控步驟執行並記錄時間，不要把長效 Refresh Token 散布到多個 Worker。所有 Session 在測試結束後都應從伺服器端失效，而不只是刪除本機檔案。

• 每個角色與帳號使用獨立憑證、Session 與結果命名空間
• Secret 只在執行時注入，不寫入程式碼、設定檔或任務輸出
• 報告僅保留 Token 雜湊或末段指紋，足以關聯但無法重播
• Session 更新、逾時、登出與撤銷都要有明確測試案例
• 測試結束撤銷伺服器端 Session、Refresh Token、API Key 與憑證

角色化探索：每一個身分都要有自己的攻擊面清單

登入後不應把所有角色的 URL 混在同一份 Crawl Queue。應先以每個 Scan Profile 分別建立 Route、API、GraphQL Operation、表單、檔案與 WebSocket 清單，再比較交集與差異。這樣才能知道某管理 Endpoint 是只在前端隱藏，還是真的由伺服器拒絕低權限請求。

覆蓋率分母也不能只用掃描器自己發現的網址。從 OpenAPI、GraphQL Schema、前端 Bundle、Route Manifest、瀏覽器 Network、產品功能清單與伺服器 Access Log 建立預期清單，再對照實際命中；否則掃描器沒有發現的功能會同時消失在分子與分母，看起來仍是百分之百。

授權測試的核心：正向與負向案例必須成對

只確認某帳號能打開自己的資料，是功能測試，不足以證明授權安全。每個敏感資源與動作至少要有一個 Allow Case 與多個 Deny Case：同角色的其他使用者、較低權限角色、其他租戶、停用帳號、缺少必要屬性或處於錯誤業務狀態。

OWASP 建議預設拒絕並對每一個請求驗證權限。測試時要修改 URL Path、Query、Body、Header、GraphQL Variable、批次項目、檔案 ID 與非同步 Job ID，而不是只看前端按鈕是否隱藏。拒絕結果也不能只看 403；應確認資料未改變、事件未送出、快取未洩漏且 Audit Log 合理。

水平、垂直與跨租戶越權要分開驗證

水平越權發生在權限等級相同但擁有者不同，例如會員 A 讀到會員 B 的發票；垂直越權是低權限角色取得主管或管理功能；跨租戶越權則跨過組織邊界，影響可能擴大到多個客戶。三者需要不同帳號與資料對照，不能用單一測試取代。

多租戶系統還要檢查 Tenant Context 是否從已驗證 Session 推導，而不是信任客戶端送入的 Tenant ID。測試範圍應包含資料庫查詢、快取、物件儲存、搜尋索引、匯出檔、背景工作、Webhook 與 Audit Log，因為主畫面隔離正確，不代表所有資料路徑都正確。

Session 生命週期也要掃：登入、升權、逾時、登出與撤銷

登入後掃描不應只借用 Session，還要驗證 Session 本身。登入或重新驗證後應輪替識別值；閒置與絕對逾時應由伺服器端執行；登出後舊 Cookie 或 Token 不得恢復私有內容；密碼重設、帳號停用、角色移除與高風險事件後，也要確認既有 Session 是否依政策撤銷。

若使用 SSO，要分清應用 Session、IdP Session、Access Token 與 Refresh Token。登出其中一層不一定終止其他層，測試報告應說明實際生命週期，而不是用『已登出』概括。OWASP WSTG 也建議用舊 Session 值重新存取多個敏感頁面，確認伺服器端狀態確實失效。

CSRF 與敏感操作：有 Cookie 的請求不代表使用者同意

使用 Cookie 維持登入的網站，瀏覽器可能在跨站請求中自動帶上憑證。對會改變資料、權限、付款或帳號狀態的操作，應驗證 CSRF Token、SameSite、Origin／Referer 與重新驗證等控制是否依威脅模型正確部署。掃描器也要能更新一次性 Token，否則容易把流程失敗誤認成安全。

高風險交易不能只依一般 Session 判定。變更密碼、MFA、主要信箱、付款資訊、管理員與 API Key 等操作，應確認使用者重新驗證或執行交易授權，且關鍵資料由伺服器端綁定，不能透過客戶端參數繞過。

API、GraphQL 與 SPA：不要只掃瀏覽器渲染後的畫面

現代前端只是 API Client。登入後掃描應保存實際 Request Template、認證 Header、GraphQL Operation 與變數，從 OpenAPI、Schema、瀏覽器 Network 與行動端流量補齊 UI 沒走到的端點。每個 API 測試仍要綁定正確角色與租戶，不能把所有 Token 混用。

GraphQL 需特別檢查 Resolver 與欄位層權限、Alias／Batch、Nested Query、Mutation 與 Node ID；REST 則要覆蓋 Path ID、Filter、排序、批次、匯出與非同步 Job。若只確認 Endpoint 需要登入，卻未檢查使用者是否能操作那個特定物件，仍可能漏掉 BOLA。

登入後弱點掃描的 10 階段標準流程

這套流程把安全前提放在掃描之前，把 Session 與覆蓋檢查放在執行期間，再把修復複驗與排程放在結果之後。它的目標不是讓工具盡可能多點按鈕，而是讓每個測試動作都能回答『用誰的身分、碰哪個資源、預期允許或拒絕、是否有副作用、如何證明』。

WAF Allowlist 與掃描白名單怎麼用才不會製造假安全？

固定掃描來源 IP 有助於辨識流量、套用速率與避免被一般 Bot Policy 阻斷，但不應無條件繞過所有正式安全控制。若白名單讓掃描器跳過身份驗證、授權、輸入驗證或 API Gateway Policy，測到的是不存在於正式攻擊路徑的另一套系統。

建議只調整會阻止合法測試執行的流量治理，例如明確速率、Bot Challenge 或觀測標記，並保留另一組不白名單的低風險檢查，用來驗證邊界控制真實行為。報告應列出測試來源獲得哪些例外、哪些控制仍啟用，以及這些差異對結果的影響。

可觀測性與緊急停止：掃描器也要像正式工作負載被監控

每個掃描任務應有唯一識別碼，並讓 Reverse Proxy、WAF、應用、身分系統與資料庫 Log 能關聯來源 IP、測試帳號、租戶、Request ID 與時間窗。這不只是追錯，也能確認請求真的到達預期服務、授權拒絕發生在哪一層，以及是否觸發異常通知或背景工作。

停止條件要能自動化，例如錯誤率、延遲、CPU、Queue、通知量、帳號鎖定、第三方費用或真實資料變動超過門檻。安全團隊、SOC、SRE 與系統 Owner 應有單一聯絡路徑；停止後先保存必要證據、撤銷 Session，再分析是否能安全恢復。

證據如何保留又不洩漏帳密、Token 與客戶資料？

可重現性需要保存 Request、Response、身分 Context、物件關係與預期結果，但原始證據很可能包含 Cookie、Authorization Header、個資、檔案、內部網址與租戶識別資訊。應在收集端就進行最小化與遮罩，不要等到報告完成才人工塗黑。

每筆 Finding 應保留足以證明問題的最小片段：測試帳號代碼、角色、租戶代碼、已去識別的資源 ID、Request Method／Path、必要參數、遮罩後回應、時間、Correlation ID 與資料是否真的變更。完整原始資料若確有必要，應加密、限權、設定保存期限並與一般報告分離。

報告至少要交付覆蓋、限制、風險與修復驗證

只列出弱點名稱與嚴重度，無法讓工程團隊重現登入後情境。報告要說明哪個角色與租戶、使用哪個自己的物件作為正向基線、如何替換成他人物件、伺服器實際回傳什麼，以及資料或狀態是否改變。修復建議則要落到伺服器端授權點，而不是只建議隱藏按鈕或使用不可猜的 ID。

同時應提供 Coverage Appendix：每個 Scan Profile 的登入健康、發現與命中 Route、API Operation、跳過項目、Session 中斷、阻擋原因與環境差異。這能避免管理層把未測範圍誤解為無弱點，也讓下一次排程能量化覆蓋是否退化。

修復與複驗：確認的是授權決策，不只是回應碼改變

登入後弱點修復通常涉及 Policy、Middleware、資料查詢、Tenant Filter、物件 Ownership、Token Scope 或流程狀態。複驗先確認修復版本與設定已部署，再重跑原始 Allow／Deny Case。正向案例仍須可用，負向案例要在伺服器端拒絕，且資料、快取、背景工作與 Audit Log 都符合預期。

若修復只把 200 改成 403，卻已先執行資料更新；或 UI 顯示錯誤，但 API 仍回傳敏感欄位，都不能關閉。也要測相鄰 Endpoint、批次 API、匯出、舊版本與行動端路徑，避免相同根因在另一個入口持續存在。

• 保留原始 Request Template 與角色／物件對照，精準重現
• 先跑正向案例確保功能沒有被一律拒絕
• 再跑同使用者、跨使用者、跨角色與跨租戶負向案例
• 確認資料庫、快取、Queue、Webhook 與 Audit Log 都沒有副作用
• 將根因轉成單元、整合與排程安全回歸測試

排程掃描與 CI/CD：Session 失效時要 Fail Closed

持續掃描的價值在於網站、API、權限與依賴變動後能重新驗證，但排程不代表把同一個長效帳密永久放在工具裡。建議使用 Vault 或受管 Secret 注入短效憑證，任務開始時建立 Session，結束時撤銷；Account Matrix 與 Test Data 由程式化流程重建或確認。

若登入、MFA、Session 健康或角色確認失敗，任務應標記 Coverage Failure，而不是降級成匿名掃描後仍顯示成功。CI/CD 可先跑高風險 Route、API 與歷史 Finding 的精準回歸；完整角色矩陣則依風險每日、每週或重大版本執行。

最常見的十個失敗模式

登入後掃描失敗很少只是工具不支援，更多時候是安全與業務前提沒有被工程化。以下問題應在每次任務的 Preflight 與 Postflight 自動檢查，並出現在 Coverage Dashboard，而不是等到報告零弱點時才人工追查。

30／60／90 天導入路線圖

第一階段不必一次涵蓋所有系統。先挑一個有明確 Owner、可建立測試帳號與資料、且登入後功能具有業務價值的網站，建立可重複的最低流程；接著補齊角色與租戶矩陣、API 覆蓋與安全監控；最後才擴到持續排程、CI/CD 與治理指標。

上線前最後檢查清單

以下清單適合成為每次登入後掃描的啟動 Gate。若其中任一高風險條件未知，不應用『先跑看看』取代確認；應指定 Owner、到期時間與替代控制。

• 已取得書面授權，並列明目標、第三方排除、來源、速率、時間窗與停止條件
• 每個 Scan Profile 的帳號、角色、租戶、權限與生命週期均已確認
• 至少具備同角色雙帳號、不同權限帳號；多租戶系統另有第二租戶
• 合成測試資料可識別、可回滾，通知、付款與外部整合已導向 Sandbox 或 Sink
• 登入、MFA、Token 與 Session 更新採核准流程，沒有為掃描直接關閉正式控制
• Session 健康檢查能驗證使用者、角色、租戶、內容指紋、逾時與重新登入
• Cookie、Token、API Key 與憑證由 Secret Store 注入，Log 與報告不含可重播值
• 正向與負向授權案例包含跨使用者、跨角色、跨租戶、欄位、批次與流程狀態
• 正式環境已限制刪除、付款、通知、上傳與其他不可逆操作
• SRE、SOC、IAM 與系統 Owner 能在執行期間監控並立即停止
• 報告會呈現角色化覆蓋、Session 中斷、未測項目、環境差異與證據限制
• 修復後以原始帳號／物件矩陣複驗，並將同根因案例加入持續回歸

Redmark 如何把登入後掃描變成可持續流程

Redmark 協助團隊將網站資產、掃描任務、風險證據與修復追蹤集中管理。規劃登入後檢測時，應先由團隊確認合法授權、測試帳號、角色與資料邊界，再依實際登入機制建立可重複的掃描流程；掃描結果則以風險與可執行修復方向整理，讓工程與管理團隊知道哪些問題要先處理。

工具可以降低重複設定與排程成本，但不應取代系統 Owner 對角色、租戶與業務規則的定義。最好的導入方式，是先從一個重要網站與一組低權限帳號開始，建立 Session 健康、覆蓋與複驗標準，再逐步加入更多角色、API 與持續排程。