Slashdot Mirror
New Vulnerability Affects All Browsers
Jimmy writes "Secunia is reported about a new vulnerability, which affects all browsers. It allows a malicious web site to "hi-jack" pop-up windows, which could have been opened by e.g. a your bank or an online shop. Here is a demonstration of the vulnerability"
Thank goodness we've found our first vulnerability in Firefox. Now we can move from the myth that free software is impervious to exploits, and into the reality that vulnerabilities are acknowleged and patched faster in most free software projects. Gentlemen, synchronize your watches. Will the Firefox team have a fix out before Microsoft even admits it's a bug?
The links to Citibank from the Secunia site are actually handled by JavaScript. The script sets a timer, then opens citibank. Every second or so, Secunia's script then checks whether you've opened Citibank's pop-up. If you have, it opens a window with the same name (i.e. variable name) as Citibank's window, thus overwriting their content.
So the attacker doesn't need you to click on anything, they just need you to have their site open -- with the timer going -- in another window. Also, the attacker needs to know in advance what name the victim site's pop-up is referenced by. A dynamically generated name could possibly defeat this attack, though the attacker could always crawl the DOM for a handle to the pop-up.
Vino, gyno, and techno -Bruce Sterling
This all boils down to a Javascript vulnerability.
If web masters would stop NEEDLESSLY using Javascript to do things like open new windows, and would use it ONLY when there is no way using HTML to accomplish the same goal, then people would not need to have Javascript active all the time, and the impact of exploits like this would be greatly reduced.
If, instead of using <a href="#" onclick="foo"> or <a href="javascript(foo)"> type constructs, web designers would use <a target="_blank" href="something.html" onclick="javascript(stuff)"> type constructs, then if the user HAS Javascript active, then the web master can micromanage the newly created window. If not, then the user STILL gets a new window, just not one that the web master can remove all the chrome from.
Seriously - when was the last time you heard of an exploit that used straight HTML? All of the recent exploits in ALL browsers, IE included, have been in either Javascript or Active-X, not in the core HTML rendering.
There is a REASON for that.
www.eFax.com are spammers
What if the page refreshes itself? Doesn't that put you in the same hole?
If so, then it's not "jumping through hoops", which makes Safari as vulnerable as any other browser.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Comment removed based on user account deletion
I don't see how this could be that big an issue either... for a site to be able to be hijacked, the pop-up it would have to be a site already sponsored by Citibank or whoever to start with.
||| I still can't believe Parkay's not butter.
Target names should only exist within the namespace of the site that created them.
Site A should be able to create and interact with a window named "popup".
Site B should be able to create and interact with a window named "popup".
This should happen without either site interfering, blocking or overwriting the other. They should simply be invisible to each other, existing in completely seperate little worlds.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Okay - it does work. I am an idiot and can't follow instructions. :)
Requires the clicking on the citibank link
Molls and trolls, molls and trolls... There is more to the web than formatted content. Dynamic websites have been a must to attract hits since 1998. Facts of life, deal with it.
Example: Sites that pop up their "main" window from their "entry tunnel." Exactly what justification do you have for thinking I still need to view your entry tunnel?
Example: (as mentioned,) sites that use Javascript to open windows. Granted, this practice came around before Opera/Mozilla introduced us to the wonders of tabbed browsing, but what's the point of pulling up a "diversionary" window and forcing the user to close it? Afraid they might not understand the concept of the "back" button?
Example: using flash/java/shockwave/etc to perform functions that could be handled in HTML, especially now that we have DHTML. I have trouble with understanding the argument "we will be more successful if we deny access to some percentage of the population."
etc etc etc.IMHO, this is a symptom of the problem where people assume "everyone else thinks / acts / behaves in the same way I do."
... useless as blink tags.
I disagree. I think they have their moments. Such as displaying incidental information without interrupting the flow of something you're already doing (say, a help link in a wizard-style sequence of pages)
like everything else, popups are a tool which can be used or misused. Unfortunately they're mostly misused.
Screw you all! I'm off to the pub
If you really want to open a pop up window, don't turn off the bloody URL bar and other assorted bits that help a user understand where they are.
It's incredibly sad that pretty much every bank I've ever used doesn't think I might like to know that I'm really talking to their server when I use their web interface.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
I was running Safari 1.2.3 (v125.9) which isn't quite the current version, but pretty close.
I can confirm this works when the "Block Pop-up Windows" in the Safari menu is disabled, but not when the Blocking option is enabled. Rather than just a "me too", I went through the demonstration in reverse order of the previous poster (and was careful to refresh and follow the appropriate links) so I don't think this behavior is due to caching issues.
While I do hope there will be a fix for this soon, IMHO, the more appropos fix is that secure sites should not EVER rely on popups.
Sure, it could be done in the same page but then it's an argument about whether dialog windows are a good thing, and usability tests show that they are.
Needless use is bad, but that doesn't mean it's always bad, and please don't jump on this vulnerability to continue an anti-popup bandwagon. This is a security issue, and could have existed in any topic independant of popups.
Funny enough that was the lone script permission that I still had checked because mouseovers were the one script action that I thought would be rather benign, now scripts aren't allowed to do much of anything in my browser =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Let's see how long it'll take for each browser to get a fix for this... my estimation, by tomorrow Firefox will have a fix. My estimation is that by, oh... possibly sp3 or loghorn (or possibly never) IE will have a fix for this.
I'm not anti-microsoft. I'm anti-bullshit. Which means I'm anti-microsoft.
All these damned Secunia bugs are basically human error bugs anyway. If you know what's in the popup, it's impossible to be spoofed - if the URL bar shows a site that's not what you expect, close it.
In general, it's always going to be possible if you are browsing sketchy and secure sites at the same time that the sketchy site might pop up some deceptive window, and if you are confused, and can't see the URL bar, you might think it came from the secure site, with or without this specific injection issue. Which is why this workaround out to be default behavior anyway (I HATE sites that try to hide my location bar and navigation toolbar, those bastards).
Anyway, the point is, yes the issue should be fixed, but if you applied the workaround, it makes the exploit essentially worthless to an adversary.
"Features" provided by Javascript fall into a very few categories, so far as I can tell:
- Client-side verification
- Eye-Candy
- Replacing standard HTML functionality
Essentially, the categories are "Don't Do", "Don't need", and "Redundant".This includes validating that all the fields in a form are filled in, as well as checking that the user entered the correct password. Naturally, this is the silliest reason to require Javascript, as the validation step still has to be done on the server side anyway, making the client-side validation a redundant convenience at best, and an addle-brained sign of utter incompetence at worst.
This includes dynamic "feedback", drop-down menus, etc. None of this is what you can call "essential", even if it's very nice and garners rave reviews from the average user.
This includes opening new windows/tabs, following links, submitting forms, and suchlike. This is perhaps the most aggravating reason to require javascript, as it artifically narrows the potential user community of the website.
However, I think it's almost a lost cause.
I think the only way we're going to convince webmasters to think twice about Javascript is to build a runtime debugger/replacement tool into the Javascript VMs in our browsers. Let the user specify wholesale replacement of javascript fragments (e.g. remove the open-window-in-a-popup portion of a tag and replace it with a good old-fashioned anchor tag) and changing of values in the running script (e.g. let's just change that discount from 5% to 95%).
It's my computer after all, and I should get a say in what programs run on my computer, no?
Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)
Malicious site? All you need is to compromise or hijack (DNS etc) the relevant banner ad site or partner site.
Has happened before.
Users may still have to click something, but they could easily be tricked into doing that. Most users aren't constantly vigilant and observant. If the compromised banner ad opened another window that looked like Citibank's site whilst you were using Citibank's site, you could fall for it - especially since Citibank does use pop-ups.
As far as I understand the issue, this same exploit is more a blind spot in the HTML / Javascript model that a browser issue. The same kind of trick could be used with frames which bear a "name" too: has it been alreday dealt with? Is a website allowed to load a page in a frame that has been provided by another site, provided it guess the correct name of that frame?
- if "yes", then there is a vulnerability with frames and iframes too, using the same trick, and popup blocking will not solve it.
- if "no" -for instance if frames and iframes that are already dispayed can only be javascript-relaoaded by the same server or domain that had generated them in the first place- then lets proceed in the same way with popup windows. This has been suggested elsewhere in this discussion.
But the real solution lies with the sites developpers: if one wants to develop a truly secure site with popup or frames, one has to produce unpredictable names for any "target" and urls by dynamically generating random frame names and maintaining them throughout the user's session, and use SSL to transmit the whole thing.
Quite a pain for web developpers isn't it? The other way to do it is to avoid complicated things like frames and popups so that there can be no doubts about the page origin. A least not in Firefox...
I am not Remy Mouton, unfortunately: http://remy.mouton.free.fr/art/
Some little JavaScript projects I have done:
- Tic-Tac-Toe - Responsive, looks good, has AI, works in a web browser. The alternatives would be CGI or Flash. I've played CGI tic-tac-toe and it is too slow. Flash seems like overkill
- Scientific Calculator - The bread and butter of Javascript, perform calculations in a web page. I tend to like this calculator better than the Windows calculator because of the free form text entry
- Currency Exchange Rate Conversion Calculator - Again the alternative is CGI but again it is slow. Plus, do you want to send your financial data (amounts you are converting) to some random website? This keeps all your data on the client side.
- At work we are working on page that shows new data as it is available. Sure you can refresh the page and see the latest, but a bit of javscript to pull new data off the server is both easier for most users and saves bandwidth because it can get just the stuff that is changed and put it into the page in the appropriate place.
I grant that javascript is often misused and I fully support your desire for a whitelist. Thankfully, there is a noscript tag so I can tell people like you exactly what you are missing and you will consider adding my page to your whitelist. But please don't beat me!javascript sucks and it should be disabled. If most boycot javascript, sites will stop using it.
Look for the target attribute and the "L" flag in the 6th column of the attributes section of the HTML 4 spec. This means it is only allowed in the HTML 4 Loose DTD, not in the Strict DTD. The original poster was right, you are wrong.
I tried this on Firefox 1.0 on Win XP and you are correct. If you open the Citibank page in a new window, you are vulnerable; if you open it in a new tab, you are not. This is potentially important info to provide the FF team so that they can fix the bug quickly.
The link for browsers with pop-up blockers does not affect my pop-up blocking Firefox (and a window pops open saying that I have no pop-up blocking), but the other link does indeed spoof the window. I'm not worried about the problem though, because I don't engage in such unsecure behaviour. An easy fix would be for Firefox to allow us to selectively allow java/javascript on a per-site basis (just like pop-ups and ads (with adblock)).
Nothing to see here. Move along.
Client-side verification This includes validating that all the fields in a form are filled in, as well as checking that the user entered the correct password. Naturally, this is the silliest reason to require Javascript, as the validation step still has to be done on the server side anyway, making the client-side validation a redundant convenience at best, and an addle-brained sign of utter incompetence at worst.
Just what I want.. a user posting 300 times before realizing that, yes, they must fill out the form. Think about something like Yahoo mail. I can go into a new message and if I forget to put in a To:, it will still post to the server and come back and say that I'm a moron. With JS verification, I would know instantly.
Obviously client-side verification shouldn't be used for passwords, but checking that a form is at least completely filled out is very helpful, both as a designer and a web user. Client side verification is practically instant and does not burden the server with incomplete requests. Of course, client side verification does not exempt you from having to perform server side verification.
In FireFox if you open the window in a new tab, create a new window manually and goto the url, type in the url manually, or go via a bookmark, your safe. In other words, very very unlikely this we'll see any wide scale usage of this bug.