You could open the browser logs to show how a user's information would be
disclosed if he/she was using a public computer (library, kiosk, hotel
business center, etc.).

You could also show the web server logs and explain how that information
would be accessible by unintentional parties or people responsible for the
backup and archival of server logs.

Regards,
Abe

-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On
Behalf Of Martín
Sent: Tuesday, December 21, 2010 12:06 PM
To: webappsec (at) securityfocus (dot) com [email concealed]; pen-test (at) securityfocus (dot) com [email concealed]
Subject: hard-to-sell vulnerabilities

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

[ reply ]