網站保安檢查指南：香港中小企如何找出風險與排定修補

網站保安檢查：先辨認警號，再決定誰要立即處理

假設一間新蒲崗貿易公司在星期日收到後台登入通知，老闆記得同事今天沒有上班，卻不知道通知是否真確。網站保安檢查應從這個具體疑問開始：通知來自哪個系統、涉及甚麼帳戶、是否真的登入成功、登入後有沒有改動。不要順著通知內的陌生連結輸入密碼，應由平日保存的官方入口進入管理介面，並經既有聯絡方法向負責人核實。

這是一個假設情境，並非 Black Media 客戶個案。它反映小公司的常見難處：大家知道網站需要保安，卻未必知道第一張檢查表應寫甚麼。若只問網站「安不安全」，答案很容易變成一串工具名稱；改問「哪些操作可能影響接單、客戶資料和網站控制權」，才較容易把檢查變成有負責人、有證據、有處理期限的工作。

先把工作分成日常盤點與事件處理。前者是定期確認帳戶、版本、設定及紀錄；後者是已出現不明管理員、異常資料匯出或收款資料被改等跡象時，安排技術人員控制影響並保存證據。日常清單不能代替事件調查，掃描工具顯示沒有問題，也不等於已查清可疑登入。兩類工作可以共用紀錄，但不能用同一個完成標準。

老闆不必親自測試程式漏洞，卻應指定一位內部協調人。協調人負責核實誰有權批准停用功能、誰能聯絡寄存商、誰可以確認客戶交易狀態。若每個問題都等老闆翻找舊電郵，技術人員即使知道怎樣修正，也可能因缺少授權或必要資料而停住。把聯絡次序寫下來，是正式檢查之前最實際的準備。

第一張表：盤點會影響網站的入口與資產

由公開網址追到背後的控制帳戶

盤點可先由現有帳單、服務通知及內部交接文件取得線索，再由授權人員核實。若帳單上的服務名稱與實際入口不同，應補上對照，避免把同一服務誤當成兩套系統。公司亦可為每項資產寫一個短編號，令故障紀錄、更新工作與帳戶清單能互相指認，毋須在多人溝通時反覆猜測「那個後台」是哪一個。

盤點範圍不應只有首頁和後台。域名註冊商、DNS 管理、寄存控制台、程式部署、資料庫、寄件服務及付款設定，都可能影響網站。記錄每個入口的用途、持有人、管理者及復原聯絡方法，毋須把密碼直接放在同一份表內。密碼應在獲批准的管理工具中保存，清單只記錄誰有權取得及甚麼情況可以使用。

同一家公司可能有正式網站、舊版網站、測試站和活動子域名。正式站更新了，舊站卻仍可登入，保安缺口便可能留在被遺忘的位置。請技術人員確認各入口是否仍需要公開，不再使用的服務應按資料保存需要妥善退役；只把導航連結移除，並不代表外界無法到達原本的網址。

把寄存責任與網站責任分開記錄

寄存商能處理的事項，要看實際服務範圍。主機作業系統、網站程式及第三方服務可能由不同人維護。可先用寄存規格與支援責任的比較方法整理現有安排，再把未有人接手的項目標示出來。例如主機有人更新，不代表自建內容管理系統的登入程式也有人持續檢查。

清單應容許寫「未確認」。這比憑印象填「供應商負責」更有用，因為未確認的項目可以直接成為追問事項。完成盤點後，先找出沒有現任負責人、無法登入或復原方式失效的入口。這些問題未必已造成入侵，但會削弱公司處理事故及日常維護的能力，應列入近期工作。

第二張表：按暴露程度與業務影響排序

不是所有發現都需要立即停站。判斷優先次序時，可同時看四件事：問題是否已被利用、外界能否直接接觸、涉及甚麼資料或操作，以及目前有沒有有效限制。工具給出的嚴重程度是參考，還要配合網站實際用途。不能只因某項容易修正便排第一，也不能因畫面暫時正常便把資料外洩跡象放到下月再看。

表內只是分流例子，並不是通用事故等級。假設一個過期測試帳戶只能看公開內容，與同一帳戶能匯出全部訂單，影響便不同。紀錄應寫明判斷依據，方便另一位同事接手時明白原因。不要只留下紅黃綠顏色，更不要將未能驗證的推測寫成已確認被入侵。

排序時可加入「影響是否正在擴大」這個問題。假設只發現一個陌生登入，尚未確認操作，應保留不確定狀態並立即核實；若已看到未批准的資料匯出，便不能仍按普通帳戶清理處理。分級應隨新證據更新，原本列為低影響的問題一旦涉及更多入口或資料，負責人需要重新安排處理，而不是受最初標籤限制。

若問題暫時不能修好，必須記錄臨時措施及有效期。例如某個上傳功能需要改寫，可先經批准限制使用者或暫停入口，同時安排替代交收方法。臨時限制應經測試，並有重新評估日期；把問題留在待辦表而沒有期限，容易令「暫時」變成長期依賴。

帳戶檢查：讓每一次管理操作找得到負責人

共用管理員帳戶要先釐清用途

幾位同事共用最高權限帳戶，會令離職處理和紀錄追查變得困難。較清楚的安排是日常各用具名帳戶，按職務分配權限，只有必要管理工作才使用較高權限。檢查時逐一問：這個人目前仍需要登入嗎？需要改哪些內容？是否真的需要新增管理員、修改付款設定或下載整批資料？

核對帳戶不只是數人頭。曾經借給外判人員的臨時帳戶、無人記得用途的測試帳戶，以及用來自動接駁的服務帳戶，也要找到現任負責人。服務帳戶未必能像員工帳戶般停用，應先查清依賴，避免中斷正常訂單同步。確認無用才移除；仍有用途的便縮窄權限並記錄憑證保管方法。

檢查登入、復原與撤銷是否連成一套

高權限入口應評估多重驗證、登入嘗試限制及可疑活動通知。OWASP 的身份驗證指引提供相關設計參考，但實際啟用前仍需確認系統支援及復原流程。啟用驗證後，要知道手機遺失時如何核實本人，避免所有管理權只繫在一部私人裝置。

當帳戶疑似被冒用，單改密碼未必會撤銷既有登入狀態或外部授權。應由技術人員確認哪些工作階段、金鑰及復原設定需要重新處理，再核對異常期間的操作。日常檢查可用指定測試帳戶驗證停用效果，確認被停用者不能繼續提交管理操作，而非只看到帳戶列表多了一個「停用」標籤。

網站的密碼復原電郵也應納入範圍。如果復原地址仍屬已離職同事，公司可能無法安全接回控制權。電郵權限混亂的團隊，可參考公司電郵帳戶與人員安排建立名單，再核對網站、域名及寄存入口的聯絡地址是否由現任授權人員管理。這項工作應與人事變動同步。

權限檢查：看到按鈕與有權執行，是兩回事

從角色與資料範圍建立測試格

把刪除按鈕隱藏，只是介面安排；真正的權限限制需要在伺服器處理請求時執行。OWASP 的授權檢查建議強調按需要給予最少權限，並檢查每次請求。商戶可以請開發者用獲授權測試帳戶示範，確認不同角色不能越過應有的資料範圍。

例如內容編輯可修改文章，卻不應因此取得客戶名單；出貨同事需要收件資料，未必需要改收款設定。測試格可沿「角色、資料、動作」三個方向建立，不只檢查是否能登入。同一角色也可能只可處理自己部門的資料，這些邊界應由業務負責人先說清楚，再交技術人員驗證。

請在受控環境使用虛構客戶及訂單，不要拿真實陌生人的資料試探。驗證報告應記錄測試角色、操作、預期結果及實際結果，而非保存大量敏感資料截圖。對一般老闆而言，最有用的交付物是哪些權限已符合需要、哪些仍未處理，以及限制是否影響同事完成日常工作。

高影響操作需要額外確認

大量匯出、批次刪除、改收款帳戶和新增管理員，應與一般文字修改分開看待。可以評估再次驗證、清楚確認畫面或額外批准流程，但不應只為形式而增加步驟。先描述錯誤操作的後果，再選擇合理控制。若確認畫面沒有列出將影響的範圍，同事依然可能在不知情下批准大批改動。

新增網上商店管理功能時，最好同時寫好角色分工。若等到接單後才發現客服與財務共用所有權限，調整會涉及培訓、操作習慣和現有資料。設計階段把職務需要說明白，比上線後逐個補鎖更容易驗證，也能減少公司對單一最高權限帳戶的依賴。

程式與設定：把版本清單變成可執行的更新工作

先知道網站用了哪些元件

自建 CMS 同樣需要盤點維護範圍，包括 PHP、資料庫、使用的程式套件及接駁服務。版本數字本身不能完整代表安全程度，要核對官方支援情況、相關公告，以及網站是否使用受影響功能。由維護者保存元件清單及更新紀錄，避免每次檢查都要重新猜測程式來自哪裏。

對老闆而言，應追問的是「誰判斷這次更新是否適用」「如何測試」「失敗時如何回復」，而不是自行把所有版本升到最新。更新可能影響登入、表格、排程和資料庫查詢，應在合適環境驗證主要操作。缺少測試條件的舊網站，要把建立條件列為工作，不能無限期以怕出問題為由擱置維護。

修補要同時查設定與資料處理

程式檢查可包括資料庫查詢是否使用參數化方式、輸出是否按所處位置作適當編碼，以及正式環境有沒有把詳細錯誤資料公開顯示。這些問題應由開發者審查與測試。OWASP 的 SQL 注入防護資料可作查詢處理的參考；單純刪除某些符號不能取代正確查詢設計。

設定檔、備份檔與暫存匯出檔也要確認儲存位置及存取限制。檔名很難猜，不等於已有權限保護。技術人員應核對哪些目錄可供公開下載，哪些資料只容許經授權流程取得。網站改版時曾留下的測試檔案，尤其容易被當成沒有影響而一直保存。

檢查報告也要區分工具推測與人工確認。某工具可能根據回應中的版本字樣提示風險，但實際部署狀態仍需維護者核對。請對方保留判斷依據、適用條件及未能確認的部分，避免將整份工具輸出原樣交給商戶便算完成。對需要深入驗證的項目，另定授權範圍及合適環境，避免檢查本身干擾正常交易。

若目前網站程式與後台設計缺少維護文件，可先從仍在使用的關鍵操作補起，例如登入、查詢提交、資料匯出及設定修改。每次修正順便留下涉及檔案、設定變更及覆核方法，逐步建立能被下一位維護者理解的紀錄，避免所有知識只存在某人的記憶中。

表格與檔案：檢查資料進站後會去甚麼地方

網站表格不只收文字，亦可能接收附件、圖片或匯入資料。檢查時要知道每個欄位的用途、接收後的處理、可讀取的人，以及不再需要時如何處理。沒有業務用途的資料不應因為「將來可能有用」而長期收集。欄位越多，後續保管、存取及刪除責任也越多。

上傳功能要限制允許類型及大小，並由伺服器作檢查，不能只依賴瀏覽器提示。檔案名稱、儲存方式與可否直接執行也需要處理。OWASP 的檔案上傳指引列出多層防護方向；具體組合應按資料用途安排，不能把任何單一檢查視為完整保證。

假設貿易公司讓客人提交詢價附件，內部要先決定誰可下載、附件是否會自動轉寄，以及外判維護者能否看見。若只是將附件複製到多人共用的公開目錄，即使表格頁使用加密連線，也沒有解決下載權限問題。檢查結果應追蹤到最終儲存及使用位置，而不止確認「成功提交」。

下載連結也應納入資料流檢查。假設客服將詢價附件寄給同事，應確認使用的是受權限保護的連結，還是任何取得網址的人都能讀取。若連結有有效期，要測試到期後的結果及合理的重新取得方法。商戶需要的是清楚的資料交收安排，而不是只在檔案名稱加上「機密」便當作已限制存取。

測試站的資料更應審慎處理。直接把正式客戶資料複製過去，可能令原本受控的資料出現在較寬鬆的環境。可優先使用虛構資料或經適當處理的測試資料，並限制測試站存取。測試人員需要的是足以重現功能的欄位與情境，通常不是整份真實客戶歷史。

連線與邊界：有加密仍要檢查後端控制

HTTPS 用來保護傳輸連線，並不能證明網站沒有程式漏洞或管理員帳戶沒有被冒用。檢查應包括憑證是否適用、續期是否有人跟進，以及登入後頁面是否持續使用加密連線。不要因瀏覽器顯示正常便跳過帳戶、資料權限及更新工作，各項控制處理的是不同問題。

防火牆、登入來源限制或流量防護可以降低部分風險，但要記錄由誰管理及如何處理誤擋。某項限制若令外勤同事無法工作，大家可能私下尋找繞過方法。較好的做法是先定義合理使用情境，再測試限制及例外申請方式，讓保安安排能真正維持下去。

使用代理或內容分發服務時，也要確認原始伺服器的存取安排。不能單看前面的管理面板就推斷後端已受同樣保護。這類設定宜交由負責伺服器與寄存環境的人員核對，報告則應寫成商戶看得懂的結果，例如哪些入口受限制、誰能修改規則，以及發生誤擋時找誰處理。

日誌與通知：有紀錄，才有機會查清發生甚麼事

先決定要回答哪些問題

日誌應能協助回答誰在何時嘗試甚麼操作、是否成功，以及涉及哪類對象。網站程式、伺服器和外部服務可能各有紀錄，時間與識別資料需要能互相對照。不能只保存畫面截圖而忽略背後時間，也不能假設所有系統都採用同一時區。檢查時可選一次正常測試操作，確認能否沿紀錄找回相關事件。

記錄越多並非必然越好。密碼、完整驗證憑證及不必要的敏感內容不應直接寫入日誌；存取及保存期限亦要按需要管理。OWASP 的日誌指引有助釐清應記錄事件及需避免保存的資料。商戶應知道誰能查閱紀錄，而不是把整份紀錄任意轉寄。

通知一定要連到接手的人

紀錄抽查可以用一個低影響測試事件進行，例如由指定帳戶修改一段測試內容，再核對紀錄內的帳戶、時間及對象。若看不出究竟改過哪類資料，便知道紀錄仍有缺口；若出現不必要的完整客戶內容，也需要調整。測試完成後保存結果摘要，不必為了證明有做檢查而複製整份日誌到更多地方。

可疑活動通知若只寄去無人查看的郵箱，不能形成有效跟進。為不同通知指定接收者、後備接收者和升級方法，並區分需要立即核實的訊號與一般維護提醒。一次安全的測試通知，可以驗證信件是否到達及同事是否知道下一步。這比只在設定頁看見「已啟用」更有說服力。

若收到大量重複警報，要先了解原因，再調整通知條件。直接關閉所有通知，會失去後續觀察能力；完全不處理雜訊，則容易令同事忽略真正異常。每次調整應留下原本條件、修改理由和覆核日期，確認減少無用通知之餘，仍保留對高影響事件的可見度。

修正之後：用證據關閉問題，而不是只寫已處理

一項問題可以經歷已發現、待核實、已確認、處理中、待覆核及已完成等狀態。重點是每次轉變都有依據。供應商說已更新，可要求列出涉及元件與驗證結果；同事說已停用帳戶，便用合適測試確認權限已撤銷。完成紀錄應足以讓未參與原本討論的人明白做過甚麼。

若發現實際事故跡象，先經已核實渠道聯絡負責人，由有能力的人安排控制影響、證據保存及調查。不要自行刪除所有可疑紀錄，亦不要急於把整站覆蓋還原，因為這可能破壞調查線索。業務端要配合確認可疑訂單、設定改動及受影響服務，技術處理與對外溝通則應有清楚分工。

• 每次人員、供應商或功能變動後，重新核對相關帳戶及權限。
• 每次重要更新後，保留主要操作的驗證結果及已知限制。
• 定期抽查紀錄與通知是否仍可使用，並確認負責人未有變更。

對外判維護者的臨時存取，也可設一個收尾動作。工作完成後由公司核對哪些帳戶仍需保留、哪些權限可以收回，以及有沒有新加入的接駁憑證。若每次工作只新增存取而沒有收尾，管理範圍會隨年月累積。收回前先確認不會中斷必要服務，完成後再把授權記錄更新，讓下一輪盤點有可靠起點。

持續檢查的價值，在於讓風險有去向。老闆可定期看未完成事項、逾期原因及臨時限制，不必要求每次都收到難以閱讀的技術長報告。若某問題因系統老舊而反覆出現，便應討論修整架構或更換元件的可行性，而非只重複處理表面症狀。

1. 先列出網站入口、管理帳戶及現任負責人。
2. 把有實際異常跡象的事項交由技術人員優先核實。
3. 為其餘問題寫好處理次序、完成條件及覆核日期。

第一次檢查毋須把所有問題同日解決，但應完成一份可信的基線：有哪些入口、哪些帳戶仍在用、哪些風險已確認，以及哪些事項還未知。下一次便可針對變化比較，例如新增功能是否帶來新資料出口、離職後是否遺留權限。這種前後可對照的紀錄，比每次從零開始勾選同一張表更能支持管理。

如果公司未有成形的檢查紀錄，可帶着現有入口清單及最擔心的操作，與 Black Media 討論網站及寄存的檢查需要。先釐清目前誰負責哪一層，再按風險安排可執行的技術工作，會比單問要加哪個保安功能更容易落實。