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: