Major IE8 Flaw Makes "Safe" Sites Unsafe
After this weekend's report of a dangerous flaw in IE (which Microsoft confirmed today), intrudere points out an exclusive report in The Register on a new hole in IE8 that could allow an attacker to pull off cross-site scripting attacks on Web sites that ought, by rights, to be safe from XSS. This is according to two anonymous sources, who told El Reg that Microsoft had been notified of the vulnerability a few months ago.
IE8 is compatible with sites designed for IE6. You won't see other browsers going the extra mile like this.
Oh my gosh! Internet explorer is not safe to use? This is incredible hot, breaking news to me.
Rain is wet....
Despite MS best efforts, IE just won't shake it's 'insecure' tag, will it?
Part of me wonders if perhaps these vulnerabilities aren't being made a big deal of because of the reputation of IE6. The rest of me which started using Firefox a long time ago just feels smug and superior.
So there I was, scribbling down some notes off the PC screen by hand, when I reached for the keyboard and Ctrl-S'd.
"IE8 Flaw" is, in and of itself, a redundancy.
This ain't rocket surgery.
If it is anything like IE 5.2 for Mac, then very few sites will work in it anyway. I am aware that it isn't exactly the same as the Windows version, it does support the <q> tag for example, whereas the Windows version doesn't.
The exploit currently doing the rounds is not particularly stable and often just causes the browser to crash.
I doesn't sound like much of a threat and if anything, folks may think it's a bug and move to IE 8 or to another browser all together - solving the problem without installing any fixes.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
... run injected code.
Damn! Code injection! Is that like Fuel Injection? So, I'll get better performance and speed from it?
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
Looks like you went to the wrong article.
http://dilbert.com/2010-12-13
You got it! It's Microsoft's version to Opera Unite! And to think they had it all along...
http://dilbert.com/2010-12-13
Please go to the "a new hole in IE8" article.
And if you're looking for the article to *read* it... yes, you are new here.
Except, that was the FIRST security flaw linked in the article. The SECOND one (at The Register) is about a different security flaw, in the XSS filter. The XSS filter is new in IE8.
And, BTW, Google does indeed disable it so that they are not vulnerable to the flaw: their servers send a "X-XSS-Protection: 0" header.
It seems to me that if the IE team is capable of telling that a combination of features is potentially dangerous, then why would they edit the source of the page to avoid triggering the vulnerability, rather than actually eliminating the vulnerability being attacked?
Again, that's "Interfect Exploder". Remember to ask for it by name!
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
A New IE8 security feature... bug.... feature.... bug..... feature.... bug...... feature....bug.
When asked why they are disabling the XSS protection in IE8, Google responds that IE8 has a undiclosed vulnerability. Anyone here think Google is just mud-slinging to disparrage the main competitor to Chrome?
No
Maybe Taco & co. aren't adding 'coolforsale' to the lameness filters thinking they'll start some kind of escalating spam war?
Otherwise I don't know why the hell they don't just do it already.
It reminds me of those sub-literate bots you see on Warcraft trade channel. My finger itches to right-click report spam it.
"Friends don't let friends use Microsoft products without the services of a lawyer"
or was it, "in Soviet Redmond, browser uses you"?
MS thought they were being safe, like replacing single quotes with double before making an INSERT statement for a database, or removing less-than or greater than characters to prevent someone embedding <script> tags everywhere.
Someone is pre-formatting the data so that when it is re-written, it becomes dangerous. In other words, this is like EVERY OTHER VULNERABILITY EVER. Someone makes a feature, doesn't think it through completely, and either leaves a hole, bypass, or unintended consequence.
When the hell did "cool" become a noun anyway? That bothers the hell out of me.
Ride the skies
Or they do it because XSS screws up their ad-revenue system.
That doesn't really make sense; if XSS is screws up their system, why disable IE's protection for it? The only reason must be that the XSS protection is flawed.
MS thought they were being safe, like replacing single quotes with double before making an INSERT statement for a database, or removing less-than or greater than characters to prevent someone embedding tags everywhere.
I understand what they were trying to do. It's like every idiot web designer who manages to make it impossible for people named "d'Agostino" (or for that matter "da Silva") to register at their web site. This whole approach has been known to be made of 100% undiluted organic FAIL for a decade. There is no lolcat facepalm epic enough for this.
Even without the security problem, I would disable XSS protection on my sites. If I've made a mistake and let an HTML-injection flaw in my app, chances are it'll still be vulnerable (since IE8's XSS protection is a pathetic string-hack on the HTML source which is insufficient to protect against anything but the most basic of attacks), so IE8 is offering only to obfuscate and not fix my problems.
Meanwhile if I allow XSS “protection”, I have a problem when someone legitimately uses a term in the query string that appears in the page and looks to IE like it might be dangerous. This is easy to do: just searching for ‘<style>’ will often break the CSS of the search results page.
Not only that, but I'm also open to deliberate sabotage when an attacker looks at my source, finds some script they don't like, and puts it in the query string so that IE8 doesn't execute it. Certainly this can be used to deliberately disable things like frame-buster scripts, to get around redress attack protections. It is presumably a form of this deliberate attack crafting that leads to whatever the undisclosed vulnerability is.
So no, I don't think Google are wrong. IE8's XSS protection is utterly, utterly bogus. It adds only more complication and more problems to webmasters' lot and no real effective security.
If their ad tech relies on XSS, and IE successfully blocks XSS on google, then disabling it would allow googles ad tech to work again. Not that hard, really..
That doesn't make sense:
1. Google serves all ads within Google.com from that same domain. No cross-site scripting anywhere, so nothing for the XSS filter to block.
2. For external sites (AdSense), disabling the XSS filter on Google.com won't help either: the external site would have to disable it. Otherwise anyone could just disable the XSS filter on their own domain and hack away on other sites.