CompTIA SY0-701: 應用程式與網站安全 — 學習指南
屬於 CompTIA Security+ SY0-701 — 學習指南. 使用經過驗證的解答練習： CompTIA 考試中心, 或參加限時模擬考試： ExamRoll.io.
現代應用程式處於商業邏輯、敏感資料和不受信任的使用者輸入的交會點。由於網站和行動裝置的前端暴露於整個網際網路，它們代表了任何企業中最大且最常被利用的攻擊面之一。要防禦它們，需要分層的控制措施，從程式碼的撰寫方式開始，延伸到執行時期的保護、完整性驗證和持續測試。
注入攻擊 (Injection Attacks)
注入攻擊仍然是典型的網站弱點。每當應用程式將不受信任的輸入串接到解譯器中——例如 SQL 查詢、殼層命令、LDAP 過濾器、XML 解析器或樣板引擎——而沒有適當地將程式碼與資料分離時，就會發生這種情況。在 SQL 注入 (SQLi) 攻擊中，攻擊者會操縱查詢，使資料庫執行由攻擊者控制的邏輯。一個典型的 PHP 易受攻擊模式如下：
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
提交 admin' OR '1'='1 會將查詢轉變為一個會回傳所有資料列的恆真式。更進階的變體包括基於 UNION 的資料擷取 (' UNION SELECT credit_card FROM payments--)、盲注的布林或時間推斷 (' AND SLEEP(5)--)，以及透過 DNS 回呼進行的頻外資料竊取。根本的修復方法是使用參數化查詢或預存陳述式，它們將查詢範本及其參數作為獨立的結構傳送給資料庫：
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
命令注入遵循相同的模式，但目標是作業系統的殼層。像 os.system("ping " + host) 這樣的程式碼允許攻擊者提交 8.8.8.8; cat /etc/passwd 並執行任意命令。修復方法要求完全避免呼叫殼層，使用接受引數陣列的 API (subprocess.run(["ping", host], shell=False))，並對任何必須傳遞給殼層的值應用嚴格的白名單驗證。
跨站腳本攻擊 (XSS) 與 CSRF
跨站腳本攻擊 (XSS) 是將惡意腳本注入到受信任應用程式所呈現的頁面中，導致受害者的瀏覽器在該網站的同源 (origin) 內執行攻擊者的程式碼。反射型 XSS 將攻擊酬載從一個易受攻擊的參數反彈回來；儲存型 XSS 將酬載持久化儲存在資料庫中，並傳遞給每個瀏覽者；DOM 型 XSS 則完全發生在客戶端的 JavaScript 中，它將不受信任的資料寫入 innerHTML、document.write 或類似的接收端 (sink)。其後果從會話劫持、鍵盤側錄到透過強制操作來完全接管帳號。
跨站請求偽造 (CSRF) 是一種不同但互補的攻擊。它濫用瀏覽器自動包含 cookie 的特性，誘騙已驗證身分的使用者提交一個非預期的請求——例如，在一個惡意網站上隱藏一個表單，該表單會向 bank.com/transfer 發出 POST 請求。防禦措施包括同步權杖 (嵌入表單中並在伺服器端驗證的每個會話的隨機值)、SameSite=Lax 或 SameSite=Strict 的 cookie 屬性，以及對敏感操作要求重新驗證身分。XSS 和 CSRF 經常被混淆，但 XSS 是在受害者的瀏覽器中執行程式碼，而 CSRF 只是讓瀏覽器發出一個請求；值得注意的是，一次成功的 XSS 攻擊可以破解大多數 CSRF 防禦措施。
安全程式碼撰寫：輸入驗證 vs. 輸出編碼
有兩種控制措施經常被混淆，但它們解決的是不同的問題。輸入驗證確保資料在應用程式對其採取行動之前，符合預期的結構——長度、類型、字元集、範圍、格式。它應該在伺服器端進行，並盡可能使用白名單 (例如 ^[A-Za-z0-9_]{3,20}$ 用於使用者名稱)。使用 JavaScript 進行的客戶端驗證僅僅是為了提升使用者體驗；它可以被任何 HTTP 代理繞過，絕不能作為安全邊界。
輸出編碼確保資料在流入任何情境時都能被安全地呈現。同一個完全合法的輸入字串，根據它最終出現的位置，可能需要不同的處理方式：HTML 主體內容需要 HTML 實體編碼 (< → <)，屬性內容需要引號屬性編碼，JavaScript 內容需要 \xHH 逸出，而 URL 則需要百分比編碼。像 O'Brien 這樣的使用者名稱是合法的輸入，但在放入 HTML 時必須編碼為 O'Brien。輸入驗證不能取代輸出編碼，而編碼也不能取代驗證——它們在資料生命週期的不同點解決不同的問題。
額外的強化措施包括內容安全策略 (CSP) 標頭以限制腳本來源、在會話 cookie 上設置 HttpOnly 和 Secure 旗標，以及在每個信任邊界使用參數化 API。
WAF 與檔案上傳保護
網站應用程式防火牆 (WAF) 會檢查 HTTP 流量，並封鎖符合已知惡意模式的請求——例如 SQLi 特徵、XSS 酬載、路徑遍歷序列、協定異常。它通常部署為反向代理 (例如使用 OWASP Core Rule Set 的 ModSecurity、AWS WAF、Cloudflare、F5)，當發現弱點但程式碼尚未修復時，能提供寶貴的虛擬補丁。然而，WAF 是一種補償性控制，不能替代安全的程式碼撰寫。高明的攻擊者經常透過編碼技巧、HTTP 參數污染和酬載碎片化來繞過 WAF。
檔案上傳值得特別關注，因為它們結合了不受信任的內容與伺服器端儲存，且通常還涉及執行。保護措施包括：透過檢查魔術位元組來驗證檔案類型，而不是信任副檔名或 Content-Type 標頭；將上傳的檔案儲存在網站根目錄之外；將檔案重新命名為伺服器產生的識別碼 (以防止透過精心製作的檔名進行目錄遍歷)；在儲存前用防毒軟體掃描；以及從一個獨立的網域提供使用者上傳的內容，以防止同源腳本執行。
實務情境：SQL 注入導致資料庫完全被攻陷
一家零售公司的產品搜尋端點接受一個 category 參數，該參數未經淨化就直接串接到 SQL 查詢中。一名安全研究員發現，提交 ' UNION SELECT table_name,null,null FROM information_schema.tables-- 會在回應中回傳所有資料庫資料表的清單。隨後的請求提取了 customers 資料表，取得了 120 萬筆記錄，包括姓名、電子郵件地址和 bcrypt 雜湊密碼。攻擊者還發現了一個預存程序，可以透過 SQL 注入來呼叫，將檔案寫入網站根目錄，從而能夠部署 webshell 並完全攻陷伺服器。這個漏洞已經存在三年，並且在先前的兩次滲透測試中被忽略，因為測試人員只測試了登入表單，而沒有測試搜尋端點。教訓是：注入測試必須涵蓋每個端點中的每個參數，而不僅僅是明顯的身份驗證路徑。
← 事件應變、鑑識與評估 · 所有領域 · 雲端、虛擬化與容器安全 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →