|
|
Posted by Gordon Burditt on 11/04/05 05:27
>> Not exactly. You should "validate" every input. That means confirm it
>> has the data you expect it to have.
>
>I always feel uncomfortable when people mention input validation in
>security discussion, as smacks of perimeter defense.
Sometimes the application is *SUPPOSED* to enforce its own security
requirements, such as not allowing a user to delete posts that aren't
his own. This can be just as important a requirement as avoiding
SQL injection attacks.
>Given that the
>question of what constitute valid user input is usually dictacted by
>the requirements of your application, it's not a good idea to rely on
>validation for security purpose. For example, while you might think
>that the single quote is unacceptable in a name, the O'Reillys and
>O'Conners of this world all say otherwise.
>
>The approach I favor is "security by assertion." Instead of looking for
>dangerous data, make the data safe. If the code is expecting a number,
>then force it into a number with intval.
I'll strongly disagree with this one. If an input should be a
number, and it's not, you should generate an error message (and
possibly log a tampering attempt), not process the input as though
it were zero or something else. Fixing an over-long string by
chopping it has potential for causing more (security and other)
problems than it fixes. Chances are a numeric input should be
checked against an application-specific range of allowable values
also.
"security by assertion" could be done by insisting that the input
match a given regular expression, and possibly a length check. That
doesn't rule out application-specific checks, such as if it's
supposed to be one of 7 different values, check that it matches one
of them.
Names should be validated for acceptable characters also.
There may be plenty of room for being too restrictive here, but you
should still check against a list of known acceptable characters,
not against a list of known unacceptable ones (backspace, carriage
return, newline, and most non-printing control characters would be
included here).
>If a text string will be
>inserted into a SQL statement, then escape it--always.
Ok, I'll go along with that, but it shouldn't eliminate application-specific
checks.
>The idea is to
>be proactive and not reactive. It's easy to know that you're something
>right than to know that things cannot go wrong.
Gordon L. Burditt
Navigation:
[Reply to this message]
|