XSS跨站腳本攻擊總結

概述

跨站腳本攻擊（Cross Site Scripting），簡稱XSS，是指惡意攻擊者在Web頁面中嵌入惡意代碼，當用戶瀏覽頁面時，嵌入在Web頁面中的惡意代碼會被執行，從而達到攻擊目的。一般情況下這些惡意代碼是JavaScript代碼。XSS漏洞通常是通過php的輸出函數將JavaScript代碼輸出到Web頁面，通過用戶瀏覽器來執行，這樣我們可以知道,在代碼審計時，對於一些輸出函數要留意一下是否設置有過濾，如果未對參數進行過濾，那么就可能存在XSS漏洞。常見的輸出函數有：

echo    printf    print    print_r   sprintf    die   var_dump   var_export

XSS跨站腳本攻擊（Cross Site Scripting）不縮寫成CSS的原因是，在前端設計語言中有一個層疊樣式表（Cascading Style Sheets，CSS），為了避免重名，跨站腳本攻擊縮寫就變成了XSS。

XSS分類

反射型XSS

反射型XSS 是非持久性、參數型的跨站腳本，反射型XSS 的JS 代碼在Web 應用的參數中。這種XSS一般出現在搜索頁面中，如搜索框的反射型XSS，在搜索框中，輸入<script>alert(/xss/)</script>，點擊搜索，即可觸發反射型XSS。這時 我們提交的參數一般會以GET或者POST的方式出現在URL中。下面我們就來實現以下反射型的XSS，我使用的是metasploitable2上的DVWA靶機，上面有各種基本的漏洞，比如SQL注入，CSRF，文件上傳等。

LOW級別的XSS：

首先我們登陸DVWA之后把安全級別設為LOW。先利用alert來測試一下是否存在XSS漏洞。

 

網頁彈出窗口，說明執行了我們提交的參數中包含的JS代碼，存在XSS漏洞，接下來我們嘗試利用XSS漏洞獲取網站的cookie，編寫cookie.php來獲取頁面的cookie。cookie.php代碼如下：

<?php
    $cookie = $_GET['cookie'];
    file_put_contents('cookie.txt',$cookie)
?>

 

在頁面URL參數中插入JS代碼，將頁面的cookie發送到cookie.php，需要注意的是這里參數需要轉換為URL編碼格式。

 

訪問一下，看到網頁正常跳轉，沒有異常，說明代碼運行成功，此時在cookie.php同一目錄下應該有cookie.txt文件，記錄了頁面的cookie信息。

現在我們就已經利用了網站的XSS獲得頁面的cookie，利用cookie我們可以登錄DVWA的首頁。

 

Medium級別XSS

我們將安全級別設置為medium，首先進行一下alert測試，發現沒有彈窗，script應該是被過濾了。

 

這里有兩種方法可以繞過過濾：

• script嵌套
• 大小寫混寫

通過繞過過濾這時候就出現彈窗了，用同LOW級別的XSS方法獲取cookie，達到登錄目的。

 

high級別XSS

將安全級別設置為high，通過low和medium級別的alert測試，發現這時候都沒有出現彈窗。這時我們可以考慮換一個標簽：

• img標簽

 

<img src=x onError=alert('1')>

 

 

 

• ifram標簽

 

<iframe onload=alert(1)>

 

但是我測試時候，img和iframe標簽並不能繞過DVWA的高級反射型XSS的過濾，可能是這個級別的XSS將&、"、'、<、>這些符號轉換成html實體，防止瀏覽器將他們作為HTML元素。

存儲型XSS

存儲型XSS與反射型XSS的區別在於存儲型會將用戶輸入的數據存入服務器，在用戶下一次點擊時便會觸發，由於其隱蔽性較高，所以危害性要比反射型XSS大一些。

LOW級別

還是一樣的套路，我們先用JS代碼檢測一下是否存在XSS漏洞，這里message欄輸入以下代碼發現又彈出窗口的，而且並沒有什么過濾，所以很好實現xss。

<script>alert('xss')</script>

 Mideum級別

這里使用之前提到的繞過手段都沒有用，看了源碼之后才知道，message幾乎過濾掉了所有的xss腳本，但是name並沒有過濾。這里從name入手，但是name字段的的長度收到了限制，所以我們用burpsuite抓包，修改name的值，來實現xss攻擊。

 

驗證xss漏洞存在之后，利用的原理和前面一樣，構造腳本得到cookie。

XSS防御

1、不要在頁面中插入任何不可信數據，除非這些數已經據根據后面幾個原則進行了編碼

1. 在將不可信數據插入到HTML標簽之間時，對這些數據進行HTML Entity編碼
2. 在將不可信數據插入到HTML屬性里時，對這些數據進行HTML屬性編碼
3. 在將不可信數據插入到SCRIPT里時，對這些數據進行SCRIPT編碼
4. 在將不可信數據插入到Style屬性里時，對這些數據進行CSS編碼
5. 在將不可信數據插入到HTML URL里時，對這些數據進行URL編碼

2、使用富文本時，使用XSS規則引擎進行編碼過濾

3、防御DOM Based XSS

  DOM Based XSS是從javascript中輸出數據到HTML頁面里。把變量輸出到頁面時要做好相關的編碼轉義工作，如要輸出到 <script>中，可以進行JS編碼；要輸出到HTML內容或屬性，則進行HTML編碼處理。根據不同的語境采用不同的編碼處理方式。

4、HttpOnly Cookie

　　一般的Cookie都是從document對象中獲得的，現在瀏覽器在設置 Cookie的時候一般都接受一個叫做HttpOnly的參數，跟domain等其他參數一樣，一旦這個HttpOnly被設置，你在瀏覽器的 document對象中就看不到Cookie了，而瀏覽器在瀏覽的時候不受任何影響 ，因為Cookie會被放在瀏覽器頭中發送出去(包括ajax的時 候)，應用程序也一般不會在js里操作這些敏感Cookie的，對於一些敏感的Cookie我們采用HttpOnly，對於一些需要在應用程序中用js操作的cookie我們就不予設置，這樣就保障了Cookie信息的安全也保證了應用。

5、輸入檢查

  輸入檢查一般是檢查用戶輸入的數據中是否包含一些特殊字符，如<、>、'、"等，如果發現存在特殊字符，則將這些字符過濾或者編碼。例如輸入email的文本框只允許輸入格式正確的email，輸入手機號碼的文本框只允許填入數字且格式需要正確。這類合法性驗證至少需要在服務器端進行以防止瀏覽器端驗證被繞過，而為了提高用戶體驗和減輕服務器壓力，最好也在瀏覽器端進行同樣的驗證。

參考

DVWA--XSS解題過程

DVWA之Stored XSS（存儲型XSS）

https://www.jianshu.com/p/b5c87ad6f796