At 9:08 AM -0400 6/4/02, Wietse Venema wrote:
>The proper approach is to eliminate such ambiguity, by normalizing
>data, that is, by transforming messages into a form that avoids
>all the grey areas where implementations err, or where RFCs are
>ambiguous.

Which is non-trivial, and also runs the risk of taking things that
passed a scanner and turning them into something dangerous.

The old adage for standards of "make your output conform strictly,
but be lenient in what you accept" simply isn't appropriate for a
secure environment. Microsoft has played very fast and loose with
what their software accepts (backslashes in URLs, mis-typed MIME
files that have their type determined by content...) and we are all
dealing with the consequences. That model worked well when the input
was from a user. It does not work well when the input is from
servers (which can be corrected) and untrusted sources (which should
be rejected).

I would go the other route with a scanner/interpreter. If the input
doesn't match your understand of the standard--reject it. Actually,
I was going to say, "or turn it into plain text", but there again we
run into the problem of software which is overly happy to interpret
what the remote sender "meant". I really don't think there's any
other safe solution.

Of course politically, if what you are rejecting is output by some
major vendor--you've got a problem.

-- 
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]