As per PHP.net manual on unserialize
( http://php.net/manual/en/function.unserialize.php ) and after few google search found - unserialize
code can be exploited.
I don't have much information about on how hackers can exploit unserialize
code. I am just scared, since I am using unserialize code that is coming from external user input.
Below is my code, I want to know if this code can be exploited:
<?php
if(filter_var($_GET['url'], FILTER_VALIDATE_URL)) {
// $_GET['url'] = 'http://example.com/page/1.html'
$html = file_get_contents($_GET['url']);
$doc = new DOMDocument();
$encode = mb_convert_encoding($html, 'HTML-ENTITIES', "UTF-8");
libxml_use_internal_errors(true);
$doc->loadHTML($encode);
libxml_clear_errors();
$nodes = $doc->getElementsByTagName('title');
$title = strtolower($nodes->item(0)->nodeValue);
// storing in mysqli database
// hiding mysql code..
$serialize = serialize(['icon' => 'check', 'data' => $title]);
// fetching from mysqli database.
// hiding other mysql code..
$row = $fetch->fetch_assoc();
$unserialize = unserialize($row['title']);
}
Can hacker craft "malicious title" tag and provide his URL to exploit my unserialize code?
Update: I am using PDO
for mysql, that is not problem. My concern is about unserialize code that is coming from external website title
html tag, for which I have no control.
If an attacker is able to somehow get a specifically crafted string directly into your database, perhaps through a secondary, unrelated vulnerability, then unserialize
ing that string while you fetch it from the database can lead to an object/code injection.
You can only trust the data you're unserialising if you're sure you have also serialised it yourself before. Now, how can you be sure that the data you fetch from the database has been serialised by a trusted party before? This depends on the entire rest of the system offering no exploitable way for an attacker to bypass serialisation. Essentially, you cannot be sure who has serialised the data that's in your database. Tiny missing sanity check over here plus harmless looking code over there can in combination lead to a vulnerability.
The better solution is to use an exploit-free data format like JSON. It purely describes data, and there's no chance to inject anything code-related into it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With