From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
Sent: Monday, 25 October, 2004 21:25
On Mon, 25 Oct 2004 09:03:20 EDT, David Brodbeck said:
Software should be able to deal with any input that's thrown at it.
Two quotes come to mind:
"A program designed for inputs from people is usually stressed beyond
breaking point by computer-generated inputs. -- Dennis Ritchie
Moot. Since HTML is frequently computer-generated, HTML renderers shouldn't
be designed for human-generated input.
Yes, "should be able to deal with anything" *is* a laudable goal. On
the other hand, there's a (presumed) requirement that the software
actually *SHIP* sometime before the thermal death of the universe -
which means that the person who has to make the decision on
when/whether to ship has to decide whether the ship date should be
slipped *another* 3 months just because some automated test program
found that the package will crash if it gets requests from a prime
number of dolphins (the ceteans, not the football players) in the same
4-second interval.
I think that's a straw man, Valdis. HTML renderers should expect malformed
HTML input, and dealing with it is not difficult. There's simply no excuse
for buffer overflows and null pointer dereferences when processing HTML.
It's just not that hard a problem. It's not a matter of exhaustive testing;
the kinds of bugs found by Mangleme are basic ones that any code review
should have caught - if the code was written properly in the first place.
Basic input validation and sanitization isn't that difficult.
I write comms code - client- and server-side middleware. I wouldn't dream
of implementing a protocol with code that didn't sanity-check the data it
gets off the wire. I don't see any reason why browser writers shouldn't be
held to the same standard. Avoiding unsafe assumptions when processing
input should not add significantly to develompment time; if it does, you
need to retrain your developers.
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus
