Kategorie: Cyber Security
-
SSRF verstehen – Teil 2: Praktische Beispiele aus der Praxis
Rückblick aus Teil 1 Wir haben gelernt: SSRF bedeutet, dass der Server Netzwerk-Requests im Auftrag des Angreifers ausführt.Das macht die Schwachstelle so gefährlich, weil der Server: Jetzt gehen wir ins Praktische. Beispiel 1: PHP – Bilder laden von einer URL Ein Entwickler möchte Bilder aus dem Internet einbinden: Angriff Der Angreifer ruft auf: 👉 Gefährlich,…
-
Teil 2 – Typische Beispiele für Broken Access Control
Mehr als nur IDOR Im ersten Teil haben wir gesehen, dass Broken Access Control (BAC) entsteht, wenn eine Anwendung nicht zuverlässig prüft, ob ein Nutzer für eine bestimmte Aktion berechtigt ist. Ein Spezialfall davon ist IDOR – aber BAC umfasst noch viele weitere Szenarien. In diesem Artikel schauen wir uns die typischen Formen an, die…
-
SSRF verstehen – Teil 3: Fortgeschrittene Techniken & sichere Python-Demo
Filter-Umgehungen: wie simple Checks ausgetrickst werden 1) Filter-Umgehungen in der Praxis Viele Abwehrversuche scheitern an Kleinigkeiten: a) Varianten von „localhost“ Merke: Ein String-Vergleich auf „localhost“ reicht nicht. Du musst auflösen → in IP verwandeln → IP-Ranges prüfen. b) Offene Umleitungen (Open Redirects) Selbst wenn du „nur example.com erlaubst“, aber https://example.com/go?to=http://169.254.169.254 zurück auf eine interne IP…
-
Teil 3 – Wie man Broken Access Control entdeckt
Der erste Schritt: Rollen verstehen Bevor man testet, muss man die Rollen und Berechtigungen der Anwendung kennen. Typische Rollen sind Gast, eingeloggter Nutzer, Moderator, Admin.Ein guter Test beginnt damit, alle Rollen durchzuspielen und zu notieren, welche Aktionen eigentlich erlaubt sein sollten.Das Ziel: Abweichungen finden zwischen dem, was die App vorgibt, und dem, was technisch tatsächlich…
-
Broken Access Control Teil 4 – Schutzmaßnahmen und Best Practices
Das Fundament: Zugriffskontrolle ernst nehmen Broken Access Control (BAC) zählt nicht umsonst zu den gefährlichsten Schwachstellen in den OWASP Top 10. Die gute Nachricht: Mit klaren Regeln und Best Practices lassen sich die meisten Probleme vermeiden. Entscheidend ist, Zugriffskontrolle als zentrales Thema in der Architektur zu behandeln, nicht als nachträgliches Detail. Autorisierung auf Server-Seite Die…
-
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…
-
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 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 – 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…
-
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…