Seite 6 - Security/OWASP

Cross Site Request Forgery gilt in vielen Teams als gelöstes Problem, sobald eine Anwendung auf eine Single Page Architektur mit Fetch statt klassischer Formulare umsteigt. Tatsächlich verschiebt sich das Risiko nur, sobald Session Cookies für authentifizierte API Aufrufe im Spiel sind, bleibt aber real und erfordert eine bewusste Kombination aus Double-Submit-Cookie, SameSite-Attribut und Custom Headern.

Security-Reviews scheitern selten an fehlendem Wissen, sondern an fehlender Systematik im Alltag der Pull-Request-Praxis. Dieser Artikel liefert eine konkrete Checkliste für Input-Validierung, Berechtigungsprüfungen und Output-Encoding, zeigt typische blinde Flecken bei internen und admin-only Code-Pfaden auf und erklärt, wie manuelles Review und automatisiertes Tooling sich sinnvoll ergänzen, damit Sicherheitslücken schon vor dem Merge auffallen und nicht erst im Live-Betrieb.

Kaum ein Browser-Feature wird so oft falsch eingesetzt wie die Notifications API: Ein Berechtigungsdialog direkt beim ersten Seitenbesuch führt in den allermeisten Fällen zur dauerhaften Ablehnung. Richtig eingesetzt, mit passendem Timing, klarem Kontext und Service-Worker-Integration, wird aus derselben API ein Feature, das Nutzer aktiv anfragen, statt es wegzuklicken.

HTTP Request Smuggling entsteht, wenn ein vorgelagerter Proxy oder Load Balancer und der dahinterliegende Backend-Server dieselbe HTTP-Nachricht unterschiedlich interpretieren, insbesondere hinsichtlich der Frage, wo genau ein Request endet und der nächste beginnt, wodurch ein Angreifer einen versteckten zweiten Request in die Verbindung einschmuggeln kann, der vom Backend fälschlicherweise als eigenständiger Request eines anderen, völlig unbeteiligten Nutzers interpretiert wird. Diese Schwachstellenklasse ist besonders gefährlich, weil sie nicht in der Anwendung selbst liegt, sondern in der Infrastruktur-Interaktion zwischen zwei eigentlich korrekt implementierten Komponenten.

unserialize() auf nicht vertrauenswürdige Daten anzuwenden, gehört zu den gefährlichsten Mustern in PHP-Anwendungen. Gadget Chains aus harmlos wirkenden Klassen ermöglichen Remote Code Execution allein durch das Wiederherstellen eines Objekts. JSON, allowed_classes und signierte Payloads schließen diese Lücke zuverlässig.

Log-Injection, auch Log-Forging genannt, entsteht, wenn eine Anwendung nutzergesteuerte Eingaben ungefiltert in Log-Dateien schreibt und ein Angreifer durch das gezielte Einschleusen von Steuerzeichen wie Zeilenumbrüchen (`\r\n`) einen einzelnen, eigentlich zusammenhängenden Log-Eintrag optisch und strukturell in mehrere, scheinbar eigenständige Einträge aufspaltet. Diese gefälschten Zusatzeinträge können dabei so gestaltet werden, dass sie wie legitime, harmlose Systemereignisse aussehen, wodurch tatsächlich stattgefundene, bösartige Aktivität in einer Flut gefälschter Ablenkungseinträge untergeht oder forensische Analysen nach einem Sicherheitsvorfall gezielt in die Irre geführt werden.

Wer Passwörter mit MD5 oder SHA-1 hasht, öffnet Angreifern nach einem Datenbank-Leak Tür und Tor für Brute-Force und Rainbow-Table-Angriffe. Dieser Artikel erklärt, wie bcrypt und Argon2id funktionieren, wie ihr sie mit PHP's password_hash() korrekt einsetzt und welche Fehler bei Salt, Cost-Faktor und Rehashing in der Praxis am häufigsten passieren.

Der Docker-Socket wird gern als bequemer Trick gemountet, damit ein Container selbst Container starten kann. Was dabei meist übersehen wird: Wer diesen Socket erreicht, hat faktisch Root-Rechte auf dem gesamten Host, ganz ohne --privileged.

Login-Formulare ohne durchdachten Brute-Force-Schutz gehören zu den am häufigsten ausgenutzten Einfallstoren in Magento-Shops. Dieser Artikel zeigt, wie Rate-Limiting, progressive Verzögerung, Account-Lockout und risikobasiertes CAPTCHA zusammenspielen, ohne legitime Kunden auszusperren oder die Conversion zu belasten, inklusive Magentos eingebauter Schutzmechanismen und konkreter Konfigurationsbeispiele.

Ein Webhook-Endpunkt ist per Definition öffentlich erreichbar und nimmt Daten von einem externen Dienst entgegen, ohne dass sich der klassische Login-Mechanismus der eigenen Anwendung anwenden ließe. Ohne eine kryptografische Signaturprüfung kann grundsätzlich jeder, der die URL kennt, beliebige Payloads einschleusen und dadurch fachliche Aktionen wie eine Zahlungsbestätigung oder eine Bestellstatus-Änderung auslösen. Dieser Artikel zeigt, wie man in Symfony einen dedizierten Webhook-Controller baut, eine HMAC-Signatur mit hash_hmac und hash_equals sicher gegen Timing-Angriffe prüft, wann sich die eingebaute Symfony-Webhook-Komponente eignet und wie man wiederholte Zustellungen desselben Events idempotent verarbeitet.