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

[Justin Koivisto]

Malcolm Dew-Jones wrote:

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 looks like something specific to a db abstraction layer like
PEAR::DB - I don't believe that RDBMS databases support this on their
own. (At least I haven't come across it yet.)

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

[Malcolm Dew-Jones]

rj***********@g mail.com wrote:
: What is "bind the statement to the value". What is bind?

bind variables

oracle examples

http://www.oracle.com/ technology/ pub/ articles/
oracle_php_cook book/ ullman_bindings .html

mysql via mysqli (look for "bind")

http://ca.php.net/mysqli
mysql without mysqli

<quote>
Andy Hassall
Sep 6, 2:28 pm show options
...
I recommend using the ADOdb library
(http://adodb.sourceforge.net/).
</quote>

Haven't used that myself yet, and I plan on trying it the next time I have
a reason sicne it sounds like a thin wrapper to add this very useful
functionality.

OT: the mysql escape should make anything _safe_, including things that
you hope to be number, so I still don't quite see the need for intval.

# ESCAPE == the mysql function the name of which I may have wrong

$maybe_a_number = ESCAPE($the_inp ut_data);

$sql = "select * from T1 where the_number = $maybe_a_number ";

# that should be _safe_, but should also generate an sql error if
# the number is not valid. It will also accept whatever syntax and
# automatic conversions are supported by the database, so if your
# database can handle human readable input like "1,234,456. 9", or
# 99,9 (where comma is the decimal point) then
# so can your application.

I'm not sure why it would be bad to allow the database to validate your
input anyway. You will be expecting it to to other validations, such as
"duplicate key", and in something like Oracle, any number of other
database enforced constraints.
--

This programmer available for rent.

[Malcolm Dew-Jones]

Justin Koivisto (ju****@koivi.c om) wrote:
: Malcolm Dew-Jones wrote:
: > 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 looks like something specific to a db abstraction layer like
: PEAR::DB - I don't believe that RDBMS databases support this on their
: own. (At least I haven't come across it yet.)

Some do support this natively. The cut of point appears to be the cost -
as they say, you sometimes get what you pay for.

According to a google search, a few example databases

Oracle DB2 Interbase Sybase MS-SQL

have bind variables built in (I am familiar with Oracle, it has "always"
had them).
mSQL, MySQL, PostgreSSQL

do not have them built in, but I wonder if the page was old because I
thought that PostgreSSQL did have them (but I don't use it so what do I
know).

Even things like MS Access have built in support for expressions in
statements that could be called bind variables.
--

This programmer available for rent.

[Jerry Stuckle]

Justin Koivisto wrote:

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,

You're right - it should have been is_numeric. And the rest of your
code is great, as well (of course).

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

[Chung Leong]

Jerry Stuckle wrote:

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. :-)

Geez. Either I failed to express myself clearly or people have never
heard of defense in-depth. The existence of a mechanism to stop one
type of SQL injection does not imply that data will necessarily reach
it. You put it there so that the code that interacts with the database
isn't dependent on your validation code for safety. That code should,
of course, keep the user from encountering the odd behavior.

[Justin Koivisto]

Justin Koivisto wrote:

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

Some things I should have pointed out is that this does not cover all
the different ways of representing numbers...

For instance, if the submitted value was an octal number like "010",
$clean['num'] is 10 rather than 8 as it should.

If "0x10" was submitted, $clean['num'] == NULL rather than 16...

If "1e4" is submitted, $clean['num'] == float(10000)...

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

[Justin Koivisto]

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.

IIRC, MySQL will actually give an error if you to quote a value for an
integer field...

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

[Andy Hassall]

On Fri, 04 Nov 2005 14:21:21 -0600, Justin Koivisto <ju****@koivi.c om> wrote:

IIRC, MySQL will actually give an error if you to quote a value for an
integer field...

mysql> create table t (c int);
Query OK, 0 rows affected (0.05 sec)

mysql> insert into t values ('1');
Query OK, 1 row affected (0.03 sec)

mysql> select * from t;
+------+
| c |
+------+
| 1 |
+------+
1 row in set (0.00 sec)

MySQL still has a nasty habit of mangling data to fit, rather than raising
errors.

mysql> create table t (c varchar(1));
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t values ('clearly too long');
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> select * from t;
+------+
| c |
+------+
| c |
+------+
1 row in set (0.00 sec)

OK, it's come up with a "warning" but that's a bit more than a warning. I
believe MySQL 5.0 has an option at last to turn these into errors.
--
Andy Hassall :: an**@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[R. Rajesh Jeba Anbiah]

Chung Leong wrote:
<snip>

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

It is true that constants cannot be tampered. But, I don't get
the idea, how it is a right choice for global scope thing. I also tried
the function, but in my tests, it severely affects the memory.

FWIW, OP may refer Chung's thread on security
<news:iP******* *************@c omcast.com> (
http://groups.google.com/group/comp....a18bc51f0448fc )

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Chung Leong]

R. Rajesh Jeba Anbiah wrote:

Chung Leong wrote:

Avoid using global variables in general. It's a bad programming
practice. For configuration info, use either constants or a function.

It is true that constants cannot be tampered. But, I don't get
the idea, how it is a right choice for global scope thing. I also tried
the function, but in my tests, it severely affects the memory.

A lot of vulnerabilities in PHP programs are caused by people using
global variables to store configuration info. If parameter is constant
value, then it should be a constant.

I don't quite understand what you mean by the use of functions
affecting memory. The idea is to use a function to return a parameter
as opposed to storing it in a global variable. What that does is
changing the assumption made by your code. When you use a global
variable to store a configurable parameter, your code assume that the
it was assigned to the proper value at an earlier point in time. When
you call a function, it is assuming the function exists. This latter
assumption is enforced by PHP (or else the script dies) hence it's
safer. In contrast, it's far harder to prove that the former assumption
would hold under all circumstances.