Penetration Testing mailing list archives
Re: stupid IE7 question
From: dork () gmx at
Date: Wed, 13 Dec 2006 00:25:22 +0100
Hi, I don't want to sound like Mr. bad ass, but it's never a good idea to pass sensitive data unencrypted via GET parameters. It has several drawbacks, to name only some that come in mind: * local browsing history * possible proxies * cached sites * web server logs * possible bookmarks * possible links containing sensitive information, sent by it's users * possible XSS vulns become _really_ powerful Hiding the browser's location additionaly opens the door for phishing attacks (maybe unlikely, but that's why IE7 doesn't hide it - and they are right) When there's information contained in the URI the user should not see for himself, I'd really question the application design in general and take a closer look on session handling. Obscure methods like hiding an URI always make me question the application's input validation and data handling. For mid- to long term, you have to contact the vendor to fix this. Depending on size and structure of the application, it could take some time until there's a version not suffering from this problem. General (and not at all beautiful) approaches for short-time fixes: #1: If I got it right, you mean a popup. You could set up a rewrite rule on the server the application runs on (or if you don't control this, using a reverse proxy in front of it) that catches the initial URI of your popup and directs it to a script that a) initiates some kind of session (easy way: generate a random string and save the vars in a file named like this) b) rewrites itself to another script of yours with the session key as the only parameter c) the second script gets the original GET vars for this kinda session and destroys the session d) the second script displays a frameset with only one full-sized frame, pointing to the real URI with all GET vars. BUT: add some extra param at the and you care about in your rewrite rule - or you get an infinite loop. This will hide URI and GET parameters again and is a bit tricky. There are possibly javascripts that will not work with this solution and if there's a target attribute in links or forms within the frame, it breaks. So you'd better check for things like this in the frontend before doing such a stunt. A short version of #1 could be changing the opener of the web app itself if you're in control of it to directly point to your script or frameset. But this depends on the place and circumstances under which it's opened. If itÄs possible, it's a lot less work to do. #2: Any kind of terminal emulation containing IE6 - it's insane and propably not what you're looking for, but under some rare conditions worth thinking about. It would wipe out most benefits of a web application of course... just my first thoughts about it... On Tuesday 12 December 2006 12:18, jas1 () hotmail com wrote:
Hi. I am currently testing a proprietary (supposedly) secure web based application. The application was built around users with IE6.0 and above, one of the instances of this is that the URL is hidden from the end user when browsing the application. Of course you can ctrl-N or save the page locally to gain the URL, but most end users would not be looking for the URL. I advised a while back that the application should not be passing sensitive info via the URL in the first place. On a recent test I thought I would use IE7 and found that 'for security' reasons the URL is always displayed, greyed out. The issue here is that some internal/external proprietary applications will now display sensitive info via the URL that could cause 'serious' information disclosure - apart from relaying to the vendor to code their apps more securely, does anyone have any more suggestions please?
------------------------------------------------------------------------ This List Sponsored by: Cenzic Need to secure your web apps? Cenzic Hailstorm finds vulnerabilities fast. Click the link to buy it, try it or download Hailstorm for FREE. http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW ------------------------------------------------------------------------
Current thread:
- stupid IE7 question jas1 (Dec 12)
- Re: stupid IE7 question dork (Dec 12)
- Re: stupid IE7 question Tim (Dec 13)
- Re: stupid IE7 question Schanulleke (Dec 12)
- RE: stupid IE7 question Debasis Mohanty (Dec 12)
- Re: stupid IE7 question dork (Dec 12)