Business Logic Flaws - Logikfehler in Anwendungen

Business Logic Flaws sind die heimtückischsten Schwachstellen in Webanwendungen: Sie entstehen nicht durch fehlerhafte Programmierung (wie SQL-Injection), sondern durch inkorrekte Implementierung von Geschäftsregeln. Ein automatisierter Scanner sieht nur HTTP-Requests - er versteht nicht, dass “Bestellmenge -5” einen negativen Preis erzeugen sollte. Nur erfahrene Tester mit Verständnis des Geschäftsprozesses erkennen diese Lücken.

Kategorien und Beispiele

Kategorie 1 - Preismanipulation:

Szenario: E-Commerce mit clientseitigem Preis
  POST /cart/checkout
  {
    "item_id": "laptop_123",
    "price": 999.99,  ← Client schickt den Preis!
    "quantity": 1
  }

  Angriff: price auf 0.01 setzen
  POST /cart/checkout
  { "item_id": "laptop_123", "price": 0.01, "quantity": 1 }
  → Wenn Server den clientseitigen Preis übernimmt: Laptop für 1 Cent!

  Weitere Preismanipulationen:
  → Negative Mengen: quantity: -1 (Guthaben erhalten statt zahlen)
  → Integer-Overflow: quantity: 9999999999 (Preis überläuft zu 0)
  → Discount-Manipulation: discount_percent: 100 (kostenloses Produkt)

Kategorie 2 - Workflow-Bypass:

Szenario: Multi-Step-Checkout (3 Schritte)
  Schritt 1: Adresse eingeben → /checkout/step1
  Schritt 2: Zahlungsmittel wählen → /checkout/step2
  Schritt 3: Bestätigen → /checkout/step3

  Angriff: Direkt zu /checkout/step3 springen
  → Wenn Server keinen State validiert: Bestellung ohne Bezahlung!
  → Prüfen ob step3 ohne step2 ausführbar ist

  Typische Workflows zum Testen:
  → Passwort-Reset: Direkt zu "Neues Passwort setzen" ohne Token
  → E-Mail-Verifizierung: Account-Funktionen vor Bestätigung nutzen
  → Admin-Aktionen: Schritt "Genehmigung" überspringen

Kategorie 3 - Coupon/Gutschein-Missbrauch:

  Szenarien:
  → Einmal-Gutschein mehrfach einlösen (Race Condition!)
  → Gutschein-Code brute-forcen (kurze, vorhersagbare Codes)
  → Gutschein für andere User-Accounts einlösen (IDOR!)
  → Negativen Betrag durch Kombination mehrerer Gutscheine

  Race Condition (paralleler Einlösungs-Angriff):
  → Gleichen Gutschein-Code 100× parallel einlösen
  → Wenn keine atomare DB-Operation: mehrfache Einlösung möglich

Kategorie 4 - Privilege/Role-Verwechslung:

  Szenario: Käufer kann "Verkäufer"-Funktion nutzen
  → Profil-Endpoint: PATCH /api/user (erlaubt für eigenes Profil)
  → Feld "role" in Request mitsenden: {"role": "admin"}
  → Wenn Server role nicht aus JWT, sondern aus Body nimmt: Privilege Escalation!

  Mass Assignment (verwandtes Problem):
  → ORM/Framework übernimmt alle POST-Felder in DB-Update
  → is_admin: true, is_premium: true, credit: 10000
  → Framework setzt alle Felder automatisch!

Kategorie 5 - Geld/Kredit-Logik:

  Szenarien:
  → Auszahlung beantragen (pending) → Konto löschen → Auszahlung trotzdem?
  → Transfer an sich selbst (source_account = dest_account): Betrag verdoppelt?
  → Währungsumrechnung mit unterschiedlichen Rates ausnutzen
  → Kryptowährungs-Withdrawals mit manipulierten Dezimalstellen

Erkennung im Pentest

Business Logic Testing Methodik:

Vorbereitung (KRITISCH - Fachverständnis nötig!):
  □ Anwendung vollständig durchlaufen und verstehen
  □ Alle Transaktionsabläufe dokumentieren
  □ Preisberechnung: wo? Client oder Server?
  □ Welche Schritte gibt es? Können sie übersprungen werden?
  □ Welche User-Rollen gibt es?
  □ Wo wird Geld/Credits bewegt?

Manuelle Tests (nicht automatisierbar!):

1. Preisfelder in allen Requests identifizieren:
   → Burp Suite: Alle Requests auf "price", "amount", "cost" prüfen
   → Jeden gefundenen Preiswert manipulieren:
     - 0
     - -1
     - 0.001
     - 99999999999

2. Workflow-Mapping und Step-Skip:
   → Alle Schritte eines Workflows in Burp HTTP History tracken
   → Letzten Schritt direkt aufrufen (Referrer-Prüfung?)
   → Cookies/Sessions aus Schritt N bei Schritt N+2 einsetzen

3. Parameter-Fuzzing für Mass Assignment:
   → Known Fields: alle Felder aus Response zurück in Request
   → Sensitive Fields probieren:
     is_admin, is_premium, role, verified, credit_balance, status
   → Unterschied zwischen "Field ignored" und "Field updated"?

4. Coupon Race-Condition-Test (ethisch!):
   # Burp Suite Intruder mit Null Payload:
   # 50 parallele Requests mit gleichem Gutschein-Code
   # HTTP/2 single-packet attack (Turbo Intruder)
   # → Mehrfache Einlösung in Response-Daten erkennbar?

5. State-Manipulation zwischen Requests:
   → Zwischenzustand prüfen: Was wenn Account gelöscht wird während Transfer läuft?
   → Two-User-Test: User A und User B gleichzeitig (Transaktionsisolation?)

Tools:
  Burp Suite Pro:  HTTP History, Repeater, Intruder (Race Conditions)
  OWASP ZAP:       Kein guter BLF-Scanner (manuell bleibt Pflicht!)
  ffuf/feroxbuster: Parameter-Discovery
  BApp Store:      Turbo Intruder (Race Condition Testing)

Schutzmaßnahmen

Sichere Business-Logik-Implementierung:

1. Preise IMMER serverseitig berechnen:
   // FALSCH - Client-Preis verwenden:
   final_price = req.body.price * req.body.quantity;

   // RICHTIG - Server berechnet aus Produkt-DB:
   const product = await db.products.findById(req.body.item_id);
   const final_price = product.price * req.body.quantity;  // Immer!
   // Clientseitige Preiswerte IGNORIEREN!

2. Server-Side-State für Workflows:
   // Schritt-Validierung in Session/DB:
   if (req.session.checkout_step < 2) {
     return res.status(400).json({ error: 'Previous step not completed' });
   }
   // KEIN Vertrauen auf Referer-Header!

3. Mengen-Validierung:
   if (quantity <= 0 || quantity > MAX_ORDER_QUANTITY) {
     return res.status(400).json({ error: 'Invalid quantity' });
   }

4. Gutscheine atomar einlösen:
   -- Atomare Transaktion (PostgreSQL):
   BEGIN;
   UPDATE coupons
   SET used_count = used_count + 1
   WHERE code = $1
   AND used_count < max_uses
   AND expiry > NOW()
   RETURNING *;
   -- 0 Rows → Coupon ungültig/verbraucht → ROLLBACK
   COMMIT;
   -- "UPDATE ... WHERE" mit Bedingung ist atomar!

5. Mass Assignment verhindern:
   // Explizit erlaubte Felder (Allowlist):
   const allowedFields = ['name', 'email', 'bio'];
   const updateData = _.pick(req.body, allowedFields);
   // NIEMALS: await User.update(req.body)

6. Geld-/Credit-Transaktionen:
   → Doppeltes Buchen verhindern: Idempotency Keys
   → Idempotent-Key pro Transaktion (einmalig!)
   → Positive Balances erzwingen: CHECK CONSTRAINT balance >= 0
   → Audit-Log für alle Finanztransaktionen

7. Business-Logic-Tests in CI/CD:
   → Automatisierte Tests für negative Mengen, 0-Preise, etc.
   → Boundary-Tests für alle Geschäftsregeln
   → Berechtigungstests: User A kann nicht User B's Ressourcen nutzen