PHP-beveiliging uitgelegd · defensief
PHP object injection: wat het is en hoe je het oplost
Wie door gebruikers beïnvloedbare data aan unserialize() geeft, laat de aanvaller kiezen welke objecten PHP aanmaakt. De PHP-handleiding waarschuwt daar expliciet voor.
Laatst bijgewerkt
Wat het is
Bij het deserialiseren bouwt PHP de beschreven objecten na en roept mogelijk magische methoden als __wakeup() en __destruct() aan. Komt de string uit een cookie, formulierveld of API-verzoek, dan kan een aanvaller al geladen klassen van de applicatie of bibliotheken kiezen en hun methoden aan elkaar rijgen, tot bestanden schrijven of code uitvoeren toe. MITRE noemt dit CWE-502.
Zo vind je het
- Zoek in je code naar
unserialize(en volg waar elk argument vandaan komt. Elk pad vanuit$_GET,$_POST,$_COOKIE, headers, uploads of door gebruikers beschrijfbare databasevelden is een bevinding. - Controleer plug-ins van derden en oude bibliotheken op dezelfde manier; veel eerdere CMS-pluginadviezen gingen over object injection.
- Statische analyse met beveiligingsregels (PHPStan, Psalm) en dependency-audits (
composer audit) vinden bekende kwetsbare pakketten.
Zo los je het op
- Gebruik
json_encode()enjson_decode()voor data die een vertrouwensgrens passeert; JSON kan geen PHP-objecten maken. - Moet je toch
unserialize()gebruiken, geef dan['allowed_classes' => false]of een korte expliciete lijst mee. De PHP-handleiding raadt onbetrouwbare invoer ook dan af. - Onderteken serialized data die je aan de clientkant opslaat met een HMAC en controleer die vóór het decoderen.
- Houd frameworks en bibliotheken bij zodat bekende gadgetketens verdwijnen.
Alleen-lezen controles en veilige patronen
# Find unserialize() calls that may receive request data (read-only)
grep -rnE "unserialize\s*\(" --include=*.php . | grep -vE "/vendor/|/tests?/"
// Safer: exchange data as JSON
$data = json_decode($input, true, 512, JSON_THROW_ON_ERROR);
// If unserialize() is unavoidable for trusted data, forbid objects
$data = unserialize($trusted, ['allowed_classes' => false]);Is allowed_classes => false genoeg?
Het blokkeert het aanmaken van objecten en daarmee het grootste risico, maar de PHP-handleiding raadt het deserialiseren van onbetrouwbare invoer nog steeds af. JSON is de veiligere standaard.
Heeft dit met PHP2Shell te maken?
Nee. PHP2Shell is een fout in de PHP-runtime; object injection is een fout in applicatiecode en bestaat ook op volledig gepatchte PHP.
Andere PHP-kwetsbaarheidsklassen
- PHP file inclusion (LFI/RFI): wat het is en hoe je het oplostFile inclusion ontstaat wanneer gebruikersinvoer het pad voor include of require bepaalt, waardoor een aanvaller lokale bestanden leest (LFI) of, met allow_url_include aan, externe code uitvoert (RFI).
- SSRF in PHP: wat het is en hoe je het oplostServer-side request forgery (SSRF) ontstaat wanneer een PHP-app een door de gebruiker bepaalde URL ophaalt, waardoor een aanvaller via je server interne diensten of cloudmetadata-endpoints bereikt.
- XSS in PHP: wat het is en hoe je het voorkomtCross-site scripting (XSS) ontstaat wanneer een PHP-pagina door gebruikers beïnvloedbare data zonder escaping in HTML zet, zodat het script van een aanvaller in de browser van andere bezoekers draait.
- phpinfo()-blootstelling: waarom het telt en hoe je het oplostEen openbare phpinfo()-pagina verraadt de exacte PHP-versie, geladen modules, bestandspaden en vaak omgevingsvariabelen of geheimen, wat aanvallers helpt fouten als PHP2Shell gericht te misbruiken.
Bronnen
Externe links verlaten deze site. Wij hosten geen exploitcode.
- unserialize() — PHP Manual
- json_decode() — PHP Manual
- PHP Object Injection — OWASP
- CWE-502: Deserialization of Untrusted Data — MITRE CWE