RE: Update: Web browsers - a mini-farce (MSIE gives in)

[Michael Wojcik <Michael.Wojcik () microfocus com>]

> From: Valdis.Kletnieks () vt edu [mailto:Valdis.Kletnieks () vt edu] 
> Sent: Thursday, 28 October, 2004 14:23
>
> On Wed, 27 Oct 2004 10:42:41 PDT, Michael Wojcik said:
>
> > 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.

Anyone who doesn't understand that a finite-size container cannot hold more
than what it can hold is unlikely to manage to write software.

> > 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.

No, you don't.  It's enough to have a specification (that is, a contract)
which says that input X must contain data that meets certain criteria.  From
that, the careful programmer will write a validation routine that rejects
input which fails to meet that criteria.  It doesn't matter whether the
programmer has any understanding of SQL at all, much less what it may do
with its input.  It suffices to know that the program specification imposes
requirements on the input.

> > 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.

No you don't.  You just have to sanitize the input.  The HTML specification
says that certain characters have special meaning and must be replaced with
character entities in ordinary text.  If the program is producing output
that's supposed to be ordinary text, for consumption by an HTML agent, it
must perform those replacements.  End of story.  There's no need whatsoever
for the person writing that code to know anything more about HTML than which
characters need to be replaced, and with what.  In fact, even that's
unnecessary, because the specification for the program should note that
those characters need to be replaced; the programmer can remain entirely
ignorant of HTML.

> > 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..

See "finite-size container" above.  I prefer to use code not written by
idiots.

> 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.

Now it's *invisible* straw men.

> 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.

Really?  I find it hard to be certain about imaginary entities, myself.

> 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*".

Ah, so this really boils down to "if we can't expect programmers to
anticipate all bugs, we can't expect them to anticipate any".

If you can't see where the fallacy is in *that*, then I don't see much point
in continuing this discussion.

I'm really not interested in excuses for programmers who fail to demonstrate
even a little discipline in their work.  And that's precisely what Mangleme
has shown.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus