什麼是跨網站指令碼（XSS）？

在目前影響 Web 應用程式的安全威脅中，跨網站指令碼攻擊一直是最持續且最普遍的威脅。此外，對企業而言，它仍然是持續性的挑戰，因為攻擊者經常利用 XSS 漏洞將惡意指令碼注入受信任的網站。跨網站指令碼攻擊的後果可能非常嚴重，包括資料外洩、未經授權的存取，甚至危及使用者隱私。此類安全事件可能對組織造成災難性的影響，導致客戶信心流失、營收損失，以及可能的訴訟。

在這篇部落格中，我們將說明什麼是跨網站指令碼（XSS），討論各種跨網站指令碼類型、它們如何發生，以及最重要的是，企業如何保護其網站免受這些威脅。本文還將進一步介紹一些跨網站指令碼攻擊向量的範例，並提出可採取行動的最佳實務，以降低這些風險。

什麼是跨網站指令碼（XSS）？

跨網站指令碼，也稱為 XSS，是一種安全性弱點，允許攻擊者將惡意指令碼注入到用戶端檢視的網頁中。近期安全報告指出，超過 55% 的所有 XSS 弱點與 IT 公司使用的應用程式有關，其次是公共部門，占 39%。這使其成為企業當前面臨的最常見高風險問題之一。XSS 弱點通常源於未適當驗證輸入，讓攻擊者能夠在使用者的瀏覽器中執行指令碼，從而繞過存取控制。

這些漏洞幾乎可能影響任何 Web 應用程式，從電子商務網站到社群網路網站皆然。因此，修補這些漏洞已成為任何企業組織的當務之急。

XSS 可被用於什麼？

自從首次發現跨網站指令碼以來，各種繞過篩選器與 防火牆 的方法使 XSS 攻擊日益複雜。因此，安全團隊必須主動落實安全實務。透過 XSS 發動的攻擊不僅僅造成單一類型的損害，而是可服務於各種惡意目的，對企業與使用者都可能帶來毀滅性的後果。

其中一些包括：

1. 工作階段劫持：XSS 最具破壞性的用途之一是工作階段劫持。在這類攻擊中，惡意指令碼會竊取使用者的工作階段 Cookie，使攻擊者得以冒充該使用者。一旦攻擊者存取使用者帳戶，便可代表合法使用者執行金融交易、修改使用者設定，或進行其他惡意活動。
2. 身分竊取： XSS 的另一種危險可能性是身分竊取。這可透過注入指令碼來擷取敏感的使用者資訊，例如登入憑證或其他個人資料，攻擊者藉此蒐集使用者名稱與密碼。之後，這些資訊可能會在暗網上販售，或用於更具針對性的攻擊，例如網路釣魚或帳戶接管。
3. 網站竄改：攻擊者會利用 XSS 變更網頁的內容與外觀來進行網站竄改，可能注入猥褻圖片與文字，甚至將使用者導向另一個惡意網站。這類攻擊可能損害企業聲譽，進而降低使用者對網站可信度的信任。
4. 網路釣魚攻擊：XSS 的另一種非常常見應用是 網路釣魚。所注入的指令碼可讓攻擊者建立假的登入表單或擷取敏感資訊。他們甚至還能將使用者轉送到釣魚頁面，該頁面在各方面看似有效，但唯一目的就是竊取資訊。在這種情況下，透過劫持網站介面，攻擊者能夠誘騙使用者輸入其個人資訊，讓其誤以為自己正在與合法網站互動。
5. 利用瀏覽器漏洞： 有時，XSS 攻擊會被用來 利用 特定的瀏覽器漏洞。透過注入特定指令碼，攻擊者可能利用受害者瀏覽器或外掛程式中的安全弱點，進而引發更嚴重的攻擊，例如安裝惡意軟體或取得對使用者裝置的存取權。

跨網站指令碼對 Web 安全的影響

如果網站感染了跨網站指令碼病毒，其安全性可能會受到多種破壞性影響。這些影響不僅僅是立即的財務與營運挑戰，更會對企業造成嚴重的長期問題。以下是跨網站指令碼對 Web 安全的一些主要影響：

1. 資料外洩：XSS 攻擊最常見但也最嚴重的後果之一，來自於 資料外洩事件。當攻擊者成功執行 XSS 攻擊時，他們便可能竊取敏感的使用者資料，例如 PII、信用卡號碼與登入憑證。這類外洩會對公司與客戶雙方造成巨大的財務損失，更不用說還會損害使用者信任。
2. 法律後果： 如果 XSS 攻擊嚴重到導致資料外洩或未經授權的存取，也可能帶來法律後果。根據 General Data Protection Regulation 及其他法規，企業必須確保使用者資料受到適當保護，並在發生任何外洩時於特定時限內通知相關方。不遵循規定可能導致高額罰款，並嚴重損害公司形象。
3. 服務停機：XSS 攻擊的另一個結果是服務停機。例如，若發生攻擊，企業往往必須讓網站或應用程式下線，以調查事件並修補漏洞。對於高度依賴線上營運的公司，例如電子商務與訂閱制服務，這可能導致營收損失。
4. 聲譽損害： 企業最重要的資產之一就是其聲譽，而跨網站指令碼攻擊顯然會削弱這一點。如果發生資料外洩，或客戶看到網站上出現某種遭入侵的跡象，他們可能會開始不信任該品牌。隨著安全與隱私成為每位消費者日益關注的議題，一旦發生這類損害，可能需要很長時間才能重建失去的信譽。
5. 營運中斷：XSS 攻擊有可能造成營運上的阻礙，尤其是在攻擊已危及關鍵系統或平台時。員工可能會發現自己被阻擋在執行工作所需的內部系統之外。在這種情況下，必須重新調度資源來修補該安全漏洞，這會拖慢生產力並影響日常業務運作。

跨網站指令碼攻擊的類型

跨網站指令碼有數種類型，每種類型的執行方式與潛在影響皆不同。這些攻擊使攻擊者能透過 Web 應用程式漏洞注入惡意指令碼、危害使用者的私人資料、劫持工作階段，或變更網站內容。因此，了解這些 XSS 形式對於保護您的應用程式並降低安全風險至關重要。

1. 儲存型 XSS（持久型 XSS）： 儲存型 XSS 是最危險的跨網站指令碼攻擊類型之一，因為它實際上會駐留在受影響的伺服器上。攻擊者注入惡意指令碼，並將其儲存到資料庫或伺服器端儲存體中。每當使用者造訪遭入侵的頁面時，該指令碼就會在其瀏覽器中執行。在這類攻擊中，所有造訪該頁面的使用者都可能受到影響，這使其對擁有大量使用者資料庫的網站特別危險。
2. 反射型 XSS： 當惡意指令碼從 Web 伺服器反射回來時，就會發生這種情況，通常是透過電子郵件或 URL 傳遞。攻擊者會精心製作一個包含該指令碼的特殊 URL，而當受害者存取該 URL 時，指令碼便會在其瀏覽器中執行。不同於儲存型 XSS 並非一次性攻擊，一旦攻擊者使用反射型 XSS，便無法再濫用該漏洞，儘管它仍可能造成嚴重後果，例如工作階段劫持或網路釣魚。
3. DOM 型 XSS： DOM 型 XSS 攻擊完全發生在用戶端，沒有任何惡意指令碼經過伺服器處理。此攻擊會操控網頁的文件物件模型，使惡意指令碼在使用者的瀏覽器上執行。這使得 DOM 型 XSS 攻擊更難以偵測或防範，因為它利用的是用戶端 JavaScript，而不是依賴伺服器端漏洞的攻擊。
4. Self-XSS： 在 Self-XSS 中，使用者會透過社交工程（操控）被誘導在自己的瀏覽器中執行惡意指令碼。攻擊者可能藉由虛假的權威說法，欺騙使用者將惡意程式碼複製並貼上到瀏覽器開發人員主控台中。雖然這類 XSS 依賴使用者操作，但仍然有害，因為使用者可能不了解其中的風險程度。
5. 變異型 XSS-mXSS： 當輸入清理程序為了阻擋注入的程式碼而對其進行轉換時，可能會將該程式碼變形成可繞過傳統防禦的攻擊模式，這種情況就會發生。這種形式的 XSS 特別危險，因為它能避開為阻止指令碼執行而設置的傳統過濾與編碼機制。

跨網站指令碼如何運作？

要完整了解跨網站指令碼（XSS）如何運作，必須探討攻擊的各個階段，從識別弱點到執行惡意酬載。了解這些階段有助於深入掌握攻擊者如何繞過安全措施並危害敏感資料。

1. 識別弱點： 透過跨網站指令碼（XSS）利用 Web 應用程式的第一步，是找出未能對使用者提供的資料進行清理或驗證的輸入欄位或參數。這最常發生在搜尋列、表單欄位和 URL 參數中，當特殊字元如 <, >, 或引號 (‘, “) 未被正確檢查時。如果未加以檢查，這些情況可能會因將惡意程式碼（如 JavaScript）注入應用程式的 HTML 而觸發攻擊。因此，這將允許有害指令碼在使用者的瀏覽器中執行，並具備進行資料竊取或工作階段劫持的能力。
2. 指令碼注入： 一旦發現漏洞，攻擊者就會建立惡意酬載，通常是利用易受攻擊輸入的 JavaScript 程式碼。這段程式碼會被注入表單欄位、搜尋查詢或 Web 應用程式未正確淨化的 URL 參數中。舉例來說，可能會將類似 <script>alert(‘XSS’)</script> 的內容插入文字欄位或 URL 中。如果網站未對此輸入進行淨化，這段指令碼就會被納入頁面的 HTML 中，並在使用者載入頁面時執行。
3. 惡意酬載的執行：這個惡意指令碼會在使用者造訪遭入侵的網頁時執行。由於瀏覽器信任該網站的網域，因此它會像執行頁面內容的其他部分一樣執行該指令碼。在此階段，攻擊者可以進行多種活動，例如竊取 Cookie、將使用者重新導向至網路釣魚頁面，或竄改網站內容。重要的是，這也表示使用者可能完全不知道瀏覽器正在執行惡意程式碼，因為這一切都在幕後發生，實際上不會出現任何可見跡象。
4. 濫用瀏覽器信任： XSS 是一種濫用瀏覽器對網站隱含信任的攻擊。由於瀏覽器相信來自受信任網站的內容是安全的，因此會自動執行來自該網域的任何指令碼。在這方面，攻擊者會利用這種信任，在使用者不知情的情況下執行其程式碼。透過 XSS 取得對網頁內容的控制後，攻擊者可以劫持使用者工作階段、竊取敏感資料，或執行其他惡意指令碼。
5. 使用者影響與資料竊取： XSS 攻擊會讓攻擊者取得敏感資料，例如外洩的工作階段權杖、Cookie，甚至是儲存在本機儲存空間中的認證資訊。例如，攻擊者若存取電子商務平台或社群媒體網站，便可竊取用於識別使用者的工作階段 Cookie，並劫持其帳戶。考量到不同類型的應用程式會處理敏感的財務或個人資料，這是相當危險的。
6. 進一步操控： 在更複雜的攻擊中，XSS 可能是多步驟攻擊的第一階段。攻擊者可以注入其他指令碼來下載惡意軟體，或將使用者重新導向至其他易受攻擊的系統。攻擊者可能會將多個弱點串連起來，從透過 XSS 取得用戶端控制，進一步發展為伺服器端利用，從而升級攻擊並觸及更關鍵的系統。

如何防止跨網站指令碼攻擊

預防 XSS 攻擊可能需要從強健的編碼實務到安全政策或主動式偵測機制等多方面著手。因此，以下提供幾項有助於降低 XSS 弱點風險的策略。

1. 輸入驗證： 輸入驗證是防止 XSS 攻擊的最佳實務之一。它包括驗證使用者輸入，以確保資料符合已知或允許的格式。例如，接受電子郵件地址輸入的表單欄位應僅允許一般電子郵件格式中允許的字元。這類技術有助於降低任意程式碼被注入表單欄位、搜尋框或 URL 參數並遭到執行的風險。
2. 輸出編碼： 在網頁中納入使用者提供的資料時，輸出編碼可能非常關鍵。Web 應用程式應將特殊字元，例如 <, >, 和 & 替換為其 HTML 編碼對應值（<, >, and &)，以避免瀏覽器將特殊字元解讀為可執行程式碼。這可讓 Web 應用程式將使用者輸入顯示為文字，而不會作為指令碼執行。
3. 內容安全政策 – CSP： 內容安全政策（Content Security Policy），簡稱 CSP，是一種安全標準，透過僅允許來自指定白名單的資源執行指令碼，協助避免網頁中的 XSS。具體而言，在 CSP 的實作中，會設定一個特定的標頭，開發人員可在其中指定哪些網域允許提供可執行程式碼。藉由這麼做，它可阻止攻擊者從未經授權的來源注入並執行惡意指令碼。就防止 XSS 攻擊而言，實作良好的 CSP 被視為最佳實務。
4. 輸入清理： 所有使用者輸入都必須經過清理，也就是在處理之前移除或中和先前具有風險的字元。這可以藉助清理程式庫或所使用程式語言中的某些內建函式來完成。在 PHP 中，像 htmlspecialchars() 這樣的函式可用於清理輸入欄位，以確保在儲存或顯示資料之前移除有害指令碼。
5. 避免內嵌 JavaScript： 在可能的情況下，應避免使用內嵌 JavaScript，也就是直接寫入 HTML 元素中的指令碼。內嵌指令碼非常容易受到 XSS 攻擊，因為這通常是攻擊者注入此類指令碼的方式。作為替代方案，應使用標籤參照外部指令碼，並透過 JavaScript 檔案附加事件處理常式，以便將 HTML 與指令碼層分離。這可讓程式碼管理更容易且更安全。
6. 開發人員教育： 防止 XSS 弱點的最佳方式，在於開發人員是否能堅持遵循安全編碼實務。開發人員需要接受最佳實務訓練，主要涵蓋輸入驗證、輸出編碼，以及正確使用程式庫，以防止 XSS。定期訓練計畫與安全稽核也有助於找出潛在弱點，並在遭到利用之前加以修補。

偵測與緩解 XSS 弱點

及早偵測 XSS 弱點可大幅降低攻擊成功的機率。各種工具與方法可協助開發人員、安全團隊或企業偵測並緩解 XSS 弱點。其中一些包括：

1. 自動化安全掃描器： XSS 弱點掃描器可能成為企業識別並回應 XSS 弱點的最佳可用替代方案之一。這些自動化安全掃描器會爬取 Web 應用程式、執行攻擊情境模擬，並嘗試識別系統中的薄弱點。自動化掃描器可提供最廣泛的涵蓋範圍，並指出手動測試時可能遺漏的 XSS 弱點。
2. 滲透測試： 滲透測試是一種手動測試活動，安全專業人員扮演攻擊者的角色，執行真實世界的攻擊以揭露應用程式漏洞。滲透測試人員會使用攻擊者可能採用的技術，而在 XSS 的情況下，這表示嘗試將指令碼注入任何看起來可能存在漏洞的輸入欄位。定期進行滲透測試可確保在攻擊者利用這些可能的攻擊向量之前，先識別並修補它們。
3. 程式碼審查： 定期程式碼審查對於識別 XSS 弱點是絕對必要的。這構成了一種程式碼審查流程，開發人員或安全人員會檢視原始碼中處理使用者輸入與主動呈現輸出的部分。應特別注意涉及輸入驗證與輸入編碼的流程，因為這些是目前最常見的 XSS 弱點來源。
4. WAF 或 Web Application Firewall： WAF 透過過濾與監控 HTTP 請求，為 XSS 攻擊增加額外的一層防禦。WAF 可偵測並封鎖意圖利用跨網站指令碼問題的惡意流量，並可作為缺乏深入安全措施之應用程式的安全防護網。WAF 與其他 XSS 預防機制搭配運作時效果非常好。
5. 監控與記錄： 需要全面的記錄與監控，才能識別跨網站指令碼攻擊的嘗試。安全團隊能否有效識別並回應，關鍵在於記錄所有使用者輸入，同時密切監控這些輸入是否有可疑活動。例如，某個特定輸入欄位出現異常尖峰，可能顯示正在發生 XSS 攻擊。

防範 XSS 的最佳實務

降低 Web 應用程式中 XSS 攻擊後果的關鍵，在於遵循最佳實務。企業與開發人員可輕鬆考慮採取的一些有效策略包括以下幾項：

1. 讓軟體保持最新： 定期更新所有軟體與程式庫，包括框架。大多數 XSS 漏洞源於使用較舊的 Web 框架，而這些問題已在較新版本中修補。透過定期更新，可確保所有最新的安全修補程式都已投入運作。
2. 強制使用 HTTP-Only Cookie： 將 Cookie 設定為 HTTP-Only 可防止透過 JavaScript 存取，進而防止透過 XSS 攻擊進行工作階段劫持：由於 HTTP-only Cookie 的特性，它們只會透過 HTTP 請求傳輸，且無法從用戶端指令碼存取，因此比傳統 Cookie 更安全​。
3. 停用內嵌 JavaScript： 在 Web 應用程式中停用內嵌 JavaScript，可大幅降低 XSS 風險。確保所有 JavaScript 都透過受信任的 script 標籤從外部來源執行，或採用適當編碼，可保護網站免受注入惡意程式碼所帶來的風險。
4. 使用安全程式庫： 許多安全程式庫（例如 Google 的 Caja）旨在清理使用者輸入與輸出，以防止 XSS 漏洞。這些程式庫會定期更新以因應新興威脅，若在 Web 應用程式中實作，能非常有效地大幅降低跨網站指令碼攻擊的風險。
5. 持續性的安全訓練： Web 應用程式安全意識與訓練，也可視為防止 XSS 攻擊的最佳實務之一。應持續訓練開發人員，讓其掌握透過正確驗證使用者輸入、編碼輸出，以及實作必要安全標頭來防止 XSS 的各種最新技術。同時，安全團隊也應持續更新知識，及時掌握新發現的漏洞或威脅向量資訊。

跨網站指令碼攻擊 XSS 範例

跨網站指令碼攻擊可透過多種不同形式執行，因此了解攻擊如何利用漏洞注入惡意程式碼變得非常重要。透過更深入檢視一些特定攻擊情境，開發人員與安全團隊可更有效避免 XSS 漏洞。

1. 反射型 XSS 範例

反射型 XSS 是指傳送至伺服器的惡意指令碼資料，會在伺服器回應中反射回來。例如，想像一個搜尋表單，使用者輸入會直接反映在結果頁面上，且未經編碼。攻擊者在搜尋查詢中注入如下指令碼：<script>alert(‘XSS’)</script>, 而伺服器在 HTML 中原樣返回，未做任何跳脫處理。這表示當使用者開啟頁面時，惡意指令碼就會在其瀏覽器中執行，進而提供工作階段劫持或網路釣魚攻擊的手段。因此，這是相當重大的威脅。

2. 儲存型 XSS 範例

儲存型 XSS 被視為較危險的 XSS 攻擊形式，因為具有惡意性質的酬載已暫時或永久儲存在伺服器上，可能位於資料庫或留言板中。舉例來說，攻擊者可能透過部落格的留言表單提交惡意指令碼。每當其他使用者瀏覽受感染的留言時，該指令碼就會再次執行。如此一來，攻擊者可能竊取 Cookie、劫持頁面，甚至將使用者重新導向至其他惡意網站。例如，透過注入的指令碼，例如 <script>document.cookie</script>, 這將使攻擊者能夠存取任何檢視該植入頁面之使用者的所有 Cookie。

3. DOM 型 XSS 範例

DOM 型 XSS 攻擊發生在用戶端，攻擊者會操控 DOM 環境來執行其惡意指令碼。一個很好的例子是，某網站會將 URL 參數反映到頁面內容上，卻未進行適當清理。想像如下 URL：http://example.com/page?user=<script>alert(1)</script>, 其中 Web 應用程式使用未編碼的使用者輸入，動態產生頁面的 HTML 內容。在這種情況下，警示指令碼將會在受害者的瀏覽器中執行。由於此攻擊直接在用戶端操作指令碼，因此可繞過伺服器端控制。

4. 錯誤頁面 XSS 攻擊範例

錯誤頁面在提供未跳脫的使用者輸入時，也容易受到 XSS 影響，例如 URL 中的查詢參數。請考慮一個 404 錯誤頁面顯示使用者提供的 URL 的範例，若未正確跳脫，可能會無意間執行 JavaScript 程式碼。攻擊者可能會嘗試使用如下內容： http://example.com/404?error=<script>alert(‘XSS’)</script>。若此內容在未適當清理的情況下被反映回頁面中，就會在使用者的瀏覽器中觸發該指令碼。這使錯誤頁面成為最常見卻也最容易被忽略的 XSS 漏洞向量之一。

結論

總而言之，我們了解到跨網站指令碼（XSS）仍然是各種規模組織在 Web 安全性方面最普遍且最危險的威脅之一。它能夠將惡意指令碼注入原本受信任的網站，進而導致資料竊取、身分詐欺，以及重大的聲譽損害。儘管大多數組織對 XSS 漏洞的認知仍不足，但採取輸入驗證、輸出編碼，以及使用如 Content Security Policy 等安全性原則等預防措施，可能在緩解方面發揮重大作用。

修補這類漏洞後，將可防止 XSS 攻擊並確保組織使用者的安全。例行程式碼稽核、自動化安全測試與滲透測試，是及早找出這類威脅的絕佳方式，並應成為任何組織安全策略不可或缺的一部分。對於希望強化安全態勢的企業而言，能針對包括 XSS 在內的廣泛漏洞提供整體性方法的解決方案，變得高度相關。