透過封鎖 HTML 輸入、清理資料、保護 Cookie 和部署 Web 應用程式防火牆 (WAF) 來防止執行惡意指令碼和竊取使用者資訊。
閱讀本文後，您將能夠：
複製文章連結
Cross-site scripting (XSS) 是攻擊者透過一或多個 Web 指令碼將惡意程式碼插入合法網站或 Web 應用程式的策略。當使用者載入網站或執行 Web 應用程式時，這些指令碼會在使用者的瀏覽器中執行。
這些指令碼可以執行各種惡意動作，例如竊取使用者的 HTTP Cookie、工作階段權杖或其他敏感資訊。攻擊者可以利用這些資訊冒充使用者，並在未經授權的情況下存取不同平台（如社交媒體平台或銀行網站）上的帳戶。此外，這些指令碼還可以破壞網站、將使用者重新導向到惡意網站，或從 Web 應用程式中擷取機密資料。
若要進一步瞭解，請參閱什麼是 Cross-site scripting？
最主要的兩種 XSS 攻擊是反射型（非持久性）XSS 和儲存型（持久性）XSS。
當合法網站未能驗證或清理使用者輸入時，就會發生反射型 XSS 攻擊。這些攻擊通常從社交工程開始，攻擊者會傳送網路釣魚電子郵件或在線上論壇帖子中留下帶有連結的留言，誘使使用者點擊連結。通常，連結中包含附有惡意程式碼的合法網站的 URL。
當使用者點擊連結時，他們的瀏覽器會向合法網站傳送請求，該網站會將插入的程式碼反射回使用者的瀏覽器。由於該網站沒有正確清理輸入，惡意指令碼會在使用者的瀏覽器中執行。
該程式碼可以複製使用者的 Cookie 並將其傳送給攻擊者。如果攻擊者獲取了工作階段 Cookie，他們就可以控制工作階段，從而進行欺詐性購買、竊取銀行資訊或在社交媒體平台上發佈垃圾郵件等惡意行為。
這種類型的 XSS 被稱為「反射」攻擊，因為惡意指令碼會從 Web 伺服器反射並在使用者的瀏覽器中執行。它也被稱為「非持久性」攻擊，因為指令碼僅在頁面載入時在使用者的瀏覽器中執行，而不是持續執行。
儲存型 XSS 攻擊比反射型 XSS 攻擊更嚴重。儲存型 XSS 會將惡意指令碼永久儲存在目標伺服器上。
攻擊者通常透過在表單欄位（例如評論框、使用者設定檔或任何接受和儲存使用者內容的輸入欄位）中嵌入惡意指令碼來執行這種形式的 XSS。提交帖子、評論或表單後，指令碼將被插入 Web 應用程式並儲存在 Web 應用程式的資料庫中。當其他使用者載入受影響的頁面時，儲存的指令碼將在他們的瀏覽器中執行。與反射型 XSS 攻擊一樣，該指令碼可能會竊取 Cookie 或其他使用者資訊，然後將其傳送回攻擊者。
這種類型的 XSS 也被稱為「持久性」XSS，因為每次存取頁面時都會執行。這也是儲存型 XSS 攻擊特別危險的原因：它們可以影響大量使用者，且無需任何互動，只需檢視網頁即可。
個人使用者可以採取幾個步驟來降低 XSS 攻擊的風險：
由於許多 XSS 攻擊都是從網路釣魚或其他社交工程策略開始的，因此使用者應該學會如何識別可疑的電子郵件和訊息。使用者可將此類可疑郵件通知相應的 IT 或安全團隊，幫助阻止 XSS 攻擊並解決其他安全問題。
如果使用者在線上論壇中或在他們不認識或不信任的人的社交帖子中看到連結，他們應該慎重點擊。即使連結看起來合法，使用者也應該謹慎行事。許多觸發 XSS 攻擊的連結看起來是合法的，因為它們包含合法的 URL。但使用者應該檢查整個連結，包括 .com、.org、.gov 或其他尾碼後的所有內容。頁面位址後的意外文字可能是惡意程式碼。
開發人員可以透過實施一些關鍵的最佳做法，在防止 XSS 攻擊方面發揮重要作用：
開發人員可以實施規則，阻止使用者在頁面或表單中發佈資料，除非資料符合某些條件。例如，如果表單要求輸入社會安全號碼或電話號碼，開發人員可以建立一條規則，規定此輸入只能包含數字、破折號或括弧。為了更有效地防止攻擊，開發人員可以設定驗證規則，明確拒絕 XSS 攻擊中常用的標籤或字元，例如 < script > 標籤。
開發人員還可以阻止使用者在評論、帖子和表單輸入中使用 HTML。HTML 內容可以成為發佈惡意指令碼或隱藏包含惡意程式碼的 URL 連結的手段。
如果組織希望允許使用者發佈 RTF 內容（例如格式化文字或影像），他們可以整合 Markdown（一種輕量型標記語言）或在「所見即所得」(WYSIWYG) 編輯器中啟用 RTF 格式。這兩種方法都是支援 RTF 內容的更安全的方法。
開發人員可以實施一個程序，在資料發佈到 Web 伺服器之後、顯示給其他使用者之前對其進行檢查，從而幫助防止 XSS 攻擊造成的危害。例如，即使開發人員允許使用 HTML，他們也可以對所有 HTML 輸入進行清理，並在惡意程式碼在瀏覽器中執行之前將其篩選掉。
輸出編碼和「轉義」遵循類似的方法。其理念是在將任何內容寫入頁面之前，將使用者輸入中的惡意指令碼或其他程式碼轉換為普通文字。輸出編碼將程式碼轉換為不同的格式；轉義將特殊字元新增到程式碼中（如反斜線或引號）。無論哪種情況，瀏覽器都不會將產生的文字解釋為程式碼並執行它。清理會篩選掉程式碼，而輸出編碼和轉義會保留程式碼，同時使其無害。
開發人員應在整個 Web 應用程式開發過程中整合安全性。例如，他們應該進行程式碼審查，特別關注接受和顯示使用者輸入的區域。他們還應該在應用程式上線之前進行威脅建模和測試以識別漏洞。
安全團隊可以實施多種最佳做法來協助防範和快速應對 XSS 攻擊：
安全團隊可以採取幾個步驟來協助確保 Web 伺服器正確設定，以封鎖惡意指令碼並防止攻擊者竊取使用者 Cookie：
實施內容安全性原則：開發人員和安全團隊應共同為網站和 Web 應用程式定義強大的內容安全性原則 (CSP)，並在 Web 伺服器上實施這些原則。CSP 是一種額外的安全層，可以偵測和緩解某些類型的攻擊。為了防止 XSS 攻擊，它會限制可以執行的指令碼。可以設定 Web 伺服器以傳回 CSP HTTP 回應標頭，禁止瀏覽器載入有害指令碼。
安全 Cookie：安全團隊可以針對 Web 伺服器處理 Cookie 的方式設定特殊規則，以降低 Cookie 被盜的可能性。例如，他們可以將 Cookie 連結到特定 IP 位址。由於大多數使用者都擁有動態 IP 位址，因此 IP 位址與 Cookie 之間的聯繫不會持續很長時間。這樣，攻擊者就無法竊取和使用這些 Cookie。
此外，安全團隊可以完全阻止 JavaScript 存取 Cookie。一種方法是在產生 Cookie 時向其新增 HttpOnly 標誌。該標誌表示 Cookie 可能包含敏感的使用者資訊，例如工作階段權杖或驗證憑據。支援 HttpOnly 標誌的瀏覽器不會洩露該資訊。
Web 應用程式防火牆 (WAF) 可提供抵禦 XSS 攻擊的關鍵防線。WAF 充當位於 Web 應用程式前方的反向代理伺服器，透過監控和篩選應用程式與網際網路之間的 HTTP 流量來保護這些應用程式。組織可以設定 WAF 規則來檢查 URL 中是否存在惡意指令碼，並阻止將其反射給使用者。具有機器學習功能的 WAF 解決方案透過偵測繞過規則的嘗試並識別已知攻擊的變體來提供更強大的保護。
由於許多 XSS 攻擊都是從網路釣魚開始的，安全團隊應加強對網路釣魚攻擊的防禦。除了教育使用者如何識別可疑電子郵件和訊息外，安全團隊還可以實施封鎖垃圾郵件的安全功能，使用瀏覽器隔離服務來防止惡意程式碼的執行，安裝安全 Web 閘道 (SWG) 以防止使用者下載惡意檔案，以及部署電子郵件安全工具來即時偵測和封鎖網路釣魚嘗試。
安全團隊應在生產環境中測試漏洞。團隊可以執行手動滲透測試或使用自動 XSS 掃描程式。
即使採取了廣泛的防範措施，組織仍有可能遭受 XSS 攻擊。制定事件回應計畫對於快速復原至關重要。該計畫應包括監控 Web 應用程式活動和在發生可疑事件時採取動作的策略。然後，團隊應分析根本原因並確定攻擊方法。攻擊結束後，他們應該吸取經驗教訓，來增強安全性功能、更新策略並修補 Web 應用程式中的漏洞。
Cloudflare 有多種產品和功能可以協助組織和使用者防止 XSS 攻擊：
進一步了解 Cloudflare WAF。