|
|
Posted by Malcolm Dew-Jones on 11/04/05 05:52
Chung Leong (chernyshevsky@hotmail.com) wrote:
: Malcolm Dew-Jones wrote:
: > rjames.clarke@gmail.com wrote:
: > 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,
Your right. Input validation is not for security. I mentioned it so that
it would be clear I was talking about two different steps for input data,
i.e. validating (one step, quoted above) and making the data safe by
escaping it (another step, not quoted above).
:as smacks of perimeter defense. 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 don't like to modify the data. What goes in should be exactly what the
user input - if it's valid, or not at all otherwise. Nothing to do with
security.
:If a text string will be
: inserted into a SQL statement, then escape it--always.
Definitely correct, but escaping is not the same as using intval to force
something into a number. Escaping is the mechanism to ensure that the
database (or whatever) sees and stores the original data in its original
format.
: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.
: > : 2) Have the database on a different server,
: >
: > It also means that the database is accessible via the network, which may
: > itself be a security risk itself if you're that concerned about security.
: >
: > But probably a good idea.
: It also allows you to keep the database server fully shielded behind a
: firewall. The main benefit though I would say is having a second server
: as backup, in case one catches on fire or something.
: > : 4) Turn global variables off.
: >
: > Yes.
: Avoid using global variables in general. It's a bad programming
: practice. For configuration info, use either constants or a function.
Sure, though I assumed he was actually talking about "register_globals."
--
This programmer available for rent.
Navigation:
[Reply to this message]
|