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'......
Attachment:
pgp8KenJzFGHX.pgp
Description: PGP signature