Autor: Stefan
-
Teil 4 – Template Injection und LDAP Injection
Weniger bekannt, aber brandgefährlich Wenn es um Injection geht, denken viele sofort an SQL. Doch moderne Anwendungen nutzen längst nicht mehr nur relationale Datenbanken – sie arbeiten mit Template-Engines für dynamische Inhalte oder mit Verzeichnisdiensten wie LDAP. Genau dort entstehen neue Angriffsflächen. Zwei besonders spannende Varianten sind Server-Side Template Injection (SSTI) und LDAP Injection. Sie…
-
Teil 3 – Command Injection und NoSQL Injection
Zwei Seiten derselben Medaille Injection ist nicht auf Datenbanken beschränkt. Überall dort, wo Eingaben eines Nutzers direkt in Befehle oder Abfragen einfließen, kann es gefährlich werden. Zwei besonders relevante Varianten sind Command Injection (Angriffe auf Betriebssystembefehle) und NoSQL Injection (Angriffe auf moderne Datenbanken wie MongoDB). Beide zeigen: Injection ist ein grundsätzliches Designproblem – wenn Daten…
-
Insecure Design Teil 4 – Schutzmaßnahmen und Best Practices
Sicherheit von Anfang an denken Das zentrale Problem von Insecure Design ist, dass Sicherheitslücken schon im Bauplan entstehen. Der beste Schutz besteht also darin, Sicherheit frühzeitig in den Entwicklungsprozess zu integrieren – nicht erst kurz vor dem Release. Das Prinzip dahinter heißt Security by Design. Prinzipien für sicheres Design 1. Security by Default Ein System…
-
Teil 3 – Wie man Insecure Design erkennt
Warum Erkennen so schwierig ist Bugs wie SQL Injection oder XSS lassen sich oft durch automatisierte Scanner entdecken. Insecure Design dagegen ist schwerer zu fassen – es geht nicht um eine fehlerhafte Codezeile, sondern um grundsätzliche Architekturentscheidungen.Das bedeutet: Um Insecure Design zu erkennen, muss man verstehen, wie das System funktionieren soll – und was passieren…
-
Teil 2 – Typische Beispiele für Insecure Design
Ein Blick in die Realität Insecure Design klingt theoretisch – aber in der Praxis begegnet man diesen Fehlern ständig. Es sind oft keine komplizierten Exploits, sondern simple Architekturentscheidungen, die von Anfang an unsicher waren. Hier ein paar typische Szenarien, die zeigen, wie vielfältig Insecure Design auftreten kann. Fehlende Rollen- und Rechtekonzepte Ein häufiges Problem: Systeme…
-
Teil 3 – Fehler bei der Speicherung sensibler Daten
Wenn Daten im Schrank statt im Tresor landen Verschlüsselung ist wie ein Tresor: Sie schützt Daten, selbst wenn jemand in den Raum eindringt. Leider werden viele sensible Informationen nicht im Tresor abgelegt, sondern einfach im Schrank – leicht zugänglich für jeden, der vorbeikommt. Genau das passiert, wenn Anwendungen Daten im Klartext oder mit schwacher Kryptografie…
-
Teil 1 – Was sind Cryptographic Failures?
Wenn der Tresor nutzlos wird Stell dir vor, ein Unternehmen bewahrt Millionen Kundendaten in einem Tresor auf – aber der Schlüssel liegt direkt daneben oder der Tresor hat gar keine Tür. Genau so verhält es sich in der IT, wenn Verschlüsselung falsch eingesetzt oder ganz vergessen wird.Das Ergebnis: sensible Daten liegen offen, auch wenn eigentlich…
-
Cryptographic Failures Teil 5 – Ausblick und weiterführende Ressourcen
Kryptografie als Fundament Kryptografie ist eines der zentralen Fundamente moderner IT-Sicherheit. Sie schützt Passwörter, Kommunikationswege, Zahlungsinformationen und vertrauliche Daten. Doch sie ist kein Selbstläufer: Schon kleine Fehler im Einsatz oder Management machen selbst starke Algorithmen wertlos. Genau das sind Cryptographic Failures. Warum Cryptographic Failures bleiben werden Auch 2025 gehören kryptografische Fehler zu den OWASP Top…
-
Teil 4 – Schlüsselmanagement und organisatorische Fehler
Der Schlüssel neben dem Tresor Ein Tresor ist nur so sicher wie die Art, wie man den Schlüssel aufbewahrt. Wenn der Schlüssel direkt daneben hängt, nützt die beste Tür nichts. Genauso verhält es sich mit Kryptografie: Selbst die stärkste Verschlüsselung ist wertlos, wenn Schlüsselmanagement versagt. Harcoded Keys im Quellcode Einer der häufigsten Fehler: Entwickler speichern…
-
Race Conditions Teil 3 – Reale Beispiele und Auswirkungen
Von der Theorie zur Praxis Race Conditions sind nicht nur ein theoretisches Problem aus Lehrbüchern. Immer wieder sorgen sie in der Praxis für erhebliche Schäden – von doppelten Banküberweisungen bis hin zu Millionenverlusten in E-Commerce-Systemen. Besonders spannend: Viele der bekanntesten Fälle wurden in Bug-Bounty-Programmen entdeckt, was zeigt, wie real und aktuell das Problem ist. Beispiel…