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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
$sql="SELECT `something`,`somethingelse` FROM `sometable` WHERE `id`='".mysql_real_escape_string($id)."'";
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.
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.
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 !