|
|
Posted by Chung Leong on 11/04/05 04:11
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, 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. If a text string will be
inserted into a SQL statement, then escape it--always. 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.
Navigation:
[Reply to this message]
|