工具-網站應用攻擊與防禦

🎯 什麼情境該想到我

當你「開放使用者輸入或上傳任何東西給網站」的時候。

⚙️ 怎麼用（三大攻擊 × 防禦手段）

書中開宗明義：全球大約 70% 的 Web 應用攻擊都來自 XSS 攻擊和 SQL 注入攻擊，此外常用的手段還包括 CSRF、Session 劫持等。

1. XSS 攻擊（跨站點腳本 Cross Site Script）

黑客竄改網頁、注入惡意 HTML 腳本，在使用者瀏覽網頁時控制其瀏覽器做惡意操作。可用來偷 Cookie、密碼，進而偽造交易、盜竊財產、竊取情報。

兩種型態：

• 反射型：誘使使用者點一個嵌了惡意腳本的連結。新浪微博那次就是反射型——微博裡有一個含惡意腳本 URL，點了會自動關注攻擊者的 ID 並再發一篇含同樣 URL 的微博，攻擊就擴散了。
• 持久型：黑客提交含惡意腳本的請求，存進被攻擊站點的資料庫，其他使用者瀏覽時腳本被包在正常頁面裡執行。常見於論壇、部落格這類應用。

兩種防禦：

• 消毒：對某些 HTML 危險字元轉義（> 轉為 &gt、< 轉為 &lt）。關鍵細節：要文字比對後再轉義，避免把「3<5」裡的 < 誤轉；只有像 <img src= 這種上下文中的 < 才轉。消毒幾乎是所有網站最必備的 XSS 防護手段。
• HttpOnly：最早由微軟提出，瀏覽器禁止頁面 JavaScript 存取帶 HttpOnly 屬性的 Cookie。注意它不是直接對抗 XSS，而是防止 XSS 攻擊者竊取 Cookie；存放使用者認證等敏感資訊的 Cookie 應加上此屬性。

2. 注入攻擊（SQL 注入 / OS 注入）

攻擊者在 HTTP 請求中注入惡意 SQL（例如 drop table users;），伺服器用請求參數拼出 SQL 命令時，惡意 SQL 被一起拼進去並在資料庫執行。

攻擊者取得資料庫表結構的三種途徑：

1. 開源——網站用開源軟體搭建（如用 Discuz! 搭論壇），資料庫結構本來就公開。
2. 錯誤回顯——網站開著錯誤回顯，伺服器內部 500 錯誤直接顯示到瀏覽器；攻擊者故意構造非法參數，讓例外訊息輸出到瀏覽器端，方便猜表結構。
3. 盲注——網站關掉錯誤回顯，攻擊者靠頁面變化判斷 SQL 執行情況據以猜測，難度較大。

防禦： 首先要避免被猜到表名等結構資訊，此外

• 消毒：透過正則比對，過濾請求資料中可能注入的 SQL（如 drop table）。簡單粗暴但有效。
• 參數綁定：使用預編譯手段，綁定參數是最好的防 SQL 注入方法。iBatis、Hibernate 等資料存取層框架都實作了 SQL 預編譯與參數綁定，攻擊者的惡意 SQL 會被當成 SQL 的參數而非命令執行。

除了 SQL，攻擊者也會視應用注入 OS 命令、程式語言程式碼。

3. CSRF 攻擊（跨站點請求偽造 Cross Site Request Forgery）

攻擊者透過跨站請求，在使用者不知情下以其合法身分做非法操作（轉帳交易、發表評論等）。核心是利用了瀏覽器 Cookie 或伺服器 Session 策略來盜用身分。防禦主軸是「識別請求者身分」：

• 表單 Token：在頁面表單中加一個隨機數當 Token，每次回應頁面的 Token 都不同；正常頁面提交的請求會帶上，偽造的請求拿不到這個值，伺服器檢查 Token 存在且正確才放行。
• 驗證碼：更簡單有效，但書中明講輸入驗證碼是一個糟糕的使用者體驗，所以請在必要時使用，如支付交易等關鍵頁面。
• Referer check：HTTP 請求頭的 Referer 域記錄請求來源，檢查來源是否合法。很多網站用這個做圖片防盜鏈。

4. 其他攻擊和漏洞（8.1.4）

• Error Code（錯誤回顯）：許多 Web 伺服器預設打開例外訊息輸出，未處理的例外堆疊直接吐到瀏覽器，黑客可故意製造非法輸入來找漏洞。防禦很簡單——設定 Web 伺服器參數，把 500 頁面跳轉到專門的錯誤頁；常用的 MVC 框架也有這功能。
• HTML 註釋：開發人員為了除錯，在 PHP、JSP 等伺服器頁面程式中用 HTML 註釋語法寫註解，這些註釋會顯示在客戶端瀏覽器。發布前要做 code review 或自動掃描。
• 檔案上傳：若上傳的是可執行程式並藉此取得伺服器端命令執行能力，攻擊者幾乎能為所欲為，還能當跳板打叢集內其他機器。最有效的防禦是設上傳檔案白名單，只允許可靠的檔案類型；此外可修改檔名、使用專門的儲存。
• 路徑遍歷：攻擊者在 URL 中用相對路徑，遍歷系統未開放的目錄與檔案。防禦是把 JS、CSS 等資源檔部署在獨立伺服器、用獨立網域，其他檔案不用靜態 URL 存取，動態參數不包含檔案路徑資訊。

5. Web 應用防火牆：ModSecurity（8.1.5）

理想的產品要能統一攔截請求、過濾惡意參數、自動消毒、加 Token，並根據最新攻擊與漏洞情報不斷升級對策。ModSecurity 就是這樣的東西：

• 開源的 Web 應用防火牆，可嵌入 Web 應用伺服器，也可當獨立應用程式啟動。最早只是 Apache 的一個模組，現在有 Java、.NET 多個版本並支援 Nginx。
• 架構重點：處理邏輯與攻擊規則集合分離。處理邏輯（執行引擎）負責請求／回應的攔截過濾、規則載入執行；攻擊規則集合負責描述具體攻擊的規則定義、模式識別、防禦策略（可用文字方式描述）。處理邏輯比較穩定，規則集合則需針對漏洞不斷升級——這是一種可擴展的架構設計。
• 商業產品也有實作此功能者，如 NEC 的 SiteShell。

6. 網站安全漏洞掃描（8.1.6）

和電腦安全漏洞掃描一樣，網站也需要。掃描工具根據內建規則構造具有攻擊性的 URL 請求，模擬黑客攻擊行為，用以發現漏洞。許多大型網站的安全團隊都有自己開發的掃描工具，不定期掃描伺服器查漏補缺；市場上也有商用的掃描平台。

🧪 我實際套用的紀錄

• （待填）

⚠️ 注意 / 什麼時候不適用

• 沒有「百毒不侵、固若金湯」的網站。書中反問「有沒有百毒不侵、固若金湯的網站呢？」，而 XSS 這種「古老」手段歷久彌新、不斷變化出新花樣，許多以前認為不可能用來攻擊的漏洞也逐漸被利用——防禦是持續升級的過程，不是一次性的驗收項目。
• 這也是 ModSecurity 把規則集合獨立出來的理由：新型漏洞不斷被報告，只有規則能持續升級的架構才跟得上。
• 驗證碼雖有效但傷體驗，別無差別地套在所有表單上。

🔗 相關工具

• 工具-資安與合規左移 —— 把這些攻擊面在設計與開發階段就處理掉，而不是等上線後靠掃描補
• 工具-防禦式編程 —— 消毒、白名單、參數綁定的上位心法：不信任任何外部輸入
• 工具-用例外處理錯誤 —— 對應 Error Code 漏洞，例外不該原封不動吐給使用者
• 工具-透明多級分流 —— WAF 就掛在流量入口那一層，和負載均衡同屬請求進來的第一道
• 工具-網站高可用與伸縮性設計 —— 同書的另一面，安全與可用性都是架構的非功能需求
• 工具-LLM安全防護 —— 同樣的注入思維在 LLM 時代的變形
• 大型網站技術架構 —— 來源書