Web Application Security
hard-to-sell vulnerabilities Dec 21 2010 08:06PM
Martín (olemoudi gmail com) (3 replies)
RE: hard-to-sell vulnerabilities Dec 22 2010 05:18AM
Abe (abek1 comcast net)
Re: hard-to-sell vulnerabilities Dec 22 2010 12:21AM
Brad Causey (bradcausey owasp org) (1 replies)
Re: hard-to-sell vulnerabilities Dec 22 2010 02:31AM
Daniel Lubarov (daniel lubarov com) (1 replies)
Visit the page in FireFox, close FF, navigate to the user's FF profile
in a shell, then run

egrep -oa SSN=.{9} places.sqlite

Is this not convincing enough?

On Tue, Dec 21, 2010 at 4:21 PM, Brad Causey <bradcausey (at) owasp (dot) org [email concealed]> wrote:
>
> 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 (at) gmail (dot) com [email concealed]> 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
> > --------------------------------------
> >
> >
>
> --
> 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
> --------------------------------------
>

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

[ reply ]
Re: hard-to-sell vulnerabilities Dec 22 2010 07:36PM
Alex Vargas (vargasa gmail com) (1 replies)
Re: hard-to-sell vulnerabilities Dec 23 2010 12:35AM
Guillermo Caminer (flaco webappsec gmail com)
Re: hard-to-sell vulnerabilities Dec 21 2010 11:40PM
Eduardo Vela (sirdarckcat gmail com) (1 replies)
Re: hard-to-sell vulnerabilities Dec 21 2010 11:49PM
Eduardo Vela (sirdarckcat gmail com)


 

Privacy Statement
Copyright 2010, SecurityFocus