Kategorie: Websecurity
-
Teil 3 – Reale Beispiele und Auswirkungen von HTTP Request Smuggling
Warum reale Beispiele so wichtig sind HTTP Request Smuggling klingt abstrakt, solange man nur über Header wie Content-Length und Transfer-Encoding spricht. Erst wenn man sieht, was damit in echten Anwendungen passiert, versteht man das volle Risiko: Session-Hijacking, Cache Poisoning, Umgehung von Sicherheitsmechanismen – alles ist möglich. Beispiel 1: Session Hijacking Szenario Eine App prüft Nutzer-Logins…
-
Teil 4 – Schutzmaßnahmen und Best Practices gegen HTTP Request Smuggling
Warum Prävention so schwierig ist HTTP Request Smuggling (HRS) entsteht durch uneinheitliche Interpretationen von HTTP-Requests zwischen Proxy/Load Balancer/CDN und Backend.Das bedeutet: Ein Patch im Backend allein reicht nicht. Ein Proxy allein kann auch nicht alles verhindern. Alle Glieder der Kette müssen dieselben Regeln haben. Wir gehen Schritt für Schritt durch, wie man HRS in den…
-
Teil 5 – Ausblick & Ressourcen zu HTTP Request Smuggling
Warum HTTP Request Smuggling ein Dauerbrenner bleibt Viele Sicherheitslücken verschwinden mit der Zeit, wenn Technologien veralten. HTTP Request Smuggling (HRS) dagegen ist seit fast 20 Jahren bekannt – und immer noch hochaktuell. Warum? Häufige Missverständnisse „Das betrifft nur alte Server.“ Falsch. Selbst 2022 und 2023 wurden neue Smuggling-Bugs in modernen Proxies und CDNs gefunden. „Wir…
-
Teil 1 – Was ist HTTP Request Smuggling?
Wenn zwei Poststellen durcheinanderkommen Stell dir vor, du schickst einen Brief über eine Zwischenstelle an die eigentliche Post. Wenn du einen Brief mit genau zwei Leerzeilen schreibst, denkt die Zwischenstelle: Alles gut, ein Brief. Die Hauptpost aber liest: Moment, da sind zwei Briefe! – und verarbeitet den zweiten Brief als eigenständige Sendung. Das ist im…
-
Teil 1 – Was ist Local File Inclusion (LFI)?
Ein Einstieg mit einer Analogie Stell dir vor, du bist in einer großen Bibliothek. Normalerweise gehst du zur Ausleihtheke und sagst dem Bibliothekar: „Bitte, ich hätte gerne das Buch Geschichte der Stadt.“ Der Bibliothekar schaut in einer Liste, greift ins richtige Regal und bringt dir das gewünschte Buch. Jetzt stell dir aber vor, der Bibliothekar…
-
Teil 2 – Wie funktioniert LFI technisch?
Rückblick: Was wir schon wissen In Teil 1 haben wir LFI als „zu gutgläubigen Bibliothekar“ beschrieben: Eine Anwendung lädt jede Datei, die der Nutzer angibt. Wir haben gesehen, dass Angreifer mit ../ im Pfad Dateien außerhalb des vorgesehenen Verzeichnisses öffnen können – z. B. /etc/passwd. Jetzt schauen wir genauer: 1. Die gefährlichen Funktionen In vielen…
-
Teil 3 – Reale Beispiele und Auswirkungen von LFI
Warum Praxisbeispiele so wichtig sind Theorie ist gut – aber erst in der Praxis zeigt sich, wie mächtig und gefährlich LFI wirklich ist. Viele Bug-Bounty-Reports und CVEs belegen: Mit einem simplen ../ im Pfad haben Angreifer Zugriff auf sensible Daten oder übernehmen ganze Systeme. 1. Klassiker: /etc/passwd Was ist das? Auf Unix/Linux-Systemen enthält /etc/passwd eine…
-
LFI: Teil 4 – Schutzmaßnahmen gegen LFI und Best Practices
Rückblick: Das Problem Wir haben gesehen, dass LFI entsteht, wenn Anwendungen unkontrolliert Dateien anhand von Benutzereingaben laden. Die gute Nachricht: Mit den richtigen Maßnahmen lässt sich LFI zuverlässig verhindern. 1. Niemals direkte Includes aus Benutzereingaben Das ist der Kernfehler: Angreifer haben hier freie Hand. Besser: Whitelisting 2. Mapping statt Dateinamen Noch besser: Arbeite gar nicht…
-
Teil 5 – Ausblick & Ressourcen zu Local File Inclusion (LFI)
Warum LFI ein Dauerproblem bleibt Viele halten LFI für eine „alte PHP-Schwachstelle“. Doch die Realität zeigt: LFI ist bis heute aktuell. Warum? LFI vs. RFI – der kleine, aber feine Unterschied Warum RFI seltener ist Warum LFI trotzdem gefährlicher sein kann LFI als Sprungbrett 1. Informationslecks 2. Remote Code Execution 3. Privilegienausweitung Zukunft von LFI…
-
OWASP Top 10 – Teil 6: Vulnerable and Outdated Components
Was bedeutet „Vulnerable and Outdated Components“? Fast jede moderne Anwendung nutzt Bibliotheken, Frameworks und externe Komponenten.Wenn diese Teile veraltet sind oder bekannte Sicherheitslücken enthalten, wird die gesamte Anwendung angreifbar – auch wenn der eigene Code fehlerfrei ist. Beispiel:Eine Web-App läuft mit einer alten Version von jQuery, die für XSS-Angriffe anfällig ist. Schon allein dadurch können…