黑客技術：跨站ASP Script攻擊

　　每當我們想到黑客的時候，黑客往往是這樣一幅畫像：一個孤獨的人，悄悄進入別人的服務器中，進行破壞或者竊取別人的秘密資料。也許他會更改我們的主頁，甚者會竊取客戶的信用卡號和密碼。另外，黑客還會攻擊訪問我們網站的客戶。與此同時，我們的服務器也成了他的幫凶。微軟稱這種攻擊為“跨站script攻擊。而這種攻擊大多數都發生在網站動態產生網頁的時侯，但黑客的目標並不是你的網站，而是浏覽網站的客戶。

　　跨站script攻擊的說明

　　在一本名為＜＜ADVISORY CA--2000-02＞＞的雜志中，CERT警告大家：如果服務器對客戶的輸入不進行有效驗證，黑客就會輸入一些惡意的HTML代碼，當這些HTML代碼輸入是用於SCRIPT程序，他們就能利用它來進行破壞，如插入一些令人厭惡的圖片或聲音等，同時，也能干擾了客戶正確浏覽網頁。

　　我們知道，有些朋友曾經被誘導到一些可疑的免費網站，他們得到的僅僅是10到20個小的窗口，這些窗口常常伴隨著由JAVA 或 JAVASCRIPT生成的失效安鈕，這被稱為鼠標陷阱。關閉這些窗口是徒勞的，每當我們關閉一個窗口，又會有10幾個窗口彈出。這種情況常常發生在管理員沒在的時侯發生。鼠標事件是黑客利用跨站SCRIPT方法攻客戶的典型范例。

　　惡意的標簽和SCRIPT不單純的惡作劇，他們甚至可以竊取資料和搗毀系統。一個聰明的甚至是不夠聰明的黑客都能夠使用SCRIPT干擾或者改變服務器數據的輸入。利用SCRIPT代碼也能攻擊客戶系統，讓你的硬盤盡損。而且你要知道，在你一邊使用服務器的時候，黑客的SCRIPT也正在你服務器裡安全的地方運行著的呀！如果客戶對你的服務器非常信認，同樣他們也會信任那些惡意的SCRIPT代碼。甚至這個代碼是以〈SCRIPT〉或者〈OBJECT〉的形式來自黑客的服務器。

　　即使使用了防火牆（SSL）也不能防止跨站SCRIPT的攻擊。那是因為如果生成惡意SCRIPT代碼的設備也使用了SSL，我們服務器的SSL是不能辨別出這些代碼來的。我們難道就這樣把客戶曾經那麼信任的網站拱手讓給黑客嗎？而且有這種破壞的存在，會讓你網站名譽盡損的。

　　一、跨站SCRIPT攻擊示例：

　　根據CERT的資料，動態輸入大致有這幾種形式：URL參數，表格元素，COOKISE以及數據請求。讓我們來分析一下，這個只有兩個頁面的網站，網站名為：MYNICESITE.COM。第一頁使用一張表格或COOKIE來獲取用戶名：

　　＜%@ Language=VBScript %＞

　　＜% If Request.Cookies("userName") ＜＞ "" Then

　　Dim strRedirectUrl

　　strRedirectUrl = "page2.asp?userName="

　　strRedirectUrl = strRedirectUrl & Response.Cookies("userName")

　　Response.Redirect(strRedirectUrl)

　　Else %＞

　　＜HTML＞

　　＜HEAD＞

　　＜TITLE＞MyNiceSite.com Home Page＜/TITLE＞

　　＜/HEAD＞

　　＜BODY＞

　　＜H2＞MyNiceSite.com＜/H2＞

　　＜FORM method="post" action="page2.asp"＞

　　Enter your MyNiceSite.com username:

　　＜INPUT type="text" name="userName"＞

　　＜INPUT type="submit" name="submit" value="submit"＞

　　＜/FORM＞

　　＜/BODY＞

　　＜/HTML＞

　　＜% End If %＞

　　第二頁返回用戶名以示歡迎：

　　＜%@ Language=VBScript %＞

　　＜% Dim strUserName

　　If Request.QueryString("userName")＜＞ "" Then

　　strUserName = Request.QueryString("userName")

　　Else

　　Response.Cookies("userName") = Request.Form("userName")

　　strUserName = Request.Form("userName")

　　End If %＞

　　＜HTML＞

　　＜HEAD＞＜/HEAD＞

　　＜BODY＞

　　＜H3 align="center"＞Hell ＜%= strUserName %＞ ＜/H3＞

　　＜/BODY＞

　　＜/HTML＞

　　當你正常常輸入文字時，一切都很正常。如果你輸入Script代碼：＜SCRIPT＞alert(’Hello.’;＜/script＞,JavaScript警告標簽就會彈出來：

　　在你下一次訪問時，這個警示標簽同樣會出現；這是因為這個Script代碼在你第一次訪問的時後就已經留在cookie中了。這是一個簡單的跨站攻擊的范例。

　　如果你認為這是一個特殊情況，你也不妨到網上別的地方看看，親自試一下。我曾經對一些大型的政府網站、教育網站以及商業網站進行過測試，他們當中的確有部分出現了以上所說的情況，我甚至發現了我經常使用信用卡的網站也居然對輸入不進行任何過濾，想想真是可怕。

二、 用E-Mail進行跨站Script攻擊

　　跨站script攻擊用在列表服務器，usenet服務器和郵件服務器來得特別容易。下面還是以MyNiceSite.com網站為例進行說明。由於你經常浏覽這個網站，它的內容也的確讓你愛不愛不釋手，因此在不知不覺中你就把浏覽器的改成了總是信任這個動態網站內容的設置。

　　MyNiceSite.com網站總是通過出售征訂它們Email信件的郵箱地址來獲得收入，這的確是一種不太好的辦法。於是我買了它的一份郵箱地址。並發了大量的郵件給你們。在信中我告訴你們盡快訪問這個網 站，並檢查你們帳戶使用的最新情況。為了讓你們感到方便，我在這信中也作了鏈接。我在這鏈接URL中的username參數中舔加了script代碼。有些客戶在不知不覺中就點擊了這個鏈接，也就是說上了我的當，同時我也從中得到了好處：

　　它是這樣工作的，當你點擊這個鏈接的時後，在鏈接裡的script代碼就會引導你所用浏覽器去下載我的JavaScript程序並執行它。我的Script檢查到你使用的是IE浏覽器後，就著手下載ActiceX控件 particularlyNasty.dll。因為之前你已經把這個網站的內容認為總是安全的，這樣，我的script代碼和Active 控件就能在你機器上自由自在的運行了。

　　三、 Activex攻擊說明

　　在討論ActiveX時，CERT和微軟都沒提到跨站script方法所帶來的的危險。W3C在＜＜安全常見問題解答＞＞中對ActiveX的安全問題作了比較詳盡的說明。Java applet對系統的控制受到嚴格限制。SUN開發它時就規定，只有那些對系統的安全不構成威脅的操作才被允許運行。

　　在另一方面，ActiveX對系統的操作就沒有嚴格地被限制。如果一但被下載，就可以象安裝的可執行程序一樣做他們想干的事情。針對這一特點IE浏覽器也作了某些限制，如對於那些不安全的站點，在它的默認設置中就會不允許你進行下載或者會給你警告的提示。正在基於ActiveX進行開發的公司，如VeriSign公司，它們對ActiveX控件都給編了號。當你在下載控件的時後，IE浏覽器會給你警告並顯示它的可信籁程度。由用戶決定是否相信這個控件。這樣一來系統的安全性就增加了。

　　但是，對於那些沒有多少經驗的用戶來說，他們往往不自覺地對原來的設置進行了修改，讓這些控件在沒有任何提示的情況下就下載了。另外，對一個新手來說，即使在有提示的情況下也會不加思索地下載那些沒作任何標記的控件。在我們所舉的例子中，由於你對該站點的信任，改了浏覽器的設置，這樣，ActiveX控件在不經過任何提示的情況下就下載，並在你的機器上不知不覺地開始運行。

　　四、16進制編碼的ActiveX Script 攻擊

　　要把用心不良的標簽和script區分出來是一件非常困難的事。Script還可以16進制的形式把自己藏起來。讓我們看看下面這個E-mail范例好嗎？它是以16進制的形式被發送出去的：

　　這幾乎是一封完整的郵件，裡面包含了以16進制偽造的URL參數：sender=mynicesite.com。當用戶點擊鏈接時，用戶的浏覽器就會直接開始第一例所說的處理過程而彈出警告窗口。

　　第二部分：跨站Script攻擊的防犯

　　一、如何避免服務器受到跨站Script的攻擊

　　值得慶幸的是，防止跨站Script攻擊的技術正趨於完善。目前可采取這幾種方式來防止跨站Script的攻擊：

　　1.對動態生成的頁面的字符進行編碼

　　你們首先要采用的就是對動態生成頁面的字符進行編碼，你必須這樣做，不然黑客很有可能更改你的字符設置而輕易地通過你的防線。如果我們的網站是個英語網站，這樣只要我們把字符編碼設成拉丁字符ISO-8859-1就行了，具體情況如下：

　　＜META http-equiv="Content-Type" content="text/HTML;charset=ISO-8859-1"＞

　　2.過濾和限制所有輸入的數據

　　這是防止跨站Script的攻擊的第二種方法，在進行登錄的時侯，不要讓那些特殊的字符也輸入進去。因此我們可在ONSUBMIT方法中加入JAVASCRIPT程序來完成這個功能。在本例中我們限制最多只能輸入15個字符。這樣可以阻止那些較長的script的輸入。

　　在＜＜Knowledge Base Article QA25