Re: hard-to-sell vulnerabilities

[Brad Causey <bradcausey () owasp org>]

It sounds like you are trying to create a vulnerability where there is
an information disclosure issue. Is the fact that sensitive data is
being passed in a url parameter not enough of an issue?

On 12/21/10, Martín <olemoudi () gmail com> 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&apos;;
> 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
> --------------------------------------

-- 
Sent from my mobile device

-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org
--
"Si vis pacem, para bellum"
--



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
--------------------------------------