security in php apps

Anon

hi,
I want to ask something:
How can I prevent the some malicious code in the submitted user input. For example, it can be <script> tag or | symbol or some malicous php code inside.... I think most ignored part of security is the apps' code.
Is there any good up-to-date security checklist or article about security in php issue?
Regards

Anon

First. Zap the bad characters (you know the ones).

Second. Especially if you are writing to anything, put a lid on the number of bytes you will accept.

Third. Make sure that your script will not accept input from anywhere outside your domain.

Fourth. If you are writing to anything, have a login system where you have authenticated your users.

Last. Remember what Lluis Mora says. "The only safe computer in turned off, unplugged, locked in a vault, and buried in the desert."

Happy motoring!
--ph

Anon

Use variables defined in a separate file for "DBHost,"DBUser","DBPass", and "DBName". Then require("secretfile.php") where necessary in your scripts.

NEVER ftp or telnet this file. ALWAYS use SSH. While you're at it, use SSH for EVERTHING.

Later.
--ph

Anon

If you are going to keep credit cards lying around on your server, seed them. That way even if your root PW gets boosted your customer's cc numbers will be safe. For a while.

There may be more. I am very paranoid.

--ph

Anon

Here's a quick example of what I mean by "lid";

These 5 lines of PHP use the fputs() function to append a 'file.txt' with $input followed by a newline.

$path = "/home/domain/www/dir_where_write_is_allowed/"; // permissions on this dir are 666
$listfile = "file.txt";
$fp = fopen("$path$listfile", "a");
fputs($fp, "$input\n", 100); // limit to 100 bytes
fclose($fp);

As for "bad" characters, see this section of this site:
http://www.phpbuilder.com/manual/function.strip-tags.php

You can apply this function, or you can use eregi_replace() to check for and replace only those characters you will not allow.

Then as far as making sure that the scripts are submitted from where they are intended, you can do that in PHP, it has nothing to do with your ISP. Study up on environment variables, specifically HTTP_REFERRER. what you want to do is compare the referrer with your domain, seeking a match.

--ph

Anon

In an book I was reading about security in forms etc... I liked the idea of only allowing what's ok, rather than trying to rule out what's not.

For instance, in a text field that asks for the first name of a person, you might allow only letters or use perl compatible regular expressions and allow only the "\w" or "words".

This entirely eliminates any possible bad sets of characters that might include escapes or the backtick, which would be very unlikely to cause any harm in this particular example but I think this example can be extended to other much more insecure processing like uploading files or calling system commands through exec or system or some such function.

matt.

Anon

Matt is absolutely right, and it's a bit easier to allow acceptable, as well, in my opinion.

This is Perl that shows both ways, taken from the cert site:

#! The first function takes the negative approach.
#! Use a list of bad characters to filter the data

sub FilterNeg {
local( $fd ) = @_;
$fd =~ s/[<>\"\'\%\;)(\&+]//g;
return( $fd ) ;
}

#! The second function takes the positive approach.
#! Use a list of good characters to filter the data

sub FilterPos {
local( $fd ) = @_;
$fd =~ tr/A-Za-z0-9\ //dc;
return( $fd ) ;
}

$Data = "This is a test string<script>";
$Data = &FilterNeg( $Data );
print "$Data\n";

$Data = "This is a test string<script>";
$Data = &FilterPos( $Data );
print "$Data\n";

If you're interested in more, see the article:
"Understanding Malicious Content Mitigation for Web Developers"

at:
http://www.cert.org/tech_tips/malicious_code_mitigation.html/

--ph

Anon

Don't rely on HTTP_REFERRER as that is something that the server relys on the client to send it and thus is easily spoofed.

Anon

True. This is just one small defense that is easy to employ, and one of many that can be defeated.

--ph

Anon

There is a much easier way to secure user-supplied input. PHP provides two functions, htmlspecialchars() and htmlentities(), which change HTML characters to their &... counterparts. Which of those two to use depends on how many tags you want to protect. Also, if you are allowing <b>, <p> and <br> tags, note that they will get killed as well. So this is only for a no-html input page.

Scott M. Miller