It appears that where rendering broken HTML is concerned, IE outperforms most so-called secure browsers:
http://www.securityfocus.com/archive/1/378632
-
-
And this is good how? All it shows is that IE works around malformed HTML when it should in fact fail to render it. That throwaway about "so-called secure browsers" is also misleading. From the scant information the author of the report includes he doesn't indicate that any of the browsers tested disclosed any data or exposed any exploitable holes so, at the end of the day, they remain secure. All in all this comes across as trolling...
-
Okay, perhaps the wording "so-called secure" was poorly chosen.
But, while its a good thing that IE renders certain cases of malformed HTML or not is open for debate, the fact that Mozilla/Firefox/Netscape, Opera, and other browsers crash in response to malformed HTML is never a good thing. That's the point of the article.
It shows, as the article says, that those browsers miss a certain level of QA that apparently has been performed for MSIE. It does not make them bad browsers, or IE inherently better or more secure.
If I implied that, I certainly didn't mean to.
-
symonc wrote:And this is good how? All it shows is that IE works around malformed HTML when it should in fact fail to render it. That throwaway about "so-called secure browsers" is also misleading. From the scant information the author of the report includes he doesn't indicate that any of the browsers tested disclosed any data or exposed any exploitable holes so, at the end of the day, they remain secure. All in all this comes across as trolling...
Symon,
This is the exact same reaction many on /. had. And it shows that they don't get it.
Michal does. The reason this is important is that every one of those crashes is either:
1) A successful DoS attack against the customer
or 2) An exploitable security hole.
If it's #2, then your browser just got your computer rootkitted.
Explain to me how this is a good thing?
The non IE browser have been touting the fact that they're more secure than IE. But they failed a very basic security test - fuzzing the input.
The thing that everyone seems to miss is that the bad guys are bad guys. When you're working in the security arena, the bad guys don't CARE if the page renders correctly. The ONLY thing they care about is taking control over your machine. If they can take over your machine, then they've won.
That means that if they can make your browser crash, then they just beat you.
When you're looking at bugs from a security standpoint, correct functionality is irrelevant, what's important is ensuring that the bad guys don't get to 0wn your machine.
If you're going to talk the talk, you've got to be able to walk the walk. Michal's simply pointing out that the browsers that are claiming that they're more secure than IE clearly weren't tested with a basic security test.
-
Agreed.
This is a fundermental test and as FireFox uses Netscape's HTML rendering engine I would have thought this kind of thing should have been done at least once before..
Your browser should *never* crack while rendering HTML.
I'm not trying to dig, but I wonder if pre-SP2 IE would have done so well.. -
symonc wrote:And this is good how? All it shows is that IE works around malformed HTML when it should in fact fail to render it.
I don't think failing to render a website because of broken HTML is a valid option now. Maybe 8 or 10 years ago, but now the web is swarming with badly written pages. I want to see the information on them whether the HTML is well formed or not - on any browser.
-
It should at least try its best at rendering the HTML. Can you iamgine if each time the browser it an error it just stopped .. I think that is even against the HTML standard.
-
LarryOsterman wrote:This is the exact same reaction many on /. had
Ow, that's harsh!
I agree that the other browsers crashing is a *very* bad thing. It definitely indicates that the level of QA is far below that exerted for IE, which then inevitably leading to questions about the QA for every other aspect of that bit of software.
My comment was meant to imply that the original report (not Sven's post) misrepresented the facts with a misleading shock headline - So-called secure browsers aren't! The assumption here is that they aren't secure (reinforced by the posting on BugTraq) when in fact they are (or at least haven't been proved not to be in this case).
The fact that you can DoS a browser with bad markup is a serious issue, but not necessarily a security one (and it certainly isn't based on the information in the original report).
As for the argument about whether malformed code should be rendered or not, I think I'll leave that well alone having nailed my colours to the mast already... -
LarryOsterman wrote:This is the exact same reaction many on /. had.
Hmmm... I see this argument all the time on these boards. Is an idea bad because it's mentioned on slashdot?
-
symonc wrote:The fact that you can DoS a browser with bad markup is a serious issue, but not necessarily a security one (and it certainly isn't based on the information in the original report).
Although I can't quote exact statistics, probably the majority of major security holes are denial of service attacks. Very few are holes where an attacker can run code on someone's machine. Or is this a case of one rule for them, another rule for others? -
this is what makes IE so great.. and those "Standards" browsers a pain in the arse
standards = " your an idiot i wont display your script or page and ill bomb"
IE = "hmm - i see what you are trying to do - you obviously are not a programmer - or you are using frontpage .. Ill display what i think you MEANT. have a nice day"
example: oops you forgot to close a table somewhere
ie- no prob
standards - loading loading loading.......
-
Maurits wrote:
Hmmm... I see this argument all the time on these boards. Is an idea bad because it's mentioned on slashdot?
No, but the headline came from the /. article, and I'm assuming that's where the original reference came from.
Many of the people on /. were being VERY reasonable in their understanding of the relevance of the issue. But there were a significant number of people who seemed to believe that it was ok to crash on malformed input.
There were also a fair number of people who seemed to believe that I did the research as opposed to simply being the messenger.
-
I'd like to see a browser that has a toggle switch... to switch between strict mode (where it would display big ugly error messages on bad input) and lenient mode (where it would do a best-guess, rendering according to DWIM principles.)
I would look at sites I developed in strict mode, so as to be aware of any errors. Other browsers might handle the error differently... and I can't be sure what browser the money is using...
I might browse the web in general (sites I didn't develop) in lenient mode... or I might browse in strict mode and only switch to lenient mode if I saw a bug ugly error message... I don't know. It depends how many errors are on sites I visit frequently. -
Maurits wrote:I'd like to see a browser that has a toggle switch... to switch between strict mode (where it would display big ugly error messages on bad input) and lenient mode (where it would do a best-guess, rendering according to DWIM principles.)
I would look at sites I developed in strict mode, so as to be aware of any errors. Other browsers might handle the error differently... and I can't be sure what browser the money is using...
I might browse the web in general (sites I didn't develop) in lenient mode... or I might browse in strict mode and only switch to lenient mode if I saw a bug ugly error message... I don't know. It depends how many errors are on sites I visit frequently.
As unwise as I know it is for me to post in threads about browsers here's a link. He asked ... not my fault.
-
IE has something like this too...
(quote)
You switch on standards-compliant mode by including the !DOCTYPE declaration at the top of your document, specifying a valid Label in the declaration, and in some cases, specifying the Definition and/or URL. The Label specifies the unique name of the DTD, and can be appended with the version number of the DTD. The Definition specifies the definition of the DTD that is specified in the Label. The URL specifies the location of the DTD.
(/quote)
These switches are both set on the page, though. I'd like to see a switch in the browser... something like (radio buttons)
* Always render in standards-compliant modes
* Always render in "quirks" mode (DWIM)
* Automatically render in the appropriate mode for the page (more...) -
Maurits wrote:IE has something like this too...
Cool I've learnt something new. The closest thing I have found to what you asked for is this extension for firefox - but it only shows which mode it is rendering in and gives other info
It does let you edit the css on the fly though
.
Which reminds me I meant to add a request for easy extensions development in IE on the wiki page ..
-
LarryOsterman wrote:No, but the headline came from the /. article, and I'm assuming that's where the original reference came from.
Actually, I got the headline from Bink. -
Sven Groot wrote:
Actually, I got the headline from Bink.
Teach me. Sorry Sven
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.