On Wed, 27 Oct 2004 10:42:41 PDT, Michael Wojcik said:
(Quoting two blocks in reverse order to make the point more obvious..)
How much would it have added to development time to have
closed *all* the holes *up front* (including *thinking* of them)
"thinking of them" isn't a prerequisite.
Actually, it is... see below..
You don't have to understand how to exploit a buffer overflow in order to
avoid overflowing buffers.
But you have to think of a buffer being overflowed to check for it.
You don't have to understand SQL code-injection
attacks to restrict SQL input fields to valid characters.
But you have to realize that SQL can be fed invalid characters to check for it.
You don't have to
understand cross-site scripting by embedded HTML to strip or sanitize HTML
tags from user-supplied input that shouldn't have them.
But you need to know which tags are safe and why, in order to strip or sanitize
it correctly.
You don't need to
understand how signed-integer overflow could cause a problem to check for
it.
But you need to understand it *can* be a problem to check for it..
But you need to understand at least the basics of THAT one to check for it,
too...
Puzzled by what goes there? Good. So am I - *neither* of us thought of it.
And that's the point - whatever goes in that blank space was certainly just as
big a problem as SQL injection or integer overflows or double-frees. But we're
both only human, and we'll look silly when the advisory hits BugTraq or
Full-Disclosure, and everybody will say "Look at that, yet another dumb-ass
programmer that didn't know enough to check for *THAT*". But what probably
happened was the phone rang at the wrong time, and the lines of code that
checked for it evaporated just as surely as the tail end of Samuel Coleridge's
poem 'Xanadu'......
pgpCuIaegiIw5.pgp
Description: PGP signature
