Dan,
I would look at it from an audit point of view. Are they
healthcare? If so it is obvious that they are passing PHI because of
the bliant use if a variable SSN is going to be obvious for an
attacker to exploit. Explaining that to a court given that HIPAA
explicitly states information like that to be encrypted would maybe
get them to think. Law suits are never nice. Just explain the letter
of the law and I am sure they will reconsider . ..

On Tue, Dec 21, 2010 at 8:31 PM, Daniel Lubarov <daniel (at) lubarov (dot) com [email concealed]> wrote:
> 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
> --------------------------------------
>
>

--
Alex J P Vargas
Email: mailto:vargasa (at) gmail (dot) com [email concealed]

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 ]