WebApp Sec mailing list archives
Re: hard-to-sell vulnerabilities
From: Daniel Lubarov <daniel () lubarov com>
Date: Tue, 21 Dec 2010 18:31:09 -0800
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 () owasp org> 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 () 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'; 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 --------------------------------------
Current thread:
- hard-to-sell vulnerabilities Martín (Dec 21)
- Re: hard-to-sell vulnerabilities Eduardo Vela (Dec 21)
- Re: hard-to-sell vulnerabilities Eduardo Vela (Dec 21)
- Re: hard-to-sell vulnerabilities Brad Causey (Dec 21)
- Re: hard-to-sell vulnerabilities Daniel Lubarov (Dec 21)
- Re: hard-to-sell vulnerabilities Alex Vargas (Dec 22)
- Re: hard-to-sell vulnerabilities Guillermo Caminer (Dec 23)
- Re: hard-to-sell vulnerabilities Daniel Lubarov (Dec 21)
- Re: hard-to-sell vulnerabilities Eduardo Vela (Dec 21)
- RE: hard-to-sell vulnerabilities Abe (Dec 21)