PHP-Sicherheit erklärt · defensiv
PHP Object Injection: was es ist und wie Sie es beheben
Wer benutzerkontrollierte Daten an unserialize() übergibt, lässt den Angreifer bestimmen, welche Objekte PHP erzeugt. Das PHP-Handbuch warnt genau davor.
Zuletzt aktualisiert
Worum es geht
Beim Deserialisieren baut PHP die beschriebenen Objekte nach und ruft eventuell magische Methoden wie __wakeup() und __destruct() auf. Stammt der String aus einem Cookie, Formularfeld oder API-Request, kann ein Angreifer bereits geladene Klassen der Anwendung oder ihrer Bibliotheken wählen und deren Methoden verketten, bis hin zu Dateischreibzugriff oder Codeausführung. MITRE führt das als CWE-502.
So finden Sie es
- Suchen Sie im Code nach
unserialize(und verfolgen Sie die Herkunft jedes Arguments. Jeder Weg aus$_GET,$_POST,$_COOKIE, Headern, Uploads oder von Nutzern beschreibbaren Datenbankfeldern ist ein Befund. - Prüfen Sie Drittanbieter-Plugins und alte Bibliotheken ebenso; viele frühere CMS-Plugin-Hinweise betrafen Object Injection.
- Statische Analyse mit Sicherheitsregeln (PHPStan, Psalm) und Abhängigkeitsprüfungen (
composer audit) finden bekannte verwundbare Pakete.
So beheben Sie es
- Nutzen Sie
json_encode()undjson_decode()für Daten über Vertrauensgrenzen hinweg; JSON kann keine PHP-Objekte erzeugen. - Wenn
unserialize()unvermeidbar ist, übergeben Sie['allowed_classes' => false]oder eine kurze explizite Liste. Das PHP-Handbuch rät trotzdem von nicht vertrauenswürdigen Eingaben ab. - Signieren Sie clientseitig gespeicherte serialisierte Daten per HMAC und prüfen Sie die Signatur vor dem Dekodieren.
- Halten Sie Frameworks und Bibliotheken aktuell, damit bekannte Gadget-Ketten verschwinden.
Lesende Prüfungen und sichere Muster
# 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]);Reicht allowed_classes => false?
Es verhindert die Objekterzeugung und damit das Hauptrisiko, doch das PHP-Handbuch rät weiterhin vom Deserialisieren nicht vertrauenswürdiger Eingaben ab. JSON ist der sicherere Standard.
Hat das mit PHP2Shell zu tun?
Nein. PHP2Shell ist ein Fehler in der PHP-Laufzeit, Object Injection ein Fehler im Anwendungscode, der auch auf vollständig gepatchtem PHP besteht.
Weitere PHP-Schwachstellenklassen
- PHP File Inclusion (LFI/RFI): was es ist und wie Sie es behebenFile Inclusion entsteht, wenn Benutzereingaben den Pfad für include oder require steuern; Angreifer lesen dann lokale Dateien (LFI) oder führen bei aktivem allow_url_include entfernten Code aus (RFI).
- SSRF in PHP: was es ist und wie Sie es behebenServer-Side Request Forgery (SSRF) entsteht, wenn eine PHP-App eine vom Benutzer gesteuerte URL abruft, sodass Angreifer über Ihren Server interne Dienste oder Cloud-Metadaten-Endpunkte erreichen.
- XSS in PHP: was es ist und wie Sie es verhindernCross-Site Scripting (XSS) entsteht, wenn eine PHP-Seite benutzerkontrollierte Daten ohne Escaping in HTML ausgibt, sodass das Skript eines Angreifers im Browser anderer Besucher läuft.
- phpinfo()-Offenlegung: warum sie zählt und wie Sie sie behebenEine öffentliche phpinfo()-Seite verrät die genaue PHP-Version, geladene Module, Dateipfade und oft Umgebungsvariablen oder Geheimnisse, was Angreifern hilft, Fehler wie PHP2Shell gezielt auszunutzen.
Quellen
Externe Links verlassen diese Website. Wir hosten keinen Exploit-Code.
- unserialize() — PHP Manual
- json_decode() — PHP Manual
- PHP Object Injection — OWASP
- CWE-502: Deserialization of Untrusted Data — MITRE CWE