Seite 11 - Security/OWASP

Wer unserialize auf nicht vertrauenswürdige Eingaben wie Cookies, Sitzungsdaten oder API Payloads anwendet, öffnet die Tür für PHP Object Injection und gefährliche Gadgetketten, die über magische Methoden wie wakeup und destruct beliebigen Code ausführen können. Dieser Artikel erklärt die Mechanik, zeigt sichere Alternativen wie json_decode und beschreibt bewährte Deserialisierungsmuster für produktive PHP und Magento Anwendungen.

Wer eigene PHP-Anwendungen ohne Symfony oder Laravel betreibt, muss CSRF-Schutz selbst bauen. Mit random_bytes für die Token-Generierung, hash_equals für den zeitkonstanten Vergleich und einer sauberen Session-Bindung lässt sich ein robuster CSRF-Schutz in wenigen Zeilen PHP umsetzen, ganz ohne fremde Abhängigkeit.

Ein Docker-Image besteht aus vielen Schichten fremden Codes: der Basis-Distribution, systemweiten Paketen, Sprachlaufzeiten und Anwendungsabhängigkeiten. In jeder dieser Schichten können bekannte Schwachstellen stecken, ohne dass ein Entwickler jemals eine Zeile davon selbst geschrieben hat. Automatisiertes Image-Scanning in der CI/CD-Pipeline macht diese Schwachstellen sichtbar, bevor ein Image überhaupt in Richtung Produktion gebaut wird, und verhindert so, dass bekannte Lücken unbemerkt live gehen.

Environment-Variablen trennen Konfiguration von Code, doch derselbe Mechanismus, der Secrets flexibel macht, macht sie auch angreifbar. Erreichbare phpinfo()-Aufrufe, ins Docker-Image gebackene Zugangsdaten und ungeschützte env.php-Dateien zählen zu den häufigsten Ursachen für Datenlecks in PHP- und Magento-Projekten. Dieser Artikel zeigt konkrete Gegenmaßnahmen für Docker, CI/CD und Magento.

XML-Parser mit aktivierter externer Entity-Verarbeitung lassen sich für Dateizugriff oder SSRF missbrauchen. Wir zeigen, wie XXE funktioniert, warum viele moderne XML-Bibliotheken das standardmäßig deaktiviert haben, und wie DOMDocument in PHP explizit abgesichert wird.

Ein Upload-Formular ist eine der direktesten Angriffsflächen einer PHP-Anwendung, weil ein Angreifer hier eigenen Inhalt kontrolliert auf den Server bringt. Wer sich allein auf die Dateiendung oder den vom Client gesendeten Content-Type verlässt, öffnet die Tür für Remote Code Execution, Path Traversal und eingeschleuste Skriptdateien, die als harmlose Bilder getarnt sind.

Sobald eine Claude Anwendung fremde Inhalte verarbeitet, seien es Nutzerdokumente, Webseiten oder E-Mails, entsteht eine neue Angriffsflaeche: eingebettete Anweisungen, die versuchen, das eigentliche Systemverhalten zu ueberschreiben. Prompt Injection ist damit kein theoretisches Randproblem, sondern ein konkretes Sicherheitsrisiko fuer jede produktive KI-Integration.

Ein Cookie-Consent-Banner wird in vielen Projekten einmalig eingerichtet, optisch abgenommen und danach kaum noch als eigenständiger, testwürdiger Funktionsbereich betrachtet, obwohl genau dieser Bereich einen unmittelbaren rechtlichen Bezug hat: Ladet ein Tracking-Skript trotz aktiv abgelehnter Zustimmung, handelt es sich nicht um eine kosmetische Kleinigkeit, sondern um einen tatsächlichen Verstoss gegen die Datenschutz-Grundverordnung mit möglichen Bussgeldfolgen. Ein automatisierter E2E-Test, der verschiedene Consent-Zustände gezielt simuliert und das tatsächliche Laden von Tracking-Skripten je nach Zustand überprüft, macht diese rechtlich relevante Funktionalität ebenso zuverlässig regressionssicher wie jeden anderen kritischen Geschäftsprozess im Shop.

Das klassische Netzwerk-Perimeter-Modell beruht auf einer einfachen, aber zunehmend fragwürdigen Annahme: Was innerhalb der Firewall liegt, gilt als vertrauenswürdig, was außerhalb liegt, muss sich beweisen. Sobald ein Angreifer diesen äusseren Perimeter einmal überwindet, etwa durch einen kompromittierten Laptop im Homeoffice oder ein gestohlenes VPN-Zertifikat, bewegt er sich oft nahezu ungehindert im internen Netzwerk. Zero-Trust-Architektur verwirft diese Annahme vollständig zugunsten des Prinzips never trust, always verify, bei dem jede einzelne Anfrage unabhängig von ihrer Herkunft neu geprüft wird.

chroot ist eines der ältesten Isolationswerkzeuge unter Unix und gleichzeitig eines der am meisten missverstandenen. Wer eine Jail-Umgebung aufbaut, um einen Prozess vom Rest des Dateisystems abzuschotten, muss genau verstehen, was chroot tatsächlich absichert und wo diese Absicherung endet, denn viele Server wurden schon über eine als sicher geglaubte chroot-Umgebung kompromittiert.