From: dork@gmx.at
Date: Tue Dec 12 2006 - 18:25:22 EST
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
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:26 EDT