ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
For a couple of weeks I've been working in a php web site, and now it's almost ready for production.
The site has some sections with authenticated access, so from the beggining I decided to pay attention to security.
These are the main points I tried to pay special attention. I'd like to know if I'm missing something or any tip which could help to improve security, so opinions or advices will be very appreciatted.
1) Log in form data are sent through TLS, for not to send them in plain text.
2) Form info is validated in order to minimized possibilities of sql injection. Validation is done via regex and php functions.
3) Some of the site's forms generate a random MD5 hash and send it through POST and SESSION method so the "target" php script can validate the origin of those data checking if both methods contain the same data.
4) Passwords are stored ecnrypted in a mysql table.
5) Configuration and classes php scripts are located outside the web public dir (outside DocumentRoot).
And any directory of the website has an index.php script to redirect to home page in order no to list directory content.
One of my doubts is the following:
Once an authorized user is logged a session variable is setted: $_SESSION['uuid'] which contains a user id number, that is stored in authusers table.
Access to restricted areas of the sites relies in that Session variable.
As I read in some articles that session ID could be hijacked, specially if the site runs in a shared server (this will be this case).
Are there any extra practice for trying to minimize this risk?
Having confidential data on a shared server is risky. I would not rely on PHP's safe mode to prevent the others from reading your files. There has been lots of bugs in it, and I wouldn't be surprised if more show up. Also, many shared servers also allow Perl and CGI which has no such mechanism. These scripts can often read anything the web server has read access to, including your files. I think that's why the safe mode is deprecated. It gives people a false impression of security. And the servers have administrators and backups which you also trust. You not only trust that they don't read your files, but also that they don't change the configuration of the server. So avoid shared servers if you can.
In addition, I would look for use of the eval function in the PHP code. Be very careful if you use it. If other people can pass data that ends up in the eval function, be super strict when validating it. If not, they can run code on the server.
Also, don't use variables in include/require statements. Most servers deny external references in include and require, but don't rely on it.
I'd better use htmlentities function? Ou could use both?
Guttorm, thanks. I know in this case shared server is Achilles' heel for this case. I understand, for a really critical application a dedicated server would be the best solution.
For this application, data stored in database is not so critical (no credit cards, no private or classified personal info involved). I'm wondering about security as a way of learning to focus on php security.
I didn't understand the use of eval function... would it be to construct prepared statements? Or is for another use? Would you please provide me an example?
I found this article http://www.tuxradar.com/practicalphp/10/0/0, and started reading. Seems very usefull on how session works.
I red sessions ids were stored by PHP within /tmp dir, but really I didn't find anything in /tmp dir. May be that changed in newers versions. I'm testing my site in a virtualized Debian running apache and php (5.3).
Another thing you could use is session_regenerate_id() as soon as the user has been authenticated, you could setup session_set_save_handler() to save the session info in a database rather than the default on disk, and use htmlentities for data being retrieved from the database and sent back to a user to be displayed in their browser, not when you are inserting the data into the database and you could use a salt when hashing your passwords.