Home » Php » security – How secure is PHP?

security – How secure is PHP?

Posted by: admin April 23, 2020 Leave a comment

Questions:

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?

How to&Answers:

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.

Answer:

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.

Answer:

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/

Answer:

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");

Answer:

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.

Answer:

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.

Answer:

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.

Answer:

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 😉