跨站Script攻擊和防範-ASP漏洞集(續)
來源:互聯網
上載者:User
攻擊 跨站Script攻擊和防範
第一部分:跨站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">Hello: <%= 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。當使用者點選連結時,使用者的瀏覽器就會直接開始第一例所說的處理過程而
彈出警告視窗。