Kategorie: Websecurity
-
Teil 1 – Was ist Injection?
Ein einfacher Gedankentrick Stell dir vor, du gehst in ein Restaurant und bestellst: „Einmal Pizza Margherita.“ Der Kellner schreibt das auf. Alles normal.Jetzt stell dir vor, du sagst: „Einmal Pizza Margherita und öffne die Kasse.“ Der Kellner führt beides aus – weil er deine Bestellung nicht von echten Befehlen unterscheiden kann.Genau das ist Injection in…
-
Teil 2 – SQL Injection (SQLi)
Der Klassiker unter den Web-Schwachstellen SQL Injection gehört zu den bekanntesten und gefährlichsten Sicherheitslücken überhaupt. Bereits seit Ende der 1990er-Jahre taucht sie in Angriffen auf – und bis heute findet man sie in modernen Web-Apps, APIs und sogar mobilen Anwendungen. Der Grund: SQL-Datenbanken sind das Rückgrat vieler Systeme, und fehlerhafte Abfragen öffnen Hackern Tür und…
-
Teil 5 – Schutzmaßnahmen & Best Practices
Das gemeinsame Muster aller Injection-Arten Ob SQL, Command, NoSQL, Template oder LDAP Injection – das Grundproblem ist immer gleich: Nutzereingaben werden nicht als Daten behandelt, sondern als Befehle interpretiert.Die wichtigste Lehre lautet also: Trenne strikt zwischen Daten und Code. Parametrisierung ist der Goldstandard Die sicherste Methode gegen Injection ist die Verwendung von parametrisierten Abfragen oder…
-
Teil 5 – Ausblick und weiterführende Ressourcen
Insecure Design bleibt ein Dauerproblem Insecure Design ist nicht so „sichtbar“ wie ein klassischer Bug – kein Syntaxfehler, keine offene Datenbank. Es ist subtiler: Die Lücken stecken im Bauplan selbst.Genau deshalb bleibt es ein Dauerproblem: Solange Teams Sicherheit nur als „Add-on“ betrachten, schleichen sich falsche Annahmen in Architektur und Prozesse ein. Häufige Missverständnisse Bei Insecure…
-
Teil 1 – Was ist Insecure Design?
Ein Haus mit falschem Bauplan Stell dir vor, du planst ein Haus. Die Türen sind stabil, die Fenster sind sicher, aber der Architekt hat vergessen, eine Wand zwischen Garage und Schlafzimmer einzuzeichnen. Egal wie solide die Handwerker später bauen – jeder, der durch die Garage kommt, steht plötzlich direkt im Schlafzimmer.Genau so ist es mit…
-
Teil 2 – Typische Fehler bei der Transportverschlüsselung
Wenn Daten auf der Reise abgehört werden Stell dir vor, du schickst einen Brief mit wichtigen Informationen – aber statt ihn zu versiegeln, steckst du ihn einfach offen in den Umschlag. Jeder Postbote kann mitlesen.Genauso unsicher ist es, wenn eine Anwendung sensible Daten ohne Transportverschlüsselung überträgt. HTTP statt HTTPS Noch immer gibt es Login-Seiten oder…
-
Teil 1 – Was sind Race Conditions?
Wenn zwei gleichzeitig losrennen Stell dir vor, zwei Personen wollen denselben Sitzplatz im Kino reservieren. Beide klicken fast zeitgleich auf „Buchen“. Das System prüft bei beiden: „Platz noch frei?“ – und bestätigt. Erst danach wird die Buchung gespeichert. Ergebnis: Zwei Leute haben denselben Platz.Das ist eine Race Condition: Ein Fehler, der entsteht, wenn mehrere Aktionen…
-
Teil 1 – Was sind Prototypen? (Das Fundament für Prototype Pollution)
Warum dieses Fundament so wichtig ist Vielleicht hast du schon von „Prototype Pollution“ gelesen und gedacht: Das klingt kompliziert. Der Knackpunkt: Ohne ein solides Verständnis von Prototypen in JavaScript bleibt die Schwachstelle wirklich abstrakt. Deshalb starten wir ganz von vorne – so, dass du auch ohne Vorwissen in JavaScript mitkommst. Am Ende dieses Beitrags wirst…
-
Teil 2 – Wie HTTP Request Smuggling funktioniert
Rückblick: Die Grundlage In Teil 1 haben wir HTTP Request Smuggling als eine Art „Missverständnis“ zwischen Proxy und Backend erklärt. Der Angreifer baut seinen Request so, dass Proxy und Backend unterschiedlich interpretieren, wo der Request endet – und dadurch wird ein zweiter Request eingeschleust. Jetzt gehen wir tiefer rein: Die beiden Stars: Content-Length & Transfer-Encoding…
-
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…