LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Linux Answers > Security
User Name
Password

Notices

By Web31337 at 2010-02-02 12:04
PHP is a poweful language for developing web-sites. Many sites on the net using it as a core.

And, of course, any power can be used in both ways. When most beginner(and even not beginner already) programmers create websites with some input forms, they usually never think about security here. And that is leading to different issues later-one site gets defaced, another gets database removed/stolen, third gets rooted and so on.

If you are PHP developer there are few basic rules you should learn and apply to whatever you code(it takes your time, but in the end, it will be in your blood and chances you won't forget it next time will be a way lower).

First issue, you can meet on most working sites over the net is XSS(Cross-Site Scripting). This type of attack comes possible when there is a way to insert unescaped HTML code. It can be abused the way it will reveal site visitors cookie information(if cookies are not set with "httponly" param). This is not so dangerous on sites doesn't have any accounting system, but still it's always better to prevent that.
That is quite simple.
Filter entire user input. Don't output ANYTHING user entered in forms back on the page without proper escaping before: htmlspecialchars() and htmlentities() can do that filtering, after which you may output inputs.

Another issue is, again, caused by using unfiltered user input when dealing with files. Say, if your site allows to download some files, where name is taken from URL or some form and then is blindly passed to file reading functions, it may result in information leaks, when attacker queries for, say, /etc/passwd or site config, if he guesses it's location. He will just download the file in a plain text view.
To prevent that, again, do a filtering of user input. Accept only filenames not containing slashes and do some extra checks depending on what this system does to verify the path is valid. Do not try to solve the problem by appending something after filename, it can easily be bypassed as well. Fight with a source of problem.

There is also an attack known as SQL injection. It can be applied to your site when you don't filter user input before you pass it directly into the SQL database, if your site uses it. As a result, attacker may query or modify(depending on privileges of database user, under which site works) anything in database.
To prevent that do a filtering of input. Say, if you have URIs like /list.php?id=<some_id>, then id parameter is dangerous, when passed to database without escaping. To do escaping for MySQL do mysql_real_escape_string($id). Your final expression may look like:
Code:
$sql="SELECT `something`,`somethingelse` FROM `sometable` WHERE `id`='".mysql_real_escape_string($id)."'";
$r=@mysql_query($sql);
For postgresql it can be done the same way with pg_escape_string() function.
Do not write your own functions or try to use other solutions, probably it will fail on some stage and cause you even more troubles. Many of beginners trying to use addslashes() for this purpose-don't do that. Read the manual pages for those functions.

One more thing you should be avoid of: usage of eval() function. This function, if used with user input is absolutely uncontrollable. Ones say, if your code has eval, you are missing something in the manual. Make sure you replaced every occurance of eval() with proper safe code.

Keep in mind the common rule: you should never trust user input or expect it to be correct. Handle incorrect input in a good way, show understandable error messages, that could just be a mistype.

If you are writing opensource product, you are meant to know this by heart and never do such mistakes. It's a pity most opensource PHP applications were written by those who never read guides like this. As a result there are buggy and unsafe applications. When they are come to be used all over the world and some vulnerability gets disclosed, it's usually a big shame for creators. So, when you write any code not for yourself, write it in a secure way if you care for your reputation.

Start writing secure applications right from next time you get back to PHP programming. Even when you write something tiny, not even meant to be accessed by anyone except for you, write it keeping these rules in mind and applying them to your code.

Written by edK, 02.02.2010

You are free to copy and redistribute this text, but please, keep my name(it's not that hard, right? :) )

by rweaver on Tue, 2010-02-09 17:14
Really good article, I hope a lot of people read and follow it. The number one problem I see with php apps that get exploited is lack of sanitized inputs for databases (injection). The only thing that scares me more than unsanitized database inputs are unsanitized inputs used in system calls... someone killing the database or injecting things you don't want is bad news, someone wiping out or root kiting your server out is worse news.

by Web31337 on Thu, 2010-02-11 05:53
Oh yes, shell commands injection is the worst. I forgot to add it.
I've seen much of those vulnerabilities, but it actually points more to PHP security itself(configuring PHP), rather than coding. Of course, it's the same rule again: don't trust user inputs. But here you gotta be more restrictive, in case you allow shell_exec(), etc, you shall not pass anything taken from user input to shell at all, until you know what are you doing.
I have it disabled everywhere and I suggest everyone do the same, disable all dangerous functions of PHP. If you need shell to act in your applications, use either standalone daemon or cron, that will verify and execute pending tasks from a shared file. Be sure to apply this rule "don't trust user inputs" everywhere.

by jcelle on Tue, 2010-11-23 02:15
Really good article indeed.
For those that want to go even deeper into this subject, I suggest you get a look at OWASP (http://www.owasp.org/). Even though it is not specially for PHP, it gives good examples of what to do and what to avoid and an excellent framework for developing secure applications.
And again, DON'T TRUST USER INPUT !


  



All times are GMT -5. The time now is 09:04 AM.

Main Menu
Advertisement

My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration