How to enhance security of a website?

Question

Question 1 : Can I just use $userid = mysql_real_escape_string($_GET['user_id']);

Or I need to use the codes below is better?

function mysql_prep( $value ){
        $magic_quotes_active = get_magic_quotes_gpc();
        $new_enough_php = function_exists( "mysql_real_escape_string" ); //example. php >= v4.3.0
        if( $new_enough_php ) { //php v4.30 or higher, undo any magic quote effects so mysql_real_escape_string can do the work
            if( $magic_quotes_active ) { $value = stripslashes( $value );}
            $value = mysql_real_escape_string( $value );
        } else { //before php v4.3.0.
            if( !$magic_quotes_active ) { $value = addslashes( $value ); }
        }
        return $value;
    }

$userid = trim(mysql_prep($_GET['user_id']));

Question 2 : Do we really need to use md5() or shal() on the $_SESSION['user_id']? Why we need that? session hijacker can get the session id only, but he cannot get the session variable value right? If so, then I don't need to hash the value of $_SESSION['user_id'] anymore right? For example :

if (isset($_POST['login'])) {
        if ($username==$user_username_in_db && $hashed_password==$user_password_in_db) {
                $_SESSION['user_id'] = sha1($user_id_in_db); //sha1 convert userid to crazy long characters
        }
}

$query2 = "SELECT id FROM user WHERE sha1(id)='{$userid}' LIMIT 1";

Question 3 : Since php session hijacking happen and I can't afford to use ssl/https, so I make the website request the user to submit password everytime they try to delete a message or friend, because the session hijacker may impersonate the user to delete his messages/friends. May I know is it dangerous if my website always ask user to input password? The password will be easier to be hacked? May I know session hijacker can only impersonate the user, but cannot steal the user's password right?

Answer 1

Question 1: if your user_id is stored as an integer in the database, you can use:

$user_id = intval($_GET['user_id']);

So if someone tampers with the query string, all that can happen is that they get a blank result. However, it's unclear HOW you use that $_GET['user_id'];

Question 2: sha1 and md5 are hashing algorithms. That means that for any given string of any length, they give back a number that's displayed as 41/32 byte hex string.

What's the use of that? The use is that those algorithms aren't reversible, which makes them perfect for hiding information such as someone's username and password. Many people use one and the same password for everything, in order to ensure their password wont' get stolen in case you messed up and a hacker got the access to your database - you provided another level of security for your users - no one should be able to get an actual password out of the hash. Naturally, that also prevents the person who has the access to the db to read people's passwords and compromise their privacy. Now, there are ways to try to reverse hashes to plain text (so called rainbow tables) but that's another topic all together.

Question 3: you should actually prevent session hijacking in the first place. Why does it happen? Are you exposing session_id to the public somehow (via URL) and are you implementing standard checks?

Asking for password every now and then is an annoyance to the user and should be avoided, unless you can't think of a way to protect the session.

As for other things, there's something called PHP PDO which SHOULD in theory make the use of cleaning strings, connecting to the database and inserting stuff into the database much easier (although it's quite complex compared to regular mysql_ or mysqli_ functions so people seem to avoid it). You should at least read about it to get an insight on what it does and how it can help you against SQL injections.

Answer 2

Question 1 : Can I just use $userid = mysql_real_escape_string($_GET['user_id']);

yes and no.
yes because you don't need all that code below.

no because mysql_real_escape_string has nothing to do with security.
it doesn't make data "safe", nor "eliminate injections", nor "convert dangerous characters".
but just merely escape string delimiters.
that's all.
So.

• unless you're going to use string delimiters (quotes) around your data, it's entirely useless.
• every time you're going to put some quote-delimited data into query, you should use this function. NO MATTER if your data is safe or not, came from user, server or whatever source - it's all irrelevant. mysql_real_escape_string belongs to quoted data and nothing else.
• still there is some nitpicking about encodings, so, if you're gonna use it, you should always set your encoding using mysql_set_charset() function.

• you can use prepared statements instead of putting your data directly into string.

• (surprise!) SQL security is not limited to this function usage. there are numerous other issues.

• overall site security is not limited to SQL injections and session hijacking.

Answer 3

You should never save your password in plain text. You better use MD5 or SHA1. The advantage of using one o those is that no one can "decrypt" the password it is a just "one-way" encryption.

Answer 4

Always use bind parameters instead of escaping to prevent SQL injection attacks. Escaping can work, but it's error-prone: different databases have different escaping rules, and you might inadvertently escape based on the wrong set of rules, leaving gaps that can be exploited. If you keep the parameter values separate from the query string, there's no chance that a malicious parameter value can change the structure of the query. PHP data objects are the right way to do this in PHP.

I don't see a point in hashing the user ID stored in the session. The usual reason for hashing something is to prevent someone who sees the hash from knowing what the "original" value was, but things stored in $_SESSION aren't shown to the user anyway. If you were using register_globals, it could potentially be a defense against someone fooling code that refers to $user_id by putting a user_id parameter in the query string, but that can be circumvented (the attacker can just put the hash of the target user_id in their query parameter), and you shouldn't be using register_globals anyway (for exactly these reasons).

Asking the user to enter their password more frequently means the password has to be transmitted over the network more frequently. Since you're not using SSL, that means there's an increased risk of it being eavesdropped. There are other ways to avoid session hijacking, such as storing the user's IP address in the session and discarding the session if a request with that session ID comes from a different IP.

You can also implement support for OpenID as an alternative to password authentication. If you do use passwords, you should store only salted hashes in your database, so that if someone manages to get a copy of your passwords table, they can't recover the users' actual passwords.