Coding securely...

[dalecosp]

I'm working on my first rather large e-commerce project, and hope to have the new system on line in a month or so...

Anyway, I was reading Spencer P.'s rather dated (but nonetheless helpful) article, and wondered what advice we could share on the subject...

Of course, I code locally (thanks, feldon23, g) and I am trying to ditch text inputs in favor of selects wherever possible; however, items like names, addresses and credit card numbers don't lend themselves to that very well. Do you use trim(), stripslashes(), htmlentities(), etc. to do variable conversion as part of the verification process? Generally, all I've been taught to do is maybe a trim() and check the string with an ereg() statement. Are there any other common practices I should know about???

TIA,

[matt_4013]

Always validate 🙂 Assume that everyone is trying to break your script, because there's a hell of a lot of people that will!

trim() is great, allows you to validate input if the user has chucked in some spaces.

Regular Expressions are good if you need to validate a particular pattern, like an email address.

If your server doesn't have magic_quotes_gpc set then do an addslashes on all inputs before you send it to a database, or run a system command on it. SQL injections aren't fun! :mad:

Not much more I can think of here. Keep all files that contain passwords below the root of the document tree, so that nobody except the web server can access them, and include them from your normal files 🙂

Hope that helps a little.
Matt

[mogster]

Hi-ho!

I agree with the poster above: error/manipulation checking is mandatory. I do it twice: first with javascript for user friendlyness (user don't need to submit to be told where he err), then again by php when the data reaches the server.

I'm using several functions, with different checking depending on wether the user is authenticated or not (authenticated users may be allowed to use html-tags, for example).

Here's some of the clean-up functions:

## Function for the ones we trust ;-) ##
function dbIn($text) {
$text = strip_tags ($text, "<ul>,<ol>,<li>,<b>,<i>");
$text = str_replace(chr(10),"",$text);
$text = str_replace(chr(13), "<br>", $text);
$text = addslashes($text);
return($text);
}
## Function for the not-trusted ##
function dbInsans($text) {
$text = strip_tags ($text, "");
$text = str_replace(chr(10),"",$text);
$text = str_replace(chr(13), "<br>", $text);
$text = str_replace("\"","*",$text);
$text = str_replace("\'","*",$text);
$text = addslashes($text);
return($text);
}

If you're starting afresh you should also code with intention of having globals set to off (mine aren't... :rolleyes: ) to further limit the attackers possibilities.

I also go through my scripts and close the possibilities for any url-manipulation of non-post/get/cookie vars (ie. vars that is fetched and processed by script only - not submitted). Guess that's not so important when the globals are off, but anyway - on top of any auth'ed page there's bound to be something like:

if($server_auth_hash != "") {
die("Yeah, as if...");
}

because the server_hash is a value generated by the server, further down in the script.
Just go through every key auth value and close the possibility for any "pre-generated" existence 😃

Then there's the sql-manipulation.
I've recently surfed a lot on dubious hacker-sites to try to unlock some of the secrets they use (but you didn't understand a word, did you, knutm?), and found that the manipulation of sql is quite easy. Shan't delve into this here, but as a reference:
http://mel.ini2.net/p/sql_injection_walkthrough.txt
http://www.hackersplayground.org/papers.html

And it's vital to turn of error-reporting in php, and protect any inc's from being read directly.

knutm

[dalecosp]

Wow! Thanks a lot for your insight Matt/Mog, and Mog for the reams of reading. :eek: I can see I'm gonna have to sit down and process a lot on my Cranium .0033 box before I do much more coding if I want to truly "run with the big dogs." 🙂

I'll check the magic quote setting; and strip_tags() is one I have never ever noticed, While I've seen mentions of SQL injection, never paid much attention since I'm really new on SQL. I'm using it, though, so something tells me it may be more like 2 months before we want to add the new stuff to the extant site. Problem is, I'm exicted 'cause the functionality is almost complete (I think---testing is going well) and it's hard to make the clients wait...

As to javascript checking, my present thought is that load on the server isn't too bad, though bandwidth responsibility will need to be addressed. It seems possible that I could 'go live' and add that later.

I've almost always coded RG=0, and always ereg() inputs to some formula. I haven't yet worked out a regexp for $address, $city, etc. Names, emails, phones, etc., absolutely!! I am also trying to adjust all user input to use selects if possible instead of text fields, but that's a honking big job on some fields. (What if user wants 549 widgets? a loop, I guess...poor surfer, heh)

And no, I never use ".inc" ... been around the web long enough on that one...although, I'm at least as vulnerable as the next guy I'm sure. I include "file.php", and make sure that it produces no output on its own. Thanks again guys for your thoughts!!

[mogster]

Hehe, since the post above, I've checked the site I'm working on, and discovered several glitches in the VAR-reception 😃
Wrote this function to prevent the manipulation of cat and art:

## This function is for cleaning GET-vars,           ##
## and will extract only preferred values            ##
## For extracting digits only:                       ##
## $do_type = ":digit:";                             ##
## For extracting letters in alphabet:               ##
## $do_type = ":alpha:";                             ##
## For extracting digits/letters in alphabet:        ##
## $do_type = ":alnum:";                             ##
## For extracting lowercase letters:                 ##
## $do_type = ":lower:";                             ##
## For extracting uppercase letters:                 ##
## $do_type = ":upper:";                             ##
## For extracting hex:                               ##
## $do_type = ":xdigit:";                            ##
## This will prohibit any manipulation of the sql,   ##
## like in inserting ' or " to provoke sql-errors,   ##
## especially in WHERE clauses:                      ##
## www.yourdomain.com/index.php?cat=3&art=234        ##
## "SELECT * from field where category_id = '3'      ##
## www.yourdomain.com/index.php?cat='3&art=234       ##
## will be with injection                            ##
## "SELECT * from field where category_id = ''3'     ##
## which provokes an error response from mysql       ##

function cleanVar($the_var, $do_type) {
	$the_var = ereg_replace("[^[".$do_type."]]", "", $the_var);
	return $the_var;
}

## Typically called with:                   					##
if(!empty($_GET['cat'])) {
	$cat = cleanVar($_GET['cat'], ":digit:");
}
if(!empty($_GET['art'])) {
	$art = cleanVar($_GET['art'], ":digit:");
}

knutm

[mogster]

BTW:

Here's for email-check:

if (empty($email)) {
$error .= "<li>You need to submit your e-mail";
} else {
if (!eregi ("^([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,4}$" , $email)) $error .= "<li>The e-mail is not valid";
}

knutm

[dalecosp]

Originally posted by mogster

if (empty($email)) {
$error .= "<li>You need to submit your e-mail";
} else {
if (!eregi ("^([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,4}$" , $email)) $error .= "<li>The e-mail is not valid";
}

[/B]

Here's what I've used in the past....

function ValidateInput($var, $type) {
        trim($var);
        if ($type=="name") { $Pattern = "^[A-Z][c]?[A-Z]?[a-z]+[a-z]$"; }
        elseif ($type=="email") { $Pattern = "^([0-9a-z]+)([0-9a-z\._-]+)@([0-9a-z\._-]+)\.([0-9a-z]+)"; }
        elseif ($type=="phone") { $Pattern = "^([0-9]{3})-([0-9]{3})-([0-9]{4})"; }
        $valid=ereg($Pattern, $var);
        return $valid;

} # end of Function

I notice a lot of the code we are posting is acting on the input, not just checking it. Is that something I need to be doing....your opinions?

[mogster]

You mean clean it up?
Well, depends on wether the posted data effects script execution, I guess? Which is more or less the case in most situations, probably.

I'm not really that security-minded when it comes to VARS, or haven't been up till now. Being a globals=on-man 😃 , I more or less accepted what was posted and happily added slashes, thinking this would do the trick.

In my opinion there's a difference between data submitted in an auth environment and data that may be submitted by anyone. Depending on the nature of the authentication (may anyone register and submit data, or is the user regged by an administrator?), authenticated users can be given higher privileges and may insert html-code in text, edit/upload files and so on.

But the un-authenticated environment should be protected, and especially the GET-vars, being very visible and exploitable.
Globals set to off is really a boost for security, but it DO require you to rewrite the existing code to enable the vars for them scripts.
Then we won't have to do checks like this:

$nono = getenv(REQUEST_METHOD);
if($nono != "POST") {
echo "The correct request method for this script is POST. $nono it????";
}

knutm :p