mailing list archives
Re: Exploits in websites due to buggy input validation where mozilla is at fault as well as the website.
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Fri, 16 Jul 2004 12:10:33 +1200
Seth Alan Woolley to me:
The correct solution to all such problems is simply to reject the
content as malformed. And guess what will happen when you do that?
Several really crappy web design products will disappear because the
folk using them will drop them because no-one can see their pages _and_
the rest will suddenly become very inetrested in producing properly
compliant content, as they should have been from the outset.
Playing "guess what the moron really meant" is a recipe for being
screwed, so let's get over the previous "need" to "see it at all cost"
and get some sense back into what folk are doing...
It wouldn't affect too many products to fix this. I would be
hard-pressed to find _any+. I would think the fact that IE didn't
interpret the malformed script tag would lead all developers to fix any
and all occurrances of the problem in real production code. Because of
this only XSS attempts are really going to be blocked by a fix.
It was behavior only seen in Mozilla. None of the other browsers do it.
And the last comment of mine to the bug explained why it's possible to
fix the tags without breaking anything unless it is highly suspect.
When you're repairing a script tag, close the tag at the first
whitespace character, not before the next tag so that anybody can stick
whatever attributes into the entity they want. Fixed. Leave the other
tags to interpret liberally if you want. I mostly care about the script
tag and the object and iframe tags, especially -- anything with src or
href attributes. The general fix would be to close the tag before the
text 'src=' or 'href=' and any other attribute like this.
And you don't see the problem with that?
Hint -- "and any other attribute like this".
Sounds like blacklisting or "default allow" to me. Now, what does the
theory _AND_ history tell us about such (hint) stupiidities?
Do you know what they all are? What about the ones that will be added
in the future -- no, they won't be a problem, surely the Mozilla (and
Opera and IE and ...) developers will simply add special handling for
them too when they arise and of course, everyone who uses Mozilla (or
whatever browser) updates to the latest, greatest version immediately
it is released so there will never be any exposure going forward...
It's a simple fix and not fixed it makes XSS a lot easier on many common
web tools. (Early versions of the popular blog tool MovableType, for
example, had this bug.)
And that attitude is a large part of why we're in the security mess
we're in. "It'll be right" might be good enough for government work,
but it certainly sucks when it comes to security awareness issues...
Broken input is broken input and apart from in incredibly simple
systems with highly constrained and limited possible valid input
options (and even then by far not always), thinking you can accept such
input and "tweak" it to "fix" it is one of the keys that opens the gate
to the fool's paradise.
There are plenty of such key-holders at MS but shouldn't Mozilla
developers be above that?
I know it's a hard marketing battle to win when your competitor is the
800lb gorilla _AND_ they do all the stupid dirty tricks as well, but if
you're going to compete on quality and/or standards compliance and/or
security issues, at least try to do a reasonable job of _those_ things
rather than lowering yourself to Microsoft's level.
Full-Disclosure - We believe in it.
Re: Exploits in websites due to buggy input validation where mozilla is at fault as well as the website. Pavel Kankovsky (Jul 15)