Was sind Business-Logic-Schwachstellen?

Business-Logic-Schwachstellen entstehen, wenn eine Anwendung technisch gültige Aktionen zulässt, die gegen ihre fachlichen Regeln verstoßen. Der Angreifer benötigt dabei oft keine klassische Injection: Er verändert Reihenfolge, Menge, Preis, Rolle oder Zustand eines vorgesehenen Prozesses.

Wie entstehen Logikfehler?

Entwickler bilden einen erwarteten Normalablauf ab, berücksichtigen aber ungewöhnliche Kombinationen nicht. Prüfungen erfolgen nur in der Oberfläche, nur im ersten Prozessschritt oder auf einem einzelnen Microservice. Parallel laufende Requests, wiederholte Gutscheine, negative Werte oder übersprungene Freigaben bringen das System dann in einen gültig aussehenden, fachlich unerlaubten Zustand.

Welche Beispiele gibt es?

Warum finden Scanner diese Fehler selten?

Scanner erkennen bekannte technische Muster. Sie wissen aber nicht, dass ein Kunde nur einmal eine Prämie erhalten darf oder eine Auszahlung stets eine zweite Freigabe benötigt. Logikfehler verlangen Verständnis für Geschäftsregeln, Rollen, wirtschaftlichen Wert und erlaubte Zustandsübergänge. Automatisierung kann Varianten ausführen, die entscheidende Hypothese entsteht meist durch manuelle Analyse.

Wie verhindert man Business-Logic-Fehler?

• Geschäftsregeln, Invarianten, Rollen und verbotene Zustandsübergänge ausdrücklich dokumentieren.
• Alle sicherheitsrelevanten Werte serverseitig aus vertrauenswürdigen Daten berechnen.
• Jeden Schritt unabhängig autorisieren und niemals auf eine zuvor angezeigte Oberfläche vertrauen.
• Idempotenz, Transaktionen, Sperren und atomare Limits gegen Wiederholung und Race Conditions einsetzen.
• Abweichende Mengen, Preise, Reihenfolgen und Rollen in automatisierte Negativtests aufnehmen.
• Ungewöhnliche, wirtschaftlich relevante Prozessmuster überwachen.

Codebeispiel: Preise niemals aus dem Request übernehmen

Verwundbar: Der Client bestimmt Preis und Rabatt selbst.

$total = $request->integer('quantity') * $request->float('unit_price');
$total -= $request->float('discount');

Order::create(['user_id' => $request->user()->id, 'total' => $total]);

Sicherer: Produkt, Preis und Rabattregel werden serverseitig ermittelt.

$product = Product::findOrFail($request->integer('product_id'));
$quantity = max(1, min($request->integer('quantity'), 20));
$subtotal = $product->current_price * $quantity;
$discount = $couponService->calculateFor($request->user(), $subtotal);

Order::create([
    'user_id' => $request->user()->id,
    'total' => max(0, $subtotal - $discount),
]);

Auch dieses Beispiel braucht Transaktion, Idempotenz und eine atomare Einlösung des Gutscheins. Der entscheidende Punkt ist, dass der Client nur Produkt und Menge auswählt, nicht aber die wirtschaftlichen Regeln vorgibt.

Wie werden sie getestet?

Tester modellieren Akteure, Werte und Zustände und führen den Prozess zunächst regulär aus. Danach verändern sie Parameter, Reihenfolge, Rollen, Zeitpunkte, Parallelität und Abbruchpunkte. Direkte API-Aufrufe umgehen Einschränkungen der Oberfläche. Besonders ergiebig sind Rückerstattungen, Einladungen, Exporte, Genehmigungen, Kontowiederherstellung und Übergänge zwischen kostenlosen und bezahlten Funktionen.

Wie bewertet man das Risiko?

Ein ungewöhnlicher Ablauf ist erst dann eine Schwachstelle, wenn er eine fachliche Sicherheitsregel verletzt. Der Bericht sollte Voraussetzung, erreichbaren Zustand, Wiederholbarkeit und wirtschaftliche oder regulatorische Folge beschreiben. Bei massenhaftem Missbrauch sind Skalierbarkeit, Erkennbarkeit und mögliche Gesamtverluste wichtiger als der Wert einer einzelnen Testtransaktion.