[web] PHP & MySQL - How secure is this?
Author
Hi there,
I have written a login page (using MySQL & PHP) where users can log in and view their own information etc...
I am wondering if, how I have gone about it is secure against hacker attacks or if there is more I can do.
My initial login screen prompts for username and password and compares against a MySQL table for validation. Once successful I have used 'session_start()' and am passing the login name to the pages after that.
Not all users have access to the same resources so each page heavily relies on $_SESSION['loginName'] (used to pass the username around).
How secure is this approach? Is there anything I can do to increase security?
Thanks in advance.
I assume that the password is hashed (preferably salted and hashed) on the database? If not, that would be a good place to start.
With regard to sessions, it is worth implementing at least some rudimentary protection against session hijacking.
Ensuring that you prevent SQL injection attacks goes without saying.
With regard to sessions, it is worth implementing at least some rudimentary protection against session hijacking.
Ensuring that you prevent SQL injection attacks goes without saying.
Also not a bad idea to use SSL (https) for the login handling, to avoid sending those passwords in plain text.
Author
Thanks for the suggestions so far. I'll take a look at those links :)
How do you prevent against this happening?
Quote:Original post by benryves
Ensuring that you prevent SQL injection attacks goes without saying.
How do you prevent against this happening?
Quote:How do you prevent against this happening?
There are several levels of security you can build into your app to prevent SQL injection.
The first starts with access rights of the database session you're opening up. If you can reasonably predict that a user's actions will be read-only, there is no need to connect to the database with any DML or DDL privileges.
Second, never ever use raw user input directly in a SQL statement in your server side scripts (that includes ANYTHING that comes from the client through form or url variables for that matter, even if the user didn't explicitly input the value, a hacker could still change hidden form fields or URL parameters with ease).
Instead, you'll need to perform some processing and safety checks to that input before you use the values in your SQL. The best way to do this is utilize bind variables that many frameworks provide, because type checking will be performed for you automatically. A hacker won't be able to inject string of SQL where an integer is expected if the bind variable is type safe. Building dynamic SQL from appending strings together (and not using bind variables) is generally a bad idea.
Also, make use of stored procedures as much as possible in place of SQL statements written directly into your scripts. Among other benefits, you will also get type-safety from this practice.
Hope this has helped and I wasn't too vague or too simplistic. Now, Google SQL injection and read!
Quote:Original post by lonewolff
Is there anything I can do to increase security?
On a different note than my last post, yes there are some things you can do.
First, it's good that you're using sessions, just make sure you don't store the username in a cookie. By default, PHP sessions will not do this so you're probably ok.
Second, you can use a revolving session ID, where each time you grab a user's session on the server, you keep the session alive and CHANGE their session ID - this will send a different session ID back to the client in a cookie. This helps eliminate session hijacking because a hacker would generally have very little time to discover and use a session ID before it is changed, and would have no way to predict the next session ID to be used.
And probably most important of all, your biggest security vulnerability will not come from session hijacking or these other devious tricks. Hackers are generally lazy and will take the path of least resistance. Close any back-doors, get rid of magic passwords, enforce users to enter STRONG passwords, and use strong random passwords for your own FTP access and database users. Make sure files that aren't supposed to be seen from the internet are not stored in directories under the web root... just generally good security practices.
I've been using php/mysql for some time, and while I've had several problems with code that accepts $_POST data, I've never had a problem with someone hi-jacking another users account. But, to cover the basics:
SSL - keeps hackers from seeing plain text sent to your server. If a hacker can see the username/password, its over. Sometimes you need this level of protection (bank accounts, stock accounts, etc), sometimes, you don't. It costs money, so you decide.
mysql_escape_strings() - never take raw user input. They can/will hack your mysql commands. Its rare, but it happens.
Read only on database - Always a good policy.
Rotating $_SESSION ID's - good in concept, but I believe a hacker can hijack the ID, then rotate the true user out of their session.
IP Tests w/ Browsers - I like to do this as I find it hard to spoof IP's and Browser signatures. Set it in the session at login, then compare it to the user's IP and Browser. I'd imagine this working extremely well with SSL. You can use this code to get a users IP address:
function get_ip()
{
if ($_SERVER['HTTP_X_FORWARD_FOR'])
{ $IP = $_SERVER['HTTP_X_FORWARD_FOR']; }
else
{ $IP = $_SERVER['REMOTE_ADDR']; }
return $IP;
}
No back doors... or at least, very cryptic back doors.
Encrypt passwords with either MD5, or some equivalent, when storing in the DB. I actually don't like MD5. I use crypt('$Password', random_string) to produce some decent encryption.
Privacy is the best policy. The more information you share, the more it will be used against you.
Other than the above, you'll be set.
SSL - keeps hackers from seeing plain text sent to your server. If a hacker can see the username/password, its over. Sometimes you need this level of protection (bank accounts, stock accounts, etc), sometimes, you don't. It costs money, so you decide.
mysql_escape_strings() - never take raw user input. They can/will hack your mysql commands. Its rare, but it happens.
Read only on database - Always a good policy.
Rotating $_SESSION ID's - good in concept, but I believe a hacker can hijack the ID, then rotate the true user out of their session.
IP Tests w/ Browsers - I like to do this as I find it hard to spoof IP's and Browser signatures. Set it in the session at login, then compare it to the user's IP and Browser. I'd imagine this working extremely well with SSL. You can use this code to get a users IP address:
function get_ip()
{
if ($_SERVER['HTTP_X_FORWARD_FOR'])
{ $IP = $_SERVER['HTTP_X_FORWARD_FOR']; }
else
{ $IP = $_SERVER['REMOTE_ADDR']; }
return $IP;
}
No back doors... or at least, very cryptic back doors.
Encrypt passwords with either MD5, or some equivalent, when storing in the DB. I actually don't like MD5. I use crypt('$Password', random_string) to produce some decent encryption.
Privacy is the best policy. The more information you share, the more it will be used against you.
Other than the above, you'll be set.
Author
Awesome guys! Some great suggestions to look into.
So far, I have the files in a location outside the webroot scope as I allready saw that this could be a massive issue in itself.
I certainly have some research to do for the session hijacking though. I might see if I can actually hijack my own session from another PC.
Interesting stuff. :)
So far, I have the files in a location outside the webroot scope as I allready saw that this could be a massive issue in itself.
I certainly have some research to do for the session hijacking though. I might see if I can actually hijack my own session from another PC.
Interesting stuff. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
