Page 1 of 2

$_GET vars and security

Posted: Fri Nov 28, 2003 3:07 am
by Nay
Okay, I've been doing some read ups at sites and I've gotten freaked out by $_GET vars and it's 0% security. My first thought was I'd validate the $_GET from an array but then, it's still not that secure, I guess.

Array eg:

Code: Select all

<?php

$mode = $_GET['mode'];
$modes = array("submit", "post");
if(in_array($mode, $modes)) {
// do the script
} else {
exit;
}

?>
Well, that didn't make any sense to me because, the mode would not be the var that hackers or anyone change, It's more on the value vars such as $comment or things. Well, even if $comment was a $_POST, the user could still make out a form and use the action="" to my script.

Yes, I'm assuming I can't trust the user 100%. So then I thought of encryption, md5 and crypt is just a one way encryption from what I read. I'd need PGP or some libraries or encrypt and decrypt - which my host does not have <_<.

So now I'm stuck with an option to make my own encryption system or............any suggestions?

-Nay

Posted: Fri Nov 28, 2003 5:30 am
by Weirdan
What are you going to encrypt? It isn't clear from your post.

Posted: Fri Nov 28, 2003 5:40 am
by Nay
Basicly any information passed, comments, query strings and passwords.

-Nay

Posted: Fri Nov 28, 2003 5:43 am
by Weirdan
Hmm.. are you going to encrypt user input?

Posted: Fri Nov 28, 2003 5:50 am
by Nay
Well, no, not really. I would like to encrypt things that are necessary for the script to function. Say I have a script that inserts comments to different tables and it was supplied as;

postcomments.php?mode=post&table=news_comments

A person could make a form and inert into admin or any other day. Soluton 1 was a valid-tables-array and check but I'm wondering any other way, from what I had in mind I'd rather do a:

postcomments.php?q=kfnaksdmsakdjksajdksndkasjdkjsa

Which in q is the query string and it will be decrypted by a function in the script, then the query is parsed.

Am I being pratical here? O_o

-Nay

Posted: Fri Nov 28, 2003 6:11 am
by Weirdan
Nay wrote:Am I being pratical here? O_o
You are, especially if you're using some sort of front controller. Check out the manual for [php_man]mcrypt[/php_man] functions. This extension isn't available on some hosts, though.

Posted: Fri Nov 28, 2003 6:48 am
by Nay
http://207.44.150.103/~admin95/info.php

mMm, well, I guess my host is one of those "some hosts" <_<.

So I guess I'm going to have to create my on encryption method.

-Nay

Posted: Fri Nov 28, 2003 7:01 am
by Weirdan

Posted: Fri Nov 28, 2003 4:21 pm
by McGruff
Setting appropriate mysql privileges & different db connections is maybe one of the first things to do. Even if someone sneaked an admin table query into the script, it wouldn't be processed if a user-level db conn isn't allowed anywhere near the table.

You'd still want to add other measures. If you need to send table data via GET or POST, you could use substitute names and map these to the real ones in scripts - in effect creating an allowed tables list.

An allowed tables array could also work well but it does mean table names are being exposed. That wouldn't necessarily matter, although in general it's bad practice.

Encryption wouldn't necessarily be secure: a hacker can run through the common encryption methods to try to decrypt anything you've encrypted - unless you've added a secret cryptographic key.

An "alien array keys" check can play a part in detecting GET or POST tampering. You know in advance what keys should be there: other values indicate a hacking attempt - script could trigger a 404 if detected.

Posted: Fri Nov 28, 2003 8:49 pm
by Gen-ik
When it comes to posting information from a form to PHP I obviously always use the POST method. On the page that is receiving the info I normally check the $_SERVER["HTTP_REFERER"] to make sure that the info has come from another page on my site, and hasn't been posted from anywhere outside of my domain.

Just my pennies worth.

Posted: Fri Nov 28, 2003 9:07 pm
by Nay
Wow, that's good. Thanks, I've not thought of using $_SERVER['HTTP_REFERRER']. I can only remember to use REMOTE_ADDR most of the time.

I think I might log it if indeed the form was posted from an outside domain, along with the IP.

-Nay

Posted: Sat Nov 29, 2003 6:55 am
by Weirdan
HTTP_REFERER could be spoofed like a breeze, so it doesn't give any bit of protection.

GENERAL RULE: Never trust anything which comes from your customers (or their browsers).

Posted: Sat Nov 29, 2003 7:11 am
by Nay
mMm.........but generally, if I check HTTP_REFERER, and do a parse_url and match the host with the host in the config file. If it matches, go on with the script, else die() and send an error message.

But then they're are always ways to manipulate it, i guess.

-Nay

Posted: Sat Nov 29, 2003 7:57 am
by Gen-ik
Weirdan wrote:HTTP_REFERER could be spoofed like a breeze, so it doesn't give any bit of protection.

GENERAL RULE: Never trust anything which comes from your customers (or their browsers).
How? If someone sends information from a mock-up page on their site how will they change the HTTP_REFERER so that it looks like the info has been sent from a page on my website?

Posted: Sat Nov 29, 2003 8:01 am
by Nay
Maybe a really-obbessed-to-hack person can emulate it.......maybe. I don't know, there's always some dirty way.

-Nay