Serializing in PHP is a way of converting a PHP object into a string. This string can be used in various ways, such as storing it in a database or passing it to another function. The PHP documentation says this is handy when passing PHP values around without losing their type and structure. But I have never had that problem before. Maybe I’m not seeing it.
<?php
$test = new User();
$test->name = "Denzyl";
echo serialize($test);
/// Output: O:4:"User":1:{s:4:"name";s:6:"Denzyl";}
So, let's digest the string. The o stands for Object, and the following number is the length of the object's name. The two letters s stand for string and the length of the string's name.
When you need to convert the string back into PHP, call the unserialize function and pass the string as a parameter.
When serializing an object, two methods are automagically being called. __serialize() & __sleep(). This will allow the class author to do something before converting the object into a string.
That is straight to the point. But for now, let’s focus on unserializing the string. This means converting the string into a real PHP object that can be later used at runtime in your PHP code.
<?php
$string = 'O:8:"User":1:{s:4:"name";s:6:"Denzyl";}';
echo unserialize($string)->name;
/// Output: Denzyl
The same functionalities also apply to unserializing. But this time, the two methods are __unserialize() and __wakeup().
But why is it a bad idea?
Using unserialize without knowing it can lead to remote code execution. That's why they say never to trust input.
Let's say you are lazy and you trust a random input, and you concatenate to the serialized object so you can
change a value inside the object. BOOM, you can be hacked.
<?php
$username = $_GET['username'];
$serialized = 'O:8:"User":1:{s:4:"name";s:6:"' . $username . '";}';
I won't explain how to write an exploit for something like this. Some tools can automatically generate a payload for you, and you can call yourself a script kiddie(we all start somewhere). The one I know is PHPGGC.
To understand the exploit, you can read the OWASP article.
If you didn't know this before, also read the rest of the OWASP articles about vulnerabilities
I know I haven't explained how to write an exploit. I don't think I can do a better job than the articles on the internet. But now you know this, and you can do your research.
How to prevent being exploited?
Why would you want to use this? I do not know; I haven't been programming long enough(~15 years) to have the opportunity to solve a problem using serialize/unserialize.
My solution is too drastic. The simple answer is. Don't use it in my PHP projects.
This article is part of a series of articles in my journey of writing a static analysis tool for PHP that can scan massive projects in a couple of minutes/seconds. And look for rules
that the developers want to have in their projects. At the time of writing this article, I'm working on a rule to stop
people from using unserialize, and it should be ready for the next release. Follow the project so that you will get notified when
I decided to write even more rules.
Top comments (3)
I've never used serialisation. I can't see how for any normal use case it's any better than using JSON or something, and I've seen enough databases with serialised fields to know how much of a pain it is when you need to do something like search and replace a value in an SQL dump because of the presence of those length values.
That last example is indeed a bad way to use serialized values. The problem already exists by using the get value with no validation.
When your application code does the serializing and unserializing, for example to get it in and out a database, I don't see a problem with using the feature.
A way to save storage in the database is to use json_encode on the object and then you get
{"name":"Denzyl"}. Most databases now have json column types where you can query the json string, so that is another bonus.But if you decide you always want to use the object, the code can benefit from a serialized string. For example return type hinting.
The default value for that column/value will be
O:4:"User":0:{}I don't dismiss any feature of php flat out, not even goto. You always should be suspicious of data that comes from outside of your application, that is your first defense.
I think one case where it's useful is job queues, where you want to store a bunch of jobs to be processed asynchronously in redis or rabbitMQ. It might be more performant to directly store the whole job object with its dependencies, ready to be processed.This is what Laravel does by default.