簡(jiǎn)介：跨站點(diǎn)腳本編制可能是一個(gè)危險(xiǎn)的安全性問(wèn)題，在設(shè)計(jì)安全的基于 Web 的應(yīng)用程序時(shí)應(yīng)該考慮這一點(diǎn)。本文中，Paul 描述了這種問(wèn)題的本質(zhì)、它是如何起作用的，并概述了一些推薦的修正策略。

當(dāng)今的大多數(shù)網(wǎng)站都對(duì) Web 頁(yè)面添加了動(dòng)態(tài)內(nèi)容，從而使用戶能獲得更愉快的體驗(yàn)。動(dòng)態(tài)內(nèi)容是由某些服務(wù)器進(jìn)程生成的內(nèi)容，它可以根據(jù)用戶的設(shè)置和需要在提交時(shí)表現(xiàn)出不同的行為和產(chǎn)生不同的顯示。動(dòng)態(tài)網(wǎng)站存在著一個(gè)稱為“跨站點(diǎn)腳本編制”（也稱為“XSS”）的威脅，而這是靜態(tài)網(wǎng)站所沒(méi)有的。

“一個(gè)網(wǎng)頁(yè)可以包含由服務(wù)器生成的、并且由客戶機(jī)瀏覽器解釋的文本和 HTML 標(biāo)記。只生成靜態(tài)頁(yè)面的網(wǎng)站能完全控制瀏覽器用戶如何解釋這些頁(yè)面。而生成動(dòng)態(tài)頁(yè)面的網(wǎng)站不能完全控制客戶機(jī)如何解釋其輸出。問(wèn)題的核心是，如果不可信的內(nèi)容被引入到動(dòng)態(tài)頁(yè)面中，則無(wú)論是網(wǎng)站還是客戶機(jī)都沒(méi)有足夠的信息識(shí)別這種情況的發(fā)生并采取保護(hù)措施，”― CERT 協(xié)調(diào)中心（CERT Coordination Center）如是說(shuō)。該中心是由聯(lián)邦政府資助的研究開(kāi)發(fā)中心，研究因特網(wǎng)安全性弱點(diǎn)并提供事件響應(yīng)。

跨站點(diǎn)腳本編制正不斷受到攻擊者的廣泛青睞，因?yàn)樵诰W(wǎng)站上很容易找到這種安全性問(wèn)題。商業(yè)站點(diǎn)上每月都會(huì)發(fā)現(xiàn)跨站點(diǎn)腳本編制的攻擊，并且每月都會(huì)發(fā)布解釋這種威脅的報(bào)告。如果不加注意，則您網(wǎng)站的安全運(yùn)行的能力以及您公司的聲譽(yù)都可能成為這些攻擊的犧牲品。

編寫(xiě)本文的目的是使大家對(duì)這一新出現(xiàn)的威脅引起注意，并為 Web 應(yīng)用程序避免這種攻擊提供解決方案實(shí)現(xiàn)。

跨站點(diǎn)腳本編制的威脅

跨站點(diǎn)腳本編制將服務(wù)器應(yīng)用程序置于危險(xiǎn)之中，這些危險(xiǎn)包括（但不限于）以下幾種情況：

當(dāng)用戶查看基于攻擊者提供的內(nèi)容而動(dòng)態(tài)生成的頁(yè)面時(shí)，他們會(huì)不知不覺(jué)地執(zhí)行惡意腳本。

在用戶的會(huì)話 cookie 失效之前，攻擊者就能接管用戶會(huì)話。

攻擊者可以將用戶連接到攻擊者選擇的惡意服務(wù)器上。

攻擊者誘導(dǎo)用戶訪問(wèn)由攻擊者提供的 URL，從而導(dǎo)致在用戶的瀏覽器中執(zhí)行攻擊者選擇的腳本或 HTML。通過(guò)使用這種技術(shù)，攻擊者可以使用訪問(wèn)過(guò)此 URL 的用戶的特權(quán)來(lái)采取行動(dòng)，諸如對(duì)底層 SQL 數(shù)據(jù)庫(kù)發(fā)出查詢并查看其結(jié)果，以及使用目標(biāo)系統(tǒng)上已知的有問(wèn)題的實(shí)現(xiàn)。

發(fā)動(dòng)攻擊

當(dāng)攻擊者知道某一網(wǎng)站上的應(yīng)用程序易受跨站點(diǎn)腳本編制攻擊后，他就可以規(guī)劃攻擊。攻擊者最常用的技術(shù)是使用受害者的特權(quán)在受害者的系統(tǒng)上插入 JavaScript、VBScript、ActiveX、HTML 或 Flash 并執(zhí)行。一旦激活了攻擊，就可能發(fā)生從截獲帳戶、更改用戶設(shè)置、竊取和篡改 cookie 到虛假?gòu)V告在內(nèi)的任何事情。

樣本攻擊方案

以下方案用圖說(shuō)明了一些比較典型的攻擊。但是，我們無(wú)法列出有關(guān)弱點(diǎn)的所有變體情況。

借助惡意鏈接的腳本編制

在本方案中，攻擊者將一個(gè)專門(mén)精心制作的電子郵件消息發(fā)送給受害者，這個(gè)消息包含如下所示的惡意鏈接腳本：

當(dāng)沒(méi)有對(duì)此產(chǎn)生懷疑的用戶點(diǎn)擊該鏈接時(shí)，URL 被發(fā)送到包含惡意代碼的?legitimateSite.com?。如果合法服務(wù)器將一個(gè)包含?clientprofile?值的頁(yè)面發(fā)回給用戶，則在客戶機(jī) Web 瀏覽器上就會(huì)執(zhí)行惡意代碼，如?圖 1?所示。

圖1 通過(guò)電子郵件攻擊

竊取用戶cookie

如果網(wǎng)站的任一部分使用了 cookie，則從該網(wǎng)站的用戶處竊取這些 cookie 是有可能的。本方案中，攻擊者使包含惡意腳本的頁(yè)面成為易受攻擊站點(diǎn)的一部分。顯示該頁(yè)面時(shí)，惡意腳本就運(yùn)行，它收集用戶的 cookie，并向攻擊者的網(wǎng)站發(fā)送包含收集到的 cookie 的請(qǐng)求。通過(guò)使用這種技術(shù)，攻擊者可以獲得諸如密碼、信用卡號(hào)以及用戶輸入的任意信息等敏感數(shù)據(jù)，如?圖 2?所示。

圖2 竊取cookie和截獲帳戶

發(fā)送未經(jīng)授權(quán)的請(qǐng)求

在本方案中，當(dāng)用戶執(zhí)行郵件消息中的惡意鏈接時(shí)，就會(huì)不知不覺(jué)地執(zhí)行攻擊者編寫(xiě)的腳本。因?yàn)閻阂饽_本執(zhí)行時(shí)所在的上下文看上去源自合法服務(wù)器，所以攻擊者對(duì)所檢索的文檔有完全的訪問(wèn)權(quán)，并可以將包含在頁(yè)面中的數(shù)據(jù)發(fā)回他們自己的站點(diǎn)。如果嵌入的腳本代碼具有額外的與合法服務(wù)器交互的能力，并且交互時(shí)不會(huì)警告受害者，則攻擊者可以開(kāi)發(fā)和利用合法 Web 服務(wù)器上不同頁(yè)面中張貼的那些數(shù)據(jù)，如?圖 3?所示。

圖3 發(fā)送未經(jīng)授權(quán)的請(qǐng)求

避免攻擊

如上所述，當(dāng)攻擊者能夠使合法 Web 服務(wù)器將一個(gè)包含攻擊者選擇的惡意腳本的頁(yè)面發(fā)送到受害用戶的 Web 瀏覽器時(shí)，就實(shí)現(xiàn)了跨站點(diǎn)腳本編制攻擊。然后攻擊者就可以使用源自合法 Web 服務(wù)器的合法腳本的特權(quán)運(yùn)行惡意腳本。

既然我們知道了攻擊的基本知識(shí)，那么做些什么才能保護(hù)我們自己避免這一脆弱性呢？

通過(guò)確保動(dòng)態(tài)生成的頁(yè)面不包含不期望的標(biāo)記，網(wǎng)站開(kāi)發(fā)人員可以防止他們的站點(diǎn)被濫用。

從 Web 用戶的角度而言，要降低因?yàn)檫@一脆弱性而遭受攻擊的風(fēng)險(xiǎn)，有兩種選擇。第一種選擇是在 Web 瀏覽器中禁用腳本編制語(yǔ)言，以及禁用支持 HTML 的電子郵件客戶機(jī)，這種選擇提供了最大程度的保護(hù)，但存在著禁用功能的副作用。第二種選擇是只執(zhí)行主網(wǎng)站的鏈接進(jìn)行查看，這將顯著降低用戶暴露給攻擊者的風(fēng)險(xiǎn)，同時(shí)仍能保留功能。

但是，在 Web 用戶可以采用的任何解決方案中，沒(méi)有一種是徹底的解決方案。最終，還是應(yīng)當(dāng)由 Web 頁(yè)面開(kāi)發(fā)人員作出決定來(lái)修改他們的頁(yè)面以消除這幾類問(wèn)題。通過(guò)適當(dāng)過(guò)濾和驗(yàn)證所接收的輸入以及適當(dāng)編碼或過(guò)濾返回給用戶的輸出，可以實(shí)現(xiàn)這一點(diǎn)。

過(guò)濾

這種方法的基本原理是決不相信用戶輸入，并總是過(guò)濾 HTML 規(guī)范中定義的元字符（“特殊”字符）。對(duì)包括鏈接參數(shù)在內(nèi)的每個(gè)輸入字段都驗(yàn)證是否為腳本標(biāo)記。當(dāng)發(fā)現(xiàn)這樣的輸入時(shí)，根據(jù)上下文來(lái)拒絕它，這樣可以防止向用戶提供惡意的 HTML。

這種方法所帶來(lái)的復(fù)雜性是許多 Web 瀏覽器都會(huì)嘗試糾正 HTML 中常見(jiàn)的錯(cuò)誤。其結(jié)果是，依照規(guī)范，當(dāng)有些字符不是特殊字符時(shí)，他們有時(shí)也會(huì)將這些字符視為特殊字符。因此，要注意可能保證把額外字符包括到特殊字符列表中的個(gè)別情況，這一點(diǎn)很重要。Web 開(kāi)發(fā)人員必須檢查他們的應(yīng)用程序，并確定哪些字符會(huì)影響他們的 Web 應(yīng)用程序。

對(duì)輸入端進(jìn)行過(guò)濾的效率比較低，因?yàn)橥ㄟ^(guò)除了 HTTP 以外的其它方法也可以將動(dòng)態(tài)內(nèi)容輸入到網(wǎng)站數(shù)據(jù)庫(kù)中。本例中，Web 服務(wù)器可能從未將這些數(shù)據(jù)視為數(shù)據(jù)輸入過(guò)程的一部分，因此這些數(shù)據(jù)元素仍然可能是受污染的。另外，建議就在數(shù)據(jù)作為動(dòng)態(tài)頁(yè)面的一部分呈現(xiàn)之前，將過(guò)濾作為數(shù)據(jù)輸出過(guò)程的一部分來(lái)完成。正確執(zhí)行后，這種方法確保過(guò)濾了所有動(dòng)態(tài)內(nèi)容。

編碼

當(dāng) Web 服務(wù)器充分確保了對(duì)生成的頁(yè)面進(jìn)行了正確編碼以防止腳本的無(wú)意執(zhí)行時(shí)，可以避免跨站點(diǎn)腳本編制的攻擊。

ISO-8859-1 規(guī)范中的每個(gè)字符都可以使用其數(shù)字項(xiàng)值進(jìn)行編碼。服務(wù)器端的編碼是一個(gè)過(guò)程，其中所有動(dòng)態(tài)內(nèi)容都將經(jīng)過(guò)一個(gè)編碼函數(shù)，這時(shí)，腳本編制標(biāo)記將被替代為所選擇的字符集中的代碼。

一般而言，推薦進(jìn)行編碼，因?yàn)樗灰竽鷽Q定什么樣的字符可以合法地輸入，而什么樣的字符需要通過(guò)編碼函數(shù)的檢查。遺憾的是，對(duì)所有不可信數(shù)據(jù)編碼是資源密集型的工作，而且可能對(duì)某些 Web 服務(wù)器產(chǎn)生性能方面的影響。

哪種策略適合我？

基于 CGI 的 Web 應(yīng)用程序或支持瀏覽器中字段編輯檢查的應(yīng)用程序很可能適合于過(guò)濾策略，通過(guò)將現(xiàn)有的字段編輯檢查擴(kuò)展至包括檢查跨站點(diǎn)腳本編制的弱點(diǎn)即可。請(qǐng)注意，雖然瀏覽器端的字段編輯檢查節(jié)省了與服務(wù)器通信的幾個(gè)來(lái)回，但它適用于誠(chéng)實(shí)的用戶，而且需要完整的代碼遍歷以保證檢查了所有的輸入字段來(lái)滿足修正建議的要求。但是，內(nèi)部設(shè)計(jì)有服務(wù)器端驗(yàn)證的 Web 應(yīng)用程序可以選擇適應(yīng)兩種策略中的任一種，或同時(shí)適應(yīng)這兩種策略。

要使過(guò)濾策略正確工作，Web 開(kāi)發(fā)人員需要確保的是，依照其應(yīng)用程序的需要，過(guò)濾用的元字符列表是最新的。相反，編碼策略不需要進(jìn)行上述維護(hù)工作，而且它對(duì)現(xiàn)有應(yīng)用程序代碼以及應(yīng)用程序功能的影響也較小。基于這些原因，看來(lái)編碼策略是受歡迎的實(shí)現(xiàn)選擇。下一節(jié)將描述樣本編碼實(shí)現(xiàn)。

樣本編碼

對(duì) Web 服務(wù)器而言，確保正確編碼所生成的頁(yè)面的簡(jiǎn)單而又有效的方法是：將動(dòng)態(tài)內(nèi)容中的每個(gè)字符都傳遞通過(guò)一個(gè)編碼函數(shù)，在該函數(shù)中，動(dòng)態(tài)內(nèi)容中的腳本編制標(biāo)記被替代為所選定的字符集中的代碼。這個(gè)任務(wù)最適合于定制標(biāo)記庫(kù)。

定制標(biāo)簽庫(kù)的基礎(chǔ)知識(shí)

定制標(biāo)記庫(kù)由一個(gè)或多個(gè) Java 語(yǔ)言類（稱為標(biāo)記處理程序）以及 XML 標(biāo)記庫(kù)描述文件（TLD）組成，后者描述新的標(biāo)記名和那些標(biāo)記的有效屬性。標(biāo)記處理程序和 TLD 確定在請(qǐng)求時(shí)，從 JSP 頁(yè)面內(nèi)如何解釋和處理這些標(biāo)記及其屬性和主體。在封裝復(fù)雜操作時(shí)，定制標(biāo)記庫(kù)提供了一種比 Java bean 更靈活的體系結(jié)構(gòu)。

定制的合適標(biāo)簽庫(kù)

除了將我們的定制標(biāo)記庫(kù)命名為?XSS?之外，還有什么更好的叫法嗎？標(biāo)記庫(kù)是插入到 servlet 容器的軟件組件。servlet 容器創(chuàng)建標(biāo)記處理程序，對(duì)它們初始化并依次調(diào)用?doStartTag()?、?doEndTag()?和?release()?方法。

通過(guò)這些交互，我們的 XSS 定制標(biāo)記庫(kù)就能應(yīng)用“定制”操作，這種操作編碼在 JSP 頁(yè)面上找到的動(dòng)態(tài)數(shù)據(jù)。實(shí)現(xiàn)定制標(biāo)記很簡(jiǎn)單，其步驟如下所示：

創(chuàng)建一個(gè)描述標(biāo)記的標(biāo)記庫(kù)描述符（?.tld?）。

將?taglib?偽指令添加到使用這些標(biāo)記的 JSP 文件中。

實(shí)現(xiàn)繼承 TagSupport 和覆蓋?doStartTag()?或?doEndTag()?方法的標(biāo)記處理程序。

TLD（標(biāo)記庫(kù)描述符）

標(biāo)記庫(kù)描述符是一個(gè) XML 文件，其元素描述了特殊的標(biāo)記庫(kù)。?清單 1?顯示了我們的?XSS?定制標(biāo)記庫(kù)的 tld 文件。標(biāo)記元素定義了?encode?操作，包括屬性?property?。?tagclass?元素定義標(biāo)記處理程序類?EncodeTag?。

清單 1. xss.tld 文件

taglib 偽指令

taglib 偽指令識(shí)別標(biāo)記庫(kù)描述符，并定義使后繼標(biāo)記與庫(kù)相關(guān)聯(lián)的標(biāo)記前綴。在使用?XSS?定制標(biāo)記庫(kù)的 JSP 中出現(xiàn)的樣本 taglib 偽指令如下所示：

taglib 偽指令

標(biāo)記處理程序是 Web 容器中的對(duì)象，在執(zhí)行 JSP 頁(yè)面時(shí)它幫助對(duì)操作求值。?EncodeTag?類是用于編碼操作的標(biāo)記處理程序。它的?doStartTag?方法將動(dòng)態(tài)內(nèi)容編碼為 ISO-8859-1 字符集，該方法顯示在?清單 2中。

清單2 編碼動(dòng)態(tài)內(nèi)容

部署

XSS?定制標(biāo)記庫(kù)是 Web 應(yīng)用程序的一部分，它作為附加文件打包到 Web 應(yīng)用程序的 WAR 文件中，如下所示：

WEB-INF/lib/encodetaglib.jar

WEB-INF/tlds/xss.tld

應(yīng)用

以下方案說(shuō)明了如何使用定制標(biāo)記庫(kù)。假設(shè)有一個(gè)接收文章的虛擬網(wǎng)站，其中有一個(gè)評(píng)論您所訂閱文章的頁(yè)面。動(dòng)態(tài)內(nèi)容，即打算提供給您的文章條目，是在 JSP 文件內(nèi)使用?<%= expression %>?語(yǔ)法準(zhǔn)備的。

讓我們假設(shè)攻擊者成功地將一個(gè)包含惡意腳本的頁(yè)面填入到訂閱成員使用的網(wǎng)站上。這個(gè)成功攻擊的效果，就是當(dāng)在用戶瀏覽器上執(zhí)行該頁(yè)面時(shí)，會(huì)顯示一個(gè)彈出窗口，如?圖 4?中所示。

圖4 編碼前

在下一個(gè)方案中，這個(gè)虛擬網(wǎng)站確保生成的頁(yè)面是通過(guò)使用?XSS?定制標(biāo)記庫(kù)正確編碼的，并且能避免攻擊。不可信的數(shù)據(jù)被保留下來(lái)用于在瀏覽器中可視查看，如?圖 5?所示。

編碼后

結(jié)語(yǔ)

本文中，我們討論了攻擊者如何使用跨站點(diǎn)腳本編制作為對(duì)網(wǎng)站發(fā)動(dòng)攻擊的技術(shù)。我們還演示了當(dāng)網(wǎng)站使用簡(jiǎn)單的定制標(biāo)記庫(kù)正確編碼動(dòng)態(tài)內(nèi)容時(shí)，可以消除大多數(shù)攻擊?？梢浴鞍船F(xiàn)狀”使用?XSS?定制標(biāo)記庫(kù)，或更為有效地更改該定制標(biāo)記庫(kù)使之適合您的 Web 應(yīng)用程序需要，保護(hù)您的 Web 應(yīng)用程序避免受到這種新出現(xiàn)的威脅。