2

I am working on a website which is having Admin panel along with the website.

Website Root Folder: /htdocs

Other public content of the website is in /htdocs folder only.

Admin website folder: /htdocs/admin

My Question: What are the things I need to do to make sure that my admin panel (or website) is secure from attacks?

These are the things I am doing:

  1. Every file in /htdocs/admin folder is set as permission: 444 (r--r--r--) of Linux.
  2. adminLogin.php file in admin folder is using POST method to send the credentials to the validateCredentials.php which will direct to adminHome.php upon correct username and password. The following session variable is set (along with others) on a successful login: $_SESSION['usertype'] = "admin";
  3. All other files in admin folder have a check at the top of the file for a valid admin SESSION variable. If there is no session variable, then page will redirect to adminLogin.php
  4. Password of administrator is stored as a MD5 hash in admin_login_details table. This table is in the same database as the whole of the site. I got this question to make password storing even more secure.
  5. While verifying the password from the admin_login_details table, the entered password is first passed to mysql_real_escape_string() and then used -- to prevent SQL Injection.

What else is needed? Are the above points correct? If there anything which is potential security concern?

Please add more points if required.

I am using PHP, MySQL, Apache on CentOS server.

Community
  • 1
  • 1
sumit
  • 9,757
  • 23
  • 63
  • 80

2 Answers2

3

It seems as though you are on the right track, but there are a few things I can note right off the bat:

  1. MD5 is a poor choice for "securing" the password. MD5 is more accurately classified as a hashing algorithm, and not intended for a means of encryption. At the very least, salt the password before hashing it. Even better, select an actual encryption algorithm and salt it as well.

  2. POST is not any more secure than GET. It is still possible to manipulate POST data; thus this shouldn't be a form of security. Ensure that ALL data coming from a user is considered untrusted, and is sanitized appropriately.

  3. I see you're at least attempting to sanitize the password input. As aforementioned, this is not enough. You need to sanitize EVERYTHING.

We can't really say much else without looking at the site/code, but in short: Sanitize your input!

Julio
  • 2,076
  • 3
  • 28
  • 56
  • Thanks for your answer Louis. What is sanitizing? Do you mean that I should apply `mysql_real_escape_string` function everytime? What are the sanitizing methods (or functions). Any keywords, links that would help my search? – sumit Dec 05 '11 at 16:51
  • 1
    @iSumitG sanitization means removing any unnecessary, and possibly malicious data from any information coming from the user. mysql_real_escape_string, while somewhat useful for mitigating SQL injections, doesn't stop all of them as Rook has pointed out. You also need to consider things liks Cross-Site Scripting (XSS), Directory Traversals, Cross-Site Forgery Requests, etc. Basically, make sure that the data you're receiving is the data you're expecting. – Julio Dec 05 '11 at 16:59
2

There is still plenty of room here to hang your self. You have only provided a loose list of security measures.

A few things to keep in mind. The header() function modifies http headers, it cannot be used to prevent access to a file. Make sure you die() after a redirect:

header("location: index.php");
die();

mysql_real_escpae_string() does not prevent all sql injection. However parametrized query libraries like PDO and MySQLi do. This query is vulnerable to sql injection:

$q="select * from user where id=".mysql_real_escape_string($_GET['id']);

PoC: ?id=sleep(30)

Also make sure you read the owasp top 10. I bet money that you haven't even addressed owasp a9.

rook
  • 62,960
  • 36
  • 149
  • 231
  • Thank Rook. Now I am using `if($_SESSION['type'] == "admin"){ ..protected content.. } else { header("Location: adminlogin.php"); die(); }` Is this fine and secure now? – sumit Dec 05 '11 at 19:05