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?
Jimmy writes "Secunia is reported about a new vulnerability"
And in other news, Slashdot is reported all about a new grammatical error in the headlines.
Reporting anyone?
Indy Media Watch-Proctologist of the Internet
I opened Secunia, Then open another browser window to Citibank via Ctrl+N, and click on Citybank's Consumer Alert button, nothing happened.
But if I used the link from Secunia to access Citybank, the Popup is then hijacked.
So it seems like you need to access (click on a link to) your trusted site via an untrusted site to get hijacked?
Rock that crushes, Paper & Scissors that don't matter.
mac os x 10.3.6... running safari 1.2.4 (the latest build.)
The exploit worked for me (FF1.0 win2k). I clicked on the "with popup" link, FF blocked a popup, but a new window spawned with Citibank. I clicked on the link I was told to, and up came the 2nd hijacked popup.
"Einstein argued that [...] God is not capricious or arbitrary. No such faith comforts the software engineer." ~ Brooks
the demo come up blank. all i see is a window called (Untitled) (and the globe spins then dies)
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.
Did you actually follow the instructions? That is: Did you click on the image on the citibank-page, thereby giving you a third window? It doesn't sound like it from your comment.
And the exploit worked just 'fine' on my firefox 1.0.
You must be new here.
File under 'M' for 'Manic ranting'
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.
I just don't believe it. Anything -- even an exploit -- working in all browsers would be unprecedented!
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?
The exploit worked for me on Firefox 1.0 on Windows 98 SE with pop-up blocking turned off, but the exploit didn't work for me when pop-up blocking was turned on.
This only worked for me when I left-clicked, like they said. I'm so used to FireFox now that it was second nature for me to open the Citibank site in a new tab, and the exploit failed to work then.
--- Bwah?
Comment removed based on user account deletion
i did it using safari, got citibank, i have no account but was able to transfer $100 million into an offshore account. That was some test
Anyone seen my jagged little pill?
The fact that everyone is confused is an indication that their instructions suck. "Step one" is click on a link in the citibank site that you haven't visited yet. "Step two" is actually visiting the citibank site. And then "step three" is a no-op; the space for that step is instead used to discuss whether you are vulnerable. (Presumably, step five is "profit!!!"). Who came up with this and what planet are they from where this is a logical sequence of instructions?
I'd rather be lucky than good.
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
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
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.
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
Using Firefox 1.0.
I followed the appropriate links allowing cookies to be placed by citibank. The window was indeed hijacked.
I then followed the same links but this time not allowing citibank to place any cookies. The window was not hi-jacked.
Be aware of what/who is placing cookies on your machine!
I just don't believe it. Anything -- even an exploit -- working in all browsers would be unprecedented!
Lynx appears to be unaffected.
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
The spoof worked for me on FF 1.0 on W2K. One more reason to use the Spoofstick browser plugin for FF or IE. It clearly showed the popup originated from secunia.com and not Citibank.
Bad boys rape our young girls but Violet gives willingly.
Comment removed based on user account deletion
I hope this helps the vast masses of smart
Seems to be in bugzilla.mozilla.org as defect 273699. (Direct link wouldn't work anyway.)
Comment removed based on user account deletion
Opera 7.11 on WIN2000 (older version, it's what i have at work) opens the CTI site and the spoof in separate windows, with or without popup disabler. I have to check it with newer versions though, i will when i get home.
My lynx browsing is totally unaffected.
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]
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."
Ahhhhh, so if you follow the instructions perfectly it might work. If you have multiple windows open, it won't work. Does this mean their vulnerability has a vulnerability?
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.
... 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
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
LOL! I suppose I should change my /. password now, just in case Secunia's proof of concept had a more-than-friendly bit of code in it.
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
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
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!
when it takes Slashdotters 5 minutes and other people's help to activate it...
Just an interesting note - if I left click on secunia's test page, and secunia opens citibank in a new tab, the exploit works.
If I middleclick on the test page and *force* firefox to open the site in a new tab, the exploit fails.
I don't know enough to now if this is a limitation in the exploit or in how they've written the exploit, but it's odd and interesting
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
My fix is a little easier (in my opinion, only because I hate having another toolbar taking up desktop real estate)...
under about:config, I have dom.disable_window_open_feature.location set to true. So every window must show the location (and because of it, I immediately could see the webpage I was at was not citibank.com).
Sig!
http://docs.info.apple.com/article.html?artnum=617 98/
"Safari
Available for: Mac OS X v10.3.6, Mac OS X Server v10.3.6, Mac OS X v10.2.8, Mac OS X Server v10.2.8
CVE-ID: CAN-2004-1122
Impact: With multiple browser windows active Safari users could be mislead about which window activated a pop-up window.
Description: When multiple Safari windows are open, a carefully timed pop-up could mislead a user into thinking it was activated by a different site. In this update Safari now places a window that activates a pop-up in front of all other browser windows. Credit to Secunia Research for reporting this issue."
I think it affects everyone who has javascript on and follows the instructions *exactly.* It's a very fragile one.
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.
Or just set firefox to always show the URL // Always display the Navigation Toolbar in pop-up windows:u re.locatio n", true);
user_pref("dom.disable_window_open_feat
as per the tips and tricks pageg
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
Yeah, this is the first thing that came into my mind as I read slashdot in lynx, however, I wasn't able to log in to post. So, the tradeoff is there: being immune to some silly vulenerability, or having a completely functional browser. Take your pick..
OK, I've read through a bunch of Slashdot posts, and I've considered my experience with this thing, and here's my web developer's opinion of this "vulnerability":
;)
In Javascript, if (and only if) your web page opens a new window, it "owns" that window. In other words, you have access to the whole DOM in that window. You can step through the document object, alter things, and so forth. This is how things are supposed to work; it's what enables us to open new windows and interact with the user. For example, maybe you want to pop up a window, ask a couple of questions, get the results, and close the window. Something I did recently at work was code an informational popup this way, because we had to kind of shock the user a little, to prevent them from just clicking "OK" to close all the alerts we were sending them. We made the popup very pretty and noticeable. OK?
So, the guys at Secunia decided that was a vulnerability and they set up this little test to scare everybody. So...
IF you went to a crooked website, and IF you clicked a link to pop up a site like Citibanks FROM THE CROOKED WEBSITE, and IF you went about your business on Citibank's site and clicked their crooked CSS overlay or popup (or whatever, you can probably do it in a couple of ways) THEN and ONLY THEN would you be sent to a crooked popup window with which they could phish you.
In other words, in order to really make use of this, a phisher would have to:
1. Get his code onto an actual commercial website so that people would find it and unsuspectingly click a banking link;
2. Evade capture for long enough to collect a bunch of credit card numbers (or whatever), with the commercial site's security team coming after him with knives sharpened;
3. Avoid having the crooked popup's web URL or IP address traced back to him by the FBI or Interpol within a day or so;
4. Figure out a way around the bank (or whatever) putting a huge banner on their site saying in bright red flashing letters "DO NOT APPROACH THIS SITE VIA A WEB LINK! TYPE THE SITE ADDRESS IN YOU SCHMUCK!" (or just putting a parent.close(); line of code in their existing Javascript, plus some code to refresh the page from the bank's server, clearing out anything from the crooked site -- would this work? I haven't tested it yet -- but I'm sure there are other ways to do it and the bank's developers are smarter than phishers, generally).
BUT, even if the phisher DOES figure all this out, it won't do him any good, because
WHEN PEOPLE GO TO THEIR BANK'S WEBSITE, THEY USUALLY JUST TYPE IN THE URL OR USE A BOOKMARK!
So, in short, I think this is nothing much to worry about.
Discuss!
Farewell! It's been a fine buncha years!
Mosaic v1.0 users are also reportedly not affected. Nevertheless, experts strongly encourage Mosaic users to upgrade anyways.
-- listen to interesting music, support independent radio... WPRB
I think there is an easy fix for this. Basically the exploit is based on the fact that you can use javascript to open a window with the target the same as another window and overwrite the other ones content.
Well, why not make a new rule in javascript that would disallow any javascript code to access any popups that aren't a direct child of the current instance of the browser.
Basically what i mean is to have each window in it's own namespace and have the child window share said namespace. (I think one would have to not allow grandparents to access it either though).
so basically if two seperate windows open a window with target="name" then 2 windows are opened one for each instance and they have nothing to do with each other.
proxy
"Firefox has prevented this site from opening 1632 pop-up windows. Click here for options..."
...And now 2000... persistent little bugger...
And this is a version of Firefox I installed approximately two weeks ago.
The Penguin Producer
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.
All browsers? Can someone tell me how to get this to work on Lynx?
LedgerSMB: Open source Accounting/ERP
Seriously, a 'vulnerability' in the 'oh shit!' sense of the phrase is "an opening by which an innocent user could get fscked by no fault of their own".
This strikes me as about as dangerous as the post-SP2 "Warning! If you copy and paste shit files from the net and click a few boxes, YOU COULD GET SPYWARE!".
For the record, I just nuked and reinstalled XP-Sp2 + hotfixes a few days ago (for once, not because it was fucked up, but my new raid0 array), so I have cherry IE6 and unextensioned-FireFox 1.
I tried several variations of the convoluted instructions, and could get no explicitly dangerous behavior. Mozilla didn't bat an eye, and IE once popped up a box saying "The script is trying to close this window, do you want to let it?" If I let it, then it opened the Citibank site in the window again.
Oooh, scary.
I'm sure there may be some actual, dangerous vulnerability here somewhere. But I've gotten better instructions from the japanese ASUS site, translated through google.
If I knew the wedgies I gave you back in 6th grade would have resulted in this . . . I might have taken a moments pause.
Javascript is the work of the devil. Leave it off unless you have a damn good reason to turn it on. Why give anyone that much control over your computer just to surf the web?
For firefox or opera just turn it on when you absolutely need it and never forget to turn it off right away when you are done. For IE make use of the security zones to implement javascript whitelisting. That's what I do because with firefox and opera I often don't remember to turn it off again until I start getting annoying popups or worse.
Seems like more than half of these vulnerabilities that keep popping up make use of javascript. That last one with the online banking passwords was pretty scary and made me very glad that I browse with javascript off.
Quite an experience to live in fear, isn't it? That's what it is to be a slave.
feel sorry for citybank's webserver?
Ignorance kills, complacency kills, hatred kills, but usually not the ones guilty of them.
Rumor has it, patches to support this exploit in Lynx will be available by the end of the week. ;)
It didn't seem to work under Lynx... I don't really use that browser, but I'm just saying it doesn't affect ALL browsers.
A month or two ago smile.co.uk swapepd their system from using a popup to using the current browser window. Thbey have won numerous awards for security (not to mention customer service) in the UK. They told customers this change was to ensure greater security. Looks like they are one step ahead of such vulnerabilities again, unlike citibank or many others.
just another reason to switch to http://www.smile.co.uk/
I dont work there, just a very happy customer.
DRM-free indie games for the PC and Mac: Positech Games
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.
"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!)
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.
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/
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.
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!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.
"I assert that no essential behavior on a web-page requires Javascript -- it's ALL needless."
There you go. You've just shown your ignorance. For simple web pages I would agree, but this vulnerablility is for, and demonstrated in, a web application.
As other posters have pointed out, you cannot get some features of an application without using Javascript.
So, until the world starts using something like Webstart and downloadable, secure thick clients via the web, the browser is all that we have. Perhaps this vulnerability will be fixed at the browser level so that the needed use of Javascript can be made safer.
Can you provide an alternative that will allow these rich client features in a UI available over the web?
Come on, we're waiting...
'Insightful' my ass....
Never by hatred has hatred been appeased, only by kindness - the Buddha
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
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.
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.
That email I got about having extra security by making sure 1337hax0rz.ru was loaded in a separate window while using my bank's website was a lie? Maybe that is why my bank keeps asking me to give them my information again. How many times can they loose my account number and SSN?
SIGFAULT
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.