PHP Security

[rjames.clarke]

I am developing an online application and the last thing I need to get
a handle on is security.
This app is very heavy with forms. Business critical data will be
entered via forms and inserted in to a database (mysql).

I've google "php security" and from what I've read, I should:

1) Filter all form data by stripping all non-alpha/numeric characters
out,

2) Have the database on a different server,

3) Use "POST" not "GET",

4) Turn global variables off.

5) Use sessions for logins

Should this do it? Or do I need more precautions?
Even with all this can I still get hacked?

Thanks

bob

[Chung Leong]

Malcolm Dew-Jones wrote:

rj***********@g mail.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.

[Gordon Burditt]

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

[Malcolm Dew-Jones]

Chung Leong (ch***********@ hotmail.com) wrote:
: Malcolm Dew-Jones wrote:
: > rj***********@g mail.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_globa ls."

--

This programmer available for rent.

[Chung Leong]

Gordon Burditt wrote:

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.

You misunderstood me. I said you shouldn't rely on validation for
security purpose. I didn't say don't do validation. My point is that
input validation is a functional requirement and not a security
measure. You do it so that you can, as you said, tell the user he did
something wrong. You don't want to rely on it, at the same time, to
protect your code downstream.

[Chung Leong]

Malcolm Dew-Jones wrote:

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.

Well, how else do you safely insert an integer into a SQL statement?
You could escape and put quotes around it, but then you're just asking
the database to cast the number into integer for you. If you leave it
as is then you're placing the burden on your validation and error
handling code to avert SQL injection. I could easily imagine someone
writing something like this: if(preg_match('/[0-9]+/', $pkTable)) { ...
}. Calling intval or floatval is easy enough.

[Peter Fox]

Following on from Chung Leong's message. . .

Gordon Burditt wrote:

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.

You misunderstood me. I said you shouldn't rely on validation for
security purpose. I didn't say don't do validation. My point is that
input validation is a functional requirement and not a security
measure. You do it so that you can, as you said, tell the user he did
something wrong. You don't want to rely on it, at the same time, to
protect your code downstream.

Input validation is a great asset to security because it simplifies the
inputs that the security has to field. Any typed input is going to have
typing errors or the user has misunderstood what goes where so when
unexpected input arrives it is best _in the first instance_ to deal with
these as an interface matter not as a security issue.

But /then/ there are two matters (One for the programmer one for the
designer) which are 'Is this a bit of bent wire being used to pick the
lock?' and 'Is this key in the right hands?' Neither should be assumed.
I like to weed out ununderstood data as soon as possible and protect
(say) the database as close to the database as possible. In the first
case it is the meaning and structure I'm interested in, in the second
its is the particular threats to (say) sql injection that I'm addressing
and I couldn't care if the (say) string is 1 or 1000 characters long -
just so as it can't do naughty things by accident or design.

Below the raw input validation is logic such as they say they want 5
starters, 5 main courses and 50 sweets - odd! (So how did that happen -
could be a bug or misunderstandin g problem rather than malicious.

--
PETER FOX Not the same since the poster business went to the wall
pe******@eminen t.demon.co.uk.n ot.this.bit.no. html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.dem on.co.uk>

[Jerry Stuckle]

Chung Leong wrote:

Malcolm Dew-Jones wrote:

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.

Well, how else do you safely insert an integer into a SQL statement?
You could escape and put quotes around it, but then you're just asking
the database to cast the number into integer for you. If you leave it
as is then you're placing the burden on your validation and error
handling code to avert SQL injection. I could easily imagine someone
writing something like this: if(preg_match('/[0-9]+/', $pkTable)) { ...
}. Calling intval or floatval is easy enough.

If the incoming value isn't an integer, you don't.

For instance - let's say I want to order 100 widgets. However, in the
quantity column I mistype "1q00", because of my fat fingers. :-)

Your way of forcing it to an int with intval would give me 1 item. The
correct response is to call is_int to determine if it is an integer or
not, and if it isn't, tell me about it.

Calling intval or floatval is incorrect - NEVER change the user's data;
it's either valid or invalid. If the former, process it. If the
latter, return an error message to the user!

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Malcolm Dew-Jones]

Chung Leong (ch***********@ hotmail.com) wrote:
: Malcolm Dew-Jones wrote:
: > 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.

: Well, how else do you safely insert an integer into a SQL statement?

insert into Tbl (my_col) values (?)

and then bind the statement to the value.


--

This programmer available for rent.

[rjames.clarke]

What is "bind the statement to the value". What is bind?

[Justin Koivisto]

Jerry Stuckle wrote:

<snip>

Your way of forcing it to an int with intval would give me 1 item. The
correct response is to call is_int to determine if it is an integer or
not, and if it isn't, tell me about it.
No, calling is_int is not the correct response. That is because all data
that is collected from the user is of type string. is_int checks to see
if it of type integer. What you'd really want to do is something like
the following:

if(is_numeric($ _POST['num'])){
if (intval($_POST['num']) == $_POST['num']){
$clean['num']=intval($_POST['num']);
}else if (floatval($_POS T['num']) == $_POST['num']) {
$clean['num']=floatval($_POS T['num']);
}
}else{
// not a number...
}

Calling intval or floatval is incorrect - NEVER change the user's data;
it's either valid or invalid. If the former, process it. If the
latter, return an error message to the user!

Correct, never change the submitted data, but in the case of numbers,
converting the variable type is acceptable if you don't change the
meaning of the submitted data.

--
Justin Koivisto, ZCE - ju****@koivi.co m
http://koivi.com