I was having a casual chat with a friend the other day who is a tech lead on a successful startup, and while we were watching the Olympics final of women's water polo, we started talking about a PHP fail I found in the wild 🤓. Him being a tech lead and me being a mid-dev, I was expecting him to have already tackled this fail in his everyday grind, but well... as surprising as it sounds he hadn't.
The "fail" I am talking about, and you probably have already guessed it, is nothing else but PHP's loose comparison. Now, to be fair, I wouldn't really call it so much of a fail, but a feature, but its usage can be so dangerous that, in that sense, it's a fail! Let's get our nerd on!
Table of contents
- PHP Loose Comparison
- Vulnerable Scenarios
- Mitigating the loose comparison bug
- Conclusion
- Show love @Sudorealm
PHP Loose Comparison
Loose comparison in PHP is when you compare two values using the == operator, which does not check the data types of the variables being compared. PHP will try to convert the values to a common type before comparing them.
if ('string' == true){
echo 'Weedle I choose you';
}
else{
echo 'Charizard I choose you';
}
Believe it or not, we are about to send a 3-level Weedle into battle here, while our Charizard remains unused. WHY? Well, in the example above, PHP converts the string 'string' to true before comparing it with true, leading to a true comparison 🥴. This behavior, while sometimes useful, can be dangerous if not properly understood and controlled.
Check this Loose Comparisons Table from the PHP Docs for more information
It might not seem as much at first, but trust me to a trained developer's eye this out of nowhere trick might send shivers to their bones and send them to a production code refactoring spree.
Vulnerable Scenarios
In this section of the article, I'll try to give out some code blocks that when found in the wild could get you a handsome bug bounty reward, also if you find anything remotely similar to your codebase... change it 😁
The insecure login system
In the snippet below you see a very basic login system logic.
$username = $_POST['username'];
$password = $_POST['password'];
if ($username == 'admin' && $password == '12345') {
// Grant access
}
Let's say that a crafty hacker tampers with the sent data and makes them: $_POST['username'] = true and $_POST['password'] = true that will result to:
$username = $_POST['username'];
$password = $_POST['password'];
if (true == 'admin' && true == '12345') {
// Grant access
}
# Now that hacker has been granted access to our App... Good for him, not for us
If you are wondering how a hacker could tamper with our data, I have two answers for you from the top of my head:
- Custom request with curl.
- Burpsuite
Moving on.
The insecure authorization with a twist
Here is where I showcase a problem with PHP that might shock you.
$user_role = $_POST['user_role']; // Example: 'admin', 'editor', 'viewer'
// Authorization check using a switch statement
switch ($user_role) {
case 'crazyDifficultAdminRoleNooneWouldEverGuess':
// Admin privileges
echo "Access granted: Super Admin level";
break;
case 'editor':
// Editor privileges
echo "Access granted: Editor level";
break;
case 'viewer':
// Viewer privileges
echo "Access granted: Viewer level";
break;
default:
// No access
echo "Access denied: Invalid role";
break;
}
This code is already vulnerable to data tampering as hackers could guess the roles and change theirs to access different levels of authorization.
We might feel a bit safe though, because they would never be able to guess our Super Admin role name.
But what if they don't have to guess at all?☠️
Did you know that Switch Case uses loose comparison? Ha! you might be shocked now!
This means that if the Hacker adds $_POST['user_role'] = true then they will access our first case in our switch statement no matter the value. Ain't that a pain in the bottom? Read the docs.
Mitigating the loose comparison bug
Mitigating the loose comparison bug is critical in ensuring the security and reliability of your PHP applications. The use of strict comparison === and the match expression, in PHP versions 8.0+, plays a vital role in this process. Unlike the loose comparison operator ==, which can lead to unexpected and potentially dangerous results due to PHP's type juggling, strict comparison ensures that both the value and the type of variables are checked. This eliminates vulnerabilities such as unintended type coercion, which could be exploited to bypass security checks.
Here is a solution to the Insecure authorization bug using match expression:
$user_role = $_POST['role'];
$response = match ($user_role) {
'crazyDifficultAdminRoleNooneWouldEverGuess' => "Access granted: Super Admin level",
'editor' => "Access granted: Editor level",
'viewer' => "Access granted: Viewer level",
default => "Access denied: Invalid role",
};
echo $response; # This outputs: 'Access denied: Invalid role' when role is set to true
Conclusion
Did you know about the dangers of loose comparison and type juggling in PHP? If you didn’t, now you do. Let this simple article serve as a reminder to always read through the documentation and develop a solid understanding of everything you use when programming. Curiosity is key when you’re striving to become the best at whatever you do!
By embracing the strict discipline of === and the sharp precision of match, you can keep your PHP code on a tight leash, ensuring it behaves exactly as you expect. Remember, a little strictness now can save you a lot of headaches later. Let this be a playful nudge that no matter where you are on your coding journey, there’s always something new to learn. So, keep those eyes open, stay curious, and don’t let those loose comparisons slip through the net! 🫡
About Me
You can find out more about me in my personal blog space on sudorealm.com.
If you like my style of writing and my content do not hesitate to whack that follow button, and magical things will happen! 🪄💫
Top comments (5)
By default all $_POST, $_GET and $_REQUEST arrays have string values, so unless you are performing some custom casting on them, there is no way for them to have boolean value.
Better example would be, if credentials were transmitted in JSON, then types can be easily manipulated.
There is always the possibility of a hacker getting in the middle by using BurpSuite and changing the
$_GETvariable totrue. This is where all the problems begin :PBurpSuite sends ordinary HTTP requests and can do nothing to change PHP's $_GET / $_POST population logic.
Can you display a POC which can prove your words?
Great post! PHP's loose comparison has always been a bit of a headache, especially when it leads to unexpected behavior. Have you ever encountered any real-world scenarios where this caused a critical issue?
If you use old version of php and compare e.g. hash via
==3v4l.org/BJ6b8