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"
I am running Firefox 1.0. I tried the link that said 'With Pop-up Blocker', and it displayed a dialog saying that I did not have a pop-up blocker.
I refreshed the page, and tried the link that said 'Without Pop-up Blocker'. It opened up the Citibank website, but it did not hijack my Citibank popup window.
Same thing happened to me under IE6 (except I did not get the dialog when I clicked on the 'With Pop-up Blocker' link).
Maybe it works under certain circumstances, but I couldn't reproduce it.
mac os x 10.3.6... running safari 1.2.4 (the latest build.)
I tried the test in Safari 1.2.4 under Mac OS X 10.3.6. I had pop-ups blocked, the normal way I set my browser. Doing the test, I saw the Citibank site fine. When I clicked on the "Consumer Alert" button, it looked like the regular Citibank content. No problem there. I refreshed and clicked on the other "try this test" link, and there still was no problem.
When I turned off the pop-up blocking feature, then when I tried the test, I did see a pop-up from the Secunia site instead of the Citibank text. Now that's a problem.
Clearly, this is just another reason to block pop-up windows.
Insert simplistic political, ideological, or personal proselytization here.
Of course, this also means that a huge amount of programmers can look at the code to find a bug to write a patch to release it to the public.
The bottom line: I switched everyone I know to Firefox nearly six months ago, and haven't had to do a single Malware clean yet.
UTF-8: There and Back Again
I reproduced this successfully on Firefox 1.0 under Linux.
Well, it didn't affect irider, which is IE-based, presumably because it opens popups in its own (excellent) 'tree-tab' system.
It's a vulnerability, but it's the correct behaviour. Browsers should open the window in the target pop-up window, even if the page opening the page does not own that window, as I recall. As they say, that's no bug...
Since when has this country used intellectual elite as a pejorative term?
Comment removed based on user account deletion
The first since 1.0 maybe, but certainly not the first outright.
As far as I can tell the problem is fixed in the latest Opera beta so they might be able to get it into a proper release pretty soon too.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Actually it does effect Safari, but you have to jump through hoops to get it to work.
After you have clicked on the link, you have to refresh the Secunia page, then it will work. It's kinda strange, but I guess it is a vulnerability. Kinda like walking back and forth through a bad neighborhood while counting your cash.
NarratorDan
"If you're not confused by quantum mechanics, you really don't understand it." - Niels Bohr
Funny, I've tried this in Internet Explorer 6.0 and Mozilla 1.7, but I could only get it to "work" in Mozilla.
In Internet Explorer I pressed "With popup-blocker" (Google Toolbar) and up came Citibank, then I pressed the Fraudulent E-Mail button, and up came CitiBanks popupwindow, first when I closed the popupwindow the "This was hijacked" window appeared (as if triggered by the window.onclose function) but that does not strike me as a gigantic security-hole.
Of course the issue in itself is scary, but I'm confident the Mozilla team will have a patch out in no time.
This should probably serve as a reminder to webmasters out there, that if you want users to trust content you provide in popup-windows eg. for creditcard payments, you should provide the address-bar, and if the creditcard processing takes place on another server, explain to the customer before he clicks "pay by creditcard" why the window will load from another server.
My <1000 UID is with a hot chick
FF 1.0 on Win2K.
Middle-click to open citibank page in new tab YOU WILL NOT BE VULNERABLE.
Left click and allow citibank page to open in new window YOU WILL BE VULNERABLE.
At least, that's the behaviour I see on this box.
Comment removed based on user account deletion
Seems to be in bugzilla.mozilla.org as defect 273699. (Direct link wouldn't work anyway.)
Comment removed based on user account deletion
User error.
Shoot, Secunia's making a big deal about this, and I guess maybe people need to be reminded from time to time, but it's like Secunia says --
Don't go to your bank with a hitchhiker. Shut your stupid browser down before you get out your passwords, account numbers, etc. Close every browser window. Then open a fresh, blank window and proceed.
(Which is one reason there should be no default page setting for a browser.)
Expecting your browser to sandbox every browser window separately is a little like expecting Superman to escort you through the projects every time you go for a walk over lunch. Browsers and OSses on desktops have not even begun to approach the paradigms necessary for that kind of protection, and it's questionable whether the average user could remember whatever protocol could be invented anyway.
Just shut your browser completely down before you go to a secured site.
According to MozillaNews the following work around can be applied to Mozilla/Firefox:
1. Enter about:config in the Location Bar.
2. Enter dom.disable_window_open_feature.location in the filter field.
3. Right-click (Ctrl+click on Mac OS) the preference option and choose Toggle (the value should change to true).
This issue is already being worked on bug 273699 (copy link location, paste) filed a few hours ago.
As a side note, being able to see the bug fixing progress unfold is one of the many reasons why i love open source. I am able to learn so much from just seeing the process take place from start to finish, how it is reported, test cases created, problems that arise, insights into other parts of the system, who the people involved are, reviews, patches, etc.
[alk]
AFAICT, the 'window' object is defacto (Netscape) standard and was never standardized by the W3C.
Traditionally, windows weren't private to sites, but this is just a variation of the "cross-frame scripting" bugs that have been patched over time.
Whenever I hear the word 'Innovation', I reach for my pistol.
Well since the target attribute of the anchor link is not part of the XHTML 1.1 Strict standard, web developers who *are* actually concerned about standards are required to use Javascript to perform the pop-up behavior. By using standards-based design and manipulating the DOM via Javascript, we can accomplish anything. No need for clunky the "onclick" or even the outdated "target" attributes.
Except that it would be easy to exploit this. Here's an example:
1) Send out a phishing expedition, asking people to log into their BofA account to update their account information. Make it look real official, and include a link that goes to "https://www.bankofamerica.com". The new window takes them to the real site, encrypted and everything.
2) Customers login and check their mailing address, or whatever.
3) Some percentage of them will leave their windows open for more than 10 minutes, at which point BofA sends their standard pop-up window warning about account inactivity and logout.
4) Hijack the pop-up window and do Something Nefarious, like initiate a funds transfer.
Now, this isn't a perfect example. But there are an untold number of different sites out there who use pop-ups for perfectly reasonable applications, and it would be trivial for some phisher to get people to go to those sites using his link.
The best thing to do is, for those sites who use pop-ups to communicate with their visitors, use some nonstandard form for naming those windows. Use the person's username, a random string, a DES hash with the first two characters of the day of the week as the salt and the time the page is first loaded as the string, whatever (no, don't use "whatever", that's just a figure of speech)'
God invented whiskey so the Irish would not rule the world.
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.
Sorry, this is incorrect. For better or worse, according to the W3C, opening windows via JavaScript is the only proper way to create new windows. In fact, the target attribute has been removed from standard HTML since at least HTML 4.01 strict.
If you remove the target="_blank" from your second example, you'd actually be doing it right. In this case -as you said- the user would get to the new link regardless. If they had JavaScript turned on, they would get whatever niceness the web developer wanted. If not, they would just get the raw page.
David
That's why I use iFrame popup instead of window popups. With popup blockers already appearing built into browsers, I'm assuming that they will be standard everywhere soon.
With scripting, you can make iFrames draggable, closeable and behave and look just like regular windows but they are, in essence, windows within a window and are tied closely to the current browser.
There are reasons to have popups like, for example, color or date pickers (with a calendar). It is actually much easier to build a draggable DIV than a draggable iFrame but the draggable DIV doesn't show up on top of certain HTML elements and hence becomes useless (even with an infinitely high z-index).
By the way, you can get draggable iFrames to work in both MSIE and Mozilla. I just bought my iMac for testing but I'm pretty sure I can get it to work in the mac versions too as they all have the necessary language and DHTML components. All I can say though is that JavaScript and DHTML are definitely vendor dependant, and I don't care if you are mozilla or Apple or Microsoft, they ALL have quirks and bugs that go outside of the specifications. In many ways, my high speed photoshop-style image scripting program (for use on web servers) was easier to write in C# than trying to figure out how to make things work across every browser out there!
Anyways, programmer alert. I wouldn't depend on popups working in the future if your app depends on it. Make sure to use iFrames or have a non popup dependant way of doing the same thing!
Sunny
Be my Friend
My system:
Slackware 10, Konqueror, and Mozilla 1.7.3.
Results with Konqueror: the popup did NOT point back at Secunia, it pointed at Citibank. Perhaps this is because I have Konqueror configured to open new windows in tabs and have "smart" popup blocking enabled. Would someone try and confirm this? If it is the issue, then we can block the vulnerability in Konqueror, at least.
In Mozilla, the popup trick worked. Bad Mozilla!
FYI
Farewell! It's been a fine buncha years!
You've got to think about accessability when making links, imagine Javascript turned off. Does it still work? Imagine using a screen reader, can it follow the link? The HREF should be a valid URL to the page you are trying to display, if Javascript is turned on, you override the behavior by attaching an event to the anchor in question.
This excellent article on ALA should answer any pending questions on the issue.
BTW, the target attribute of anchors was dropped between XHTML 1.1 Transitional and XHTML 1.1 Strict.
1. 'target' is certainly part of standard html.
http://www.w3.org/TR/html4/present/frames.html#ad
Just because it isn't defined initially by the A tag doesn't mean the A tag can't use it.
2. From http://www.w3.org/TR/html4/types.html#type-frame-
PS. Hey mods, if you don't know about a subject, don't mark a post 'informative' just because there's a link in it.
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
I don't know about broken, I've never looked at it in that way. For me, the standards are perfectly clear and separate content (XHTML) from presentation (CSS) from user-interactive (DOM). If you take a webpage that's written to the Strict spec, and render the HTML at the simplest level (text-based) you have a perfectly legible webpage by any browser/user. I don't see how that could have been possible without the work of the W3C and the current XHTML 1.1 Strict specification.
Javascript is here to stay, I don't agree that using Javascript in itself is a problem or a vulnerability. Allowing Javascript to alter the DOM of a website at a different domain name than the site the Javascript is running on *is* a problem.
*BZZZZZZT*
XHTML1.1/Strict does not have the target attribute, though. (Download the DTDs and grep for "target", it's not there)
XFRAMES must be something new. I've read that they were going to completely remove the target attribute from (X)HTML as you can create "frame"-effects with CSS and "position: fixed".
Ah well, I'll continue to use my non-existant-target removing javascript parsing popup-rewriting proxy (onclick -> proper href) (NETRJPP).
(Yes I am completely aware of the fact that "position: fixed" does not work in IE, and that using it results in very slow scrolling in Firefox. Thank you very much.)
Alert!: Unsupported URL scheme!
Now, from where did the "affects all browsers" come? Not the Secunia site, AFAICT, did the slashdot editors add that one? Things are really going downwards if even people on slashdot don't know that there are other browsers than IE and Netscape.
Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.
As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.
I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.
And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.
The "target" attribute still exists in the Transitional and Frameset versions of HTML 4.01 and XHTML 1.0. XHTML 1.1 does not have a Transitional or a Frameset version; however, it is a modularization of XHTML which means that the same functionality can be easily re-introduced. For example, Jacques Distler has produced a page using the "target" attribute which is valid against an extended XHTML 1.1 DTD. This is one of the major selling points of XML-based markup and having true XML parsers as clients.
The exploit did work on my FireFox 1.0, and I have always had all those checkboxes except "Change Images" disabled.
I would like to disable JavaScript entirely, but unfortunately that breaks too many pages.
I tried this, and it didn't work. Then I realised what they were actually wanting. Open the citbank window, then click on the genuine link in the citibank window (pictured in the site) and if the window opens and shows citibank stuff you're ok, if it opens and then immediatly written over with their data, you're vunerable.
I did this, and Firefox 1.0 (linux) was vunerable. The site wasn't clear that the first site wasn't the vunerability, but links from a genuine site can be made vunerable.
Of course, you have to visit one of thse sites, and then go to the other.. so you have to be fooled by the malware site into it first.
Are you sure you actually clicked on the 'Consumer Alert' image on the citibank site? The popup blocker isn't meant to stop it. A popup comes up when you click on the image and 'You are vulnerable, if [it] showed text from Secunia and not from CitiBank.'
I looked at the DOM spec (levels 1 and 2) and there's no Window object; ECMAScript mentions that the Window object may exist but not what it does (since it's part of the runtime environment rather than the base language).
I did find this:
Referring to windows and frames from the Netscape JavaScript handbook. It says nothing about window names being private.
So, pin this one on Netscape, and the lack of any formal open standard for what happens in a browser outside of the document.
Let's see you build something as responsive, usable and practical as GMail without using Javascript.
OK, let's try something easier. I've got a table with many rows where each row contains two sets of radio buttons. When one of the radio buttons in the first set is selected, you shouldn't select an answer in the second set. Thus, I use Javascript to disable the second set of radio buttons when that particular option is chosen. Care to tell me how to do that using regular HTML?
Safari appears to be OK, as long as 'block pop-up Windows' is selected in preferences. ... So it is vulnerable by default, sadly.
Also this doesn't work if you use tabbed browsing. If you open the link in a new tab and then click the button you get the citibank popup, not the infected one. It only seemed to work if you opened their link in a new window.
I'm also confident that this will be fixed soon but it's also not really a big issue for me because I do mostly tabbed browsing. It is very rarely that I open a new site in a seperate window anymore.
He specifically said html 4.01 strict, not html 4 transitional....
In strict, frames and target= are depricated
And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
You probably clicked the wrong link, you should click the one that says.
With Pop-up Blocker:
Test Now - With Pop-up Blocker - Left Click On This Link
Either that or you have a very aggressive popup-blocker.
It looks like some people are at risk and some are not. Reading through the comments people swear their browsers are not affected...
But I ran the tests, and here are my results:
Mac OSX 10.3.6
Safari 1.2.4 (v125.12) - Not affected according to test.
FireFox 1.0 (G4 optimized build) - Affected according to test
Camino 0.8.2+ - Affected according to test
All browsers have pop-up blocking enabled, and some sort of ad filtering (Pith Helmet, Ad Block, etc).
Your mileage WILL vary.
Or you're running through a proxy. I don't get the error in in Konqueror, Safari, or Firefox when I connect via my squid proxy. I do get the hijacked screen when I do not.
BTW Javascript has nothing to do with Java except the name.