17
It's the most insecure code in the world
Just the Gist
A not uncommon criticism of PHP is that it lacks in security. The sad part is, we can't argue against it. It's too broad of a criticism which can be leveraged against most languages, as most have some way a secret can be leaked. Modern PHP and modern coding practices exists to mitigate this. But today, we are going to take a look at one very basic security flaw example, and a way we could mitigate it. It's what could happen if we don't run a web server but still have our php-files public.
Say that we have an index.php
located in a public-folder. This file is protecting the identity of the secret santa until Christmas Day. It may look like this:
<?php
define('SECRET_SANTA', "Olaf ⛄");
?>
<!DOCTYPE html>
<html lang="en">
<body>
<h1>The Secret Santa is a secret!</h1>
<p>You have to wait until Christmas Day to know who it is.</p>
<?php
$today = new DateTime("now");
$christmas = new DateTime("2021-12-25");
if ($today >= $christmas) {
echo "<p>The Secret Santa is " . SECRET_SANTA . "!</p>";
} else {
echo "<p>The Secret Santa is still a secret.</p>";
}
?>
</body>
</html>
As long as we have a web server service active (such as Apache), this will be interpreted correctly and we would have the following output:
But what would happen if the service was down and we had visitors to the website? Instead of parsing the PHP file and rendering the correct output, we would serve the file as simple text. All our code would be visible and any one could see that it's Olaf! 😱
So how could we protect ourselves from this happening? We could move our secrets out of the public folder (or the web-root) and into a folder that is not accessible by visitors. Say that we have the following structure:
/
|-- public-folder
| |-- index.php
|
|-- private-folder
|-- SecretSanta.php
Our visitors would be unable to see the contents of the SecretSanta.php
file, but they would be able to see the index.php
file. So here's how we could do this.
SecretSanta.php
<?php
class SecretSanta
{
private const SECRET_SANTA = 'Olaf ⛄';
public static function getSecretSanta(): bool|string
{
if ((new DateTime("now")) >= new DateTime("2021-12-25")) {
return self::SECRET_SANTA;
} else {
return false;
}
}
}
This class declares a constant with the identity of the Secret Santa. It's private so no other file has access to it. We must use the static function getSecretSanta()
to access the secret santa. This function will return the secret santa if it's on or after Christmas Day, otherwise it will return false
.
Going back to the index.php
file, we can now get the secret santa by calling the static function on the class (SecretSanta::getSecretSanta()
):
<?php
require('../private/SecretSanta.php');
?>
<!DOCTYPE html>
<html lang="en">
<body>
<h1>The Secret Santa is a secret!</h1>
<p>You have to wait until Christmas Day to know who it is.</p>
<?php
if (SecretSanta::getSecretSanta()) {
echo "<p>The Secret Santa is " . SecretSanta::getSecretSanta() . "!</p>";
} else {
echo "<p>The Secret Santa is still a secret.</p>";
}
?>
</body>
</html>
We would still get the same output as before when the web server service is running, but now we can see that the secret santa is not visible to the public if the service is down. This is but one example of how it may be a good idea to have your application logic and secrets outside of the public folder.
There is so much more to keep track of when it comes to security. This article hasn't covered even a fraction of it. And many of the issues are not specific to PHP. There are Cross Origin Resource Forgery (CSRF) attacks, SQL Injection, Cross Site Scripting (XSS), and many more.
Perhaps you have some good insight into good security practices within the PHP ecosystem, please share! Have you encountered projects with bad security? What are your best security recommendations to web developers building their first couple of PHP projects? Comment below and let us know what you think ✍
- PHP Manual on Security: https://www.php.net/manual/en/security.php
- Zend on how to handle security risks: https://www.zend.com/blog/managing-security-risks-php-engine-and-web-applications
17