I am somewhat new to PHP coding and I am aware that malicious users can hack a website if you have not sanitized your PHP code. What I am wondering is whether they need a data entry box (like for file submissions, or user-name/password entry fields)?. Do commands like "include (header.php)" also need some sort of security or are they innately safe?
+36
A:
Just like any other language, PHP code is as secure as the programmer writes it.
Also like any other language, individual (and even common) security risks are too numerous and detailed to include in a StackOverflow answer.
Find a book which covers Secure PHP coding.
Steven
2009-10-06 18:07:39
+1, many people think PHP is an insecure language because lots of insecure code has been written using PHP. This is because PHP has a fairly mild initial learning curve, which gives insecure programmers the chance to spit out some insecure code. Also, PHP is pretty widely deployed, which gives it a greater statistical chance of having insecure programmers pick it up for a project.
snicker
2009-10-06 19:34:38
for a book on PHP security - I'd recommend "Essential PHP Security" by Chris Shiflett (http://oreilly.com/catalog/9780596006563/) - its pretty comprehensive, and shows that it isn't actually difficult to follow good, secure, code practices.
HorusKol
2009-10-07 02:45:23
+18
A:
Don't trust the user.
include "a/literal/file.php";
is quite safe
include $someFile;
means you want to think about how $someFile gets set. If you use any data that was given to you by a user to set $someFile's value, you'd better sanitize it.
timdev
2009-10-06 18:10:04
... and if you need to select an include based on user input, always create a list of includes you know are valid and secure, then match user input to a value on that list - and only use the safe list value itself for the include.
Ilari Kajaste
2009-10-13 08:52:46
+3
A:
PHP is as secure as anything. But not by default, it relies on the skills of the programmer. Unlike .NET which tends to help out with security by default.
Includes are safe just be careful if the paths are being dyanmically generated.
The below is harmless (depending on the code in myfile.php)
include("mypath/myfile.php");
Andi
2009-10-06 18:10:24
A:
Your question is rather broad and general but to address a specific point you made:
include (header.php);is relatively safe but
include ($header);is potentially a dangerous security hole depending on how $header was assigned and if it's been sanitized.
Asaph
2009-10-06 18:11:34
A bigger advantage of the former is that you don't have to look any further - it is locally secure. (As someone who has to do auditing on a fairly large codebase, that's important to me.)
Tom Hawtin - tackline
2009-10-08 03:29:19
A:
To answer the question specifically, PHP as a language is very secure. For the language itself, it is recommended that you use the latest stable build to keep on top of language-based security. The php maintainers are the ones that create and fix bugs ;)
Citizen
2009-10-06 20:38:59
+2
A:
Agree with everyone here - PHP is not really more or less secure in and of itself than any other language.
You should look deeply into your php.ini file though. You should probably learn about all of the directives. This is where a lot of people make mistakes early on.
thewebguy
2009-10-07 01:39:44
+2
A:
Regarding data entry boxes, one should be concerned about SQL injection attacks, overflow, bad chars, etc. Check out functions like filter_var(), mysql_real_escape_string(), pg_escape_string() for starters.
Bill Hoag
2009-10-07 20:34:17
+2
A:
To quote RSnake from a sla.ckers.org post back in 2006:
I thought what was interesting is that Stefan Esser retired from the PHP incident response team. Not to start a religious war on the boards, but it's interesting that the founder of PHP's security response team is fed up with the lack of security in PHP and quit as a result. His site is down at the moment (traffic flood?): [blog.php-security.org] So here is a cut and paste of the cache:
Saturday, December 9. 2006
Last night I finally retired from the PHP Security Response Team, that was initially my idea a few years ago.
The reasons for this are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the security of PHP itself you become persona non grata. I stopped counting the times I was called immoral traitor for disclosing security holes in PHP or for developing Suhosin.
For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.
Posted by Stefan Esser in PHP, Security at 10:58
Well, scary as that sounds, I am really excited to finally get the "real deal" on PHP security. I've always been a little wary of it and it will be interesting to see what Stefan has to say.
source: http://sla.ckers.org/forum/read.php?2,3976
Which introduces nicely the Hardened PHP project, Suhosin http://www.hardened-php.net/suhosin/ and Esser's Month of PHP Bugs project http://www.php-security.org/
Cheekysoft
2009-10-14 16:17:22