Business-Logic-Angriffe erklärt

Angreifer brechen nicht immer Ihren Code, um Geld zu stehlen.

Viele Entwickler verbringen Monate damit, APIs und Verschlüsselungen abzusichern. Sie konzentrieren sich darauf, SQL-Injection oder XSS zu verhindern. Dann stiehlt ein Angreifer Gelder, ohne eine einzige Sicherheitskontrolle zu umgehen.

Das ist ein Business-Logic-Angriff.

Die Anwendung funktioniert exakt so, wie sie konzipiert wurde. Der Angreifer nutzt einfach Ihre eigenen Regeln gegen Sie.

Denken Sie an einen Banktresor. Die meisten Sicherheitstests prüfen, ob die Tür stabil ist. Das Testen der Geschäftslogik stellt eine andere Frage: Was passiert, wenn jemand den Wachmann davon überzeugt, ihm die Tür zu öffnen?

Der Tresor funktioniert. Der Prozess versagt.

Hier sind drei Wege, wie Angreifer die Banklogik missbrauchen:

  1. Umgehen von Wartezeiten Banken verlangen oft eine 24-stündige Wartezeit, nachdem ein neuer Empfänger hinzugefügt wurde. Dies verhindert schnellen Diebstahl. Ein Angreifer könnte einen API-Endpunkt finden, der diese Prüfung überspringt. Er umgeht die Einschränkung der Benutzeroberfläche und überweist Geld sofort.

  2. Durchbrechen von Transaktionslimits Eine Bank legt vielleicht ein tägliches Limit von 50.000 fest. Wenn der Code jede Transaktion nur einzeln prüft, kann ein Angreifer fünf Überweisungen von jeweils 49.000 senden. Jede Transaktion sieht gültig aus. Die Gesamtsumme überschreitet das Limit, aber das System bemerkt es nicht.

  3. Missbrauch von Belohnungen Viele Apps gewähren Cashback für Rechnungszahlungen. Ein Angreifer könnte eine Rechnung bezahlen und diese dann sofort wieder stornieren. Wenn das System die Belohnung nicht zurückfordert, erzeugt der Angreifer eine Endlosschleife, um unendlich viel Cashback zu sammeln.

Warum übersehen automatisierte Scanner das?

Scanner suchen nach technischen Schwachstellen wie Malware oder Injection. Ein Scanner sieht eine erfolgreiche Überweisung und gibt den Status 200 OK zurück. Er denkt, alles sei in Ordnung.

Ein menschlicher Tester fragt: Hätte diese Überweisung überhaupt stattfinden dürfen?

Um diese Schwachstellen zu finden, hören Sie auf zu fragen, ob eine Funktion gehackt werden kann. Fangen Sie an zu fragen, ob eine Funktion missbraucht werden kann.

Prüfen Sie diese Bereiche:

  • Können Benutzer Verifizierungsschritte überspringen?
  • Können Benutzer den Besitz einer ID ändern?
  • Können Wartezeiten über die API umgangen werden?
  • Werden Limits für den Gesamtbetrag durchgesetzt oder nur pro Klick?
  • Können Belohnungen mehrfach ausgelöst werden?

Elite-Sicherheitsteams erstellen nicht nur Use Cases. Sie erstellen Abuse Cases.

Anstatt „Benutzer überweist Geld“ zu testen, testen Sie „Angreifer versucht 500 kleine Überweisungen, um Limits zu umgehen“.

Die zweite Frage deckt das wahre Risiko auf.

Quelle: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj