Verwundbare Bankanwendung 🏦

Eine absichtlich verwundbare Webanwendung zum Üben von Anwendungssicherheitstests für Web, APIs und LLMs, für sicheres Code-Review und für die Implementierung von Sicherheit in CI/CD-Pipelines.

⚠️ WARNUNG: Diese Anwendung ist absichtlich verwundbar und sollte nur zu Bildungszwecken in isolierten Umgebungen verwendet werden.

Bild

Überblick

Dieses Projekt ist eine einfache Bankanwendung mit mehreren eingebauten Sicherheitslücken. Sie wurde entwickelt, um Sicherheitsingenieuren, Entwicklern, Praktikanten, QA-Analysten und DevSecOps-Praktikern Folgendes näherzubringen:

Häufige Webanwendungs- und API-Schwachstellen
KI-/LLM-Schwachstellen
Sichere Codierungspraktiken
Automatisierung von Sicherheitstests
DevSecOps-Implementierung

Funktionen & Schwachstellen

Kernfunktionen der Bank

🔐 Benutzerauthentifizierung & Autorisierung
💰 Kontostandsverwaltung
💸 Geldüberweisungen
📝 Kreditanfragen
👤 Profilbild-Upload
📊 Transaktionshistorie
📈 Transaktionsanalyse-Dashboard (GraphQL-gestützt)
🔑 Passwort-Reset-System (3-stellige PIN)
💳 Verwaltung von Virtual Cards in mehreren Währungen
💱 Aufladung von Virtual Cards vom USD-Hauptguthaben mit integrierter Währungsumrechnung (USD, GBP, NGN, JPY, EUR, QAR, BTC, ETH)
🛒 Öffentliche Händler-Zahlungs-API für absichtlich verwundbare E-Commerce-/Demo-Integrationen
📱 Rechnungszahlungssystem
🤖 KI-Kundensupport-Agent (echtes LLM mit DeepSeek-API / Mock-Modus)

Bild

Implementierte Schwachstellen

Authentifizierung & Autorisierung
- SQL-Injection beim Login
- Schwache JWT-Implementierung
- Gebrochene Autorisierung auf Objektebene (BOLA)
- Gebrochene Autorisierung auf Objekteigenschaftsebene (BOPLA)
- Massenzuweisung (Mass Assignment) & übermäßige Datenoffenlegung
- Schwacher Passwort-Reset-Mechanismus (3-stellige PIN)
- Token im localStorage gespeichert
- Keine serverseitige Token-Invalidierung
- Keine Sitzungsablaufzeit
Datensicherheit
- Informationsoffenlegung
- Offenlegung sensibler Daten
- Klartext-Speicherung von Passwörtern
- SQL-Injection-Punkte
- Offenlegung von Debug-Informationen
- Ausführliche Fehlermeldungen offengelegt
Transaktionsschwachstellen
- Keine Betragsvalidierung
- Überweisungen mit negativem Betrag möglich
- Keine Transaktionslimits
- Race Conditions bei Überweisungen und Kontostandsaktualisierungen
- Informationsoffenlegung der Transaktionshistorie
- Keine Validierung der Empfängerkonten
Dateioperationen
- Uneingeschränkter Datei-Upload
- Path-Traversal-Schwachstellen
- Keine Dateitypvalidierung
- Verzeichnis-Traversal
- Keine Dateigrößenlimits
- Unsichere Dateibenennung
- Server-Side Request Forgery (SSRF) über URL-basierten Profilbild-Import
Sitzungsverwaltung
- Token-Schwachstellen
- Keine Sitzungsablaufzeit
- Schwache geheime Schlüssel
- Token-Offenlegung in URLs
Client- und serverseitige Fehler
- Cross Site Scripting (XSS)
- Cross Site Request Forgery (CSRF)
- Unsichere direkte Objektreferenzen
- Kein Rate Limiting
Schwachstellen bei Virtual Cards
- Massenzuweisung bei Kartenlimit-Updates
- Massenzuweisung bei der Wechselkurs-Behandlung der Kartenaufladung
- Vorhersehbare Kartennummerngenerierung
- Klartext-Speicherung von Kartendetails
- Keine Validierung von Kartenlimits
- BOLA bei Kartenoperationen
- Race Conditions bei Kontostandsaktualisierungen
- Offenlegung von Kartendetails
- Keine Transaktionsverifizierung
- Fehlende Überwachung der Kartenaktivität
- Vom Client gesteuerte Währungsumrechnung bei der Kartenaufladung
Schwachstellen bei Rechnungszahlungen
- Keine Validierung der Zahlungsbeträge
- SQL-Injection bei Biller-Abfragen
- Informationsoffenlegung im Zahlungsverlauf
- Vorhersehbare Referenznummern
- Offenlegung der Transaktionshistorie
- Keine Validierung der Biller-Konten
- Race Conditions bei der Zahlungsabwicklung
- BOLA beim Zugriff auf den Zahlungsverlauf
- Fehlende Zahlungslimits
Schwachstellen der Händler-Zahlungs-API
- Klartext-Händlerpasswörter und API-Schlüssel
- API-Schlüssel werden in Registrierungs- und Login-Antworten zurückgegeben
- Rohe Kartennummern/CVV werden von Händler-Zahlungs-APIs akzeptiert
- SQL-Injection-anfällige Händler- und Kartenabfragen
- Fehlende Idempotenz, fehlender Replay-Schutz, fehlende Zahlungslimits und fehlendes Rate Limiting
- Lücken in der Autorisierung auf Objektebene bei der Händlerzahlungs-Abfrage
- Detaillierte Zahlungsablehnungsgründe und Offenlegung von Debug-Daten
- Vorhersehbare Generierung von Autorisierungscodes
Schwachstellen des KI-Kundensupports

Prompt-Injection (CWE-77)
KI-basierte Informationsoffenlegung (CWE-200)
Gebrochene Autorisierung im KI-Kontext (CWE-862)
Offenlegung von KI-Systeminformationen (CWE-209)
Unzureichende Eingabevalidierung für KI-Prompts (CWE-20)
Direkter Datenbankzugriff durch KI-Manipulation
KI-Rollenüberschreibungs-Angriffe
Kontextinjektions-Schwachstellen
KI-unterstützter unbefugter Datenzugriff
Offengelegte KI-Systemprompts und -konfigurationen

GraphQL-Schwachstellen

Aktivierte Schema-Introspektion am Transaktionsanalyse-Endpunkt
Schwache JWT-basierte Authentifizierung, die von /graphql übernommen wird
SQL-Injection bei der Konstruktion von GraphQL-Resolver-Abfragen
Fehlende GraphQL-Tiefen-/Komplexitätskontrollen
Offenlegung roher GraphQL-Fehler
Offenlegung der Transaktionsanalyse über Admin-bereichsbezogene Abfragen

Installation & Einrichtung 🚀

Voraussetzungen

Docker und Docker Compose (für die Container-Einrichtung)
PostgreSQL (bei lokaler Ausführung)
Python 3.9 oder höher (für die lokale Einrichtung)
Git

Option 1: Mit Docker (empfohlen)

Mit Docker Compose (am einfachsten)

Repository klonen:

git clone https://github.com/Commando-X/vuln-bank.git
cd vuln-bank

Anwendung starten:

docker-compose up -d --build

Die Anwendung ist unter http://localhost:5000 erreichbar.

Wiederherstellungsverhalten des Containers

Das Docker-Setup enthält einige betriebliche Schutzmechanismen, damit sich die App ohne manuellen SSH-Eingriff erholen kann:

web und db verwenden restart: unless-stopped, sodass Docker sie automatisch neu startet, falls der Prozess beendet wird.
db verfügt über einen Health Check, und web wartet auf die PostgreSQL-Bereitschaft, bevor es startet.
web führt den Flask-Entwicklungsserver mit debug=True aus (beabsichtigt — erhält die Trainingsszenarien, die auf den Werkzeug-Debugger abzielen).
web stellt GET /healthz bereit, damit der Container melden kann, ob die App und die Datenbank tatsächlich nutzbar sind.

Dies hält das absichtlich verwundbare Anwendungsverhalten intakt und macht den Container-Lebenszyklus gleichzeitig widerstandsfähiger.

Lokaler Smoke-Test

Sie können die lokale Laufzeit-Verdrahtung validieren, ohne echte Container zu starten:

python3 -m unittest discover -s tests -v

Beliebteste

vuln-bank