Pentest einer Banking-App | Testkonto- und Zahlungsmissbrauch

Was dies für Ihren Test bedeutet

Ein Penetrationstest einer Banking-App muss der Customer Journey über das Gerät, den Identitätsdienst und die Backend-API hinweg folgen. Berücksichtigen Sie Kontowiederherstellung, Geräteanmeldung, Änderungen von Zahlungsempfängern und Zahlungsfreigaben. Bereiten Sie passende Rollen für Kunden und Mitarbeitende vor, damit die Prüfung zwischen einer zulässigen Aktion und einem Fehler bei Besitz- oder Freigabeprüfungen unterscheiden kann.

Ein Bankvorgang. Mehrere Sicherheitsgrenzen.

Ein Penetrationstest einer Banking-App ist eine autorisierte Sicherheitsprüfung der mobilen oder webbasierten Anwendung einer Bank und der unterstützenden Backend-Services. Dabei wird untersucht, ob jemand auf Informationen anderer Kunden zugreifen, eine Sitzung missbrauchen oder eine Aktion außerhalb seiner Berechtigungen ausführen kann. Der vereinbarte Umfang kann Retail Banking, Geschäftskundenbanking oder eine bestimmte Produktversion umfassen.

Atlant Security verbindet Tests mobiler Anwendungen mit den Berechtigungen von Kunden, Mitarbeitenden und Diensten hinter den einzelnen Nutzungsvorgängen. Die praktische Frage lautet: Kann der Server die Regeln der Bank weiterhin durchsetzen, wenn dem Client, dem Gerät oder der Sitzung nicht mehr vertraut werden kann?

Beginnen Sie mit Ihren Plattformen, Kundenrollen und kritischen Arbeitsabläufen. Wir leiten daraus einen Vorschlag für den Prüfungsumfang, die Betriebsbedingungen und die Ergebnisse ab.

Was ein Penetrationstest einer Banking-App abdecken kann

Wählen Sie die Kanäle und Workflows aus, die geprüft werden sollen. Ein iOS-Build, ein Android-Build und eine gemeinsame API sind eigenständige Testoberflächen; die Einbeziehung eines davon schließt die anderen nicht automatisch ein.

Für einen Auftrag, der ausschließlich APIs umfasst, siehe Penetrationstests für digitales Banking und APIs. Für umfassendere Szenarien zu Vier-Augen-Prinzip, Zahlungsfreigabe und Abstimmung siehe Tests von Zahlungsabläufen.

Wie wir Mobile- und Onlinebanking testen

01 / Freigabe und Testbedingungen vereinbaren

Anwendungskennungen, Build-Nummern, unterstützte Betriebssysteme, API-Versionen und Umgebungsunterschiede dokumentieren. Kundenrollen, sensible Abläufe, zulässige Techniken, Ratenbegrenzungen und Ansprechpersonen für einen Teststopp festlegen. Vereinbaren, ob Quellcode, ein Test-Build oder bereitgestellte Zugangsdaten verfügbar sind und wie diese Unterstützung dokumentiert wird.

02 / Kunden und Kommunikation untersuchen

Das bereitgestellte App-Paket prüfen und das Verhalten auf vereinbarten Geräten beobachten. Lokale Datenverarbeitung, Plattformfunktionen und Datenverkehr zu autorisierten Diensten untersuchen. Wenn App-Härtung die Beobachtung einschränkt, sollte der Prüfungsansatz vorab vereinbart werden. Ein Umgehungsversuch in einem modifizierten Test-Build wird nicht als nachgewiesene Umgehung des Produktions-Builds dargestellt.

03 / Die Regeln der Bank serverseitig überprüfen

Führen Sie repräsentative Abläufe mit getrennten Testidentitäten durch. Vergleichen Sie erlaubte und verweigerte Vorgänge über Konten, Rollen und Transaktionszustände hinweg. Validieren Sie relevante Schwachstellen manuell und bestätigen Sie Zustandsänderungen durch unabhängiges Auslesen oder einen vereinbarten Auditdatensatz. Tool-Ausgaben allein belegen keine geschäftlichen Auswirkungen.

04 / Berichten, beheben und erneut testen

Erläutern Sie den nachgewiesenen Zugriff, die wirksamen Kontrollen und die nicht getesteten Bereiche. Besprechen Sie die Ergebnisse mit den verantwortlichen Teams und testen Sie vereinbarte Korrekturen anschließend anhand des geänderten Builds und der Backend-Version erneut. Release-Termine, Zeitfenster für Wiederholungstests und Abhängigkeiten sind Teil des Angebots.

Beispiel: Änderung des Zahlungsempfängers nach der Genehmigung

Beispielhaftes Testdesign, kein Kundenergebnis. Ein Geschäftskunde im Bankwesen erstellt eine synthetische Zahlung an einen freigegebenen Testbegünstigten. Ein zweiter autorisierter Benutzer genehmigt sie. Bei der Prüfung wird kontrolliert, ob spätere Änderungen des Begünstigten oder Betrags diese Genehmigung ungültig machen und die vorgesehene erneute Autorisierung erfordern.

• Ausgangspunkt: Getrennte Maker- und Checker-Identitäten, eine vorbereitete Zahlung und eine Testumgebung ohne Abwicklung.
• Erwartetes Ergebnis: Der Server weist eine nicht autorisierte Änderung zurück oder versetzt den Auftrag zurück in den entsprechenden Genehmigungsstatus.
• Nachweise: App- und API-Versionen, Identität und Rolle, Zeitstempel, bereinigte Anfragen und Antworten, resultierender Transaktionsstatus sowie relevante Audit-Ereignisse.
• Einschränkung: Die Änderung eines Entwurfs belegt nicht, dass Gelder freigegeben werden können. Die Abwicklung bleibt deaktiviert; eine nachgelagerte Signaturgrenze wird nur geprüft, wenn dies genehmigt ist.

Dieser Ansatz liefert den Engineering- und Risikoteams einen Befund, den sie validieren können, ohne einen erreichbaren Bildschirm, eine erfolgreiche Antwort und eine abgeschlossene Zahlung miteinander zu verwechseln.

Was Ihr Team erhält

• Managementbewertung: die getesteten Bankabläufe, geschäftlichen Auswirkungen, wirksamen Kontrollen und vorrangigen Entscheidungen.
• Abdeckungsnachweis: Anwendungen, Builds, Rollen, APIs, Umgebungen, Annahmen, Ausschlüsse sowie blockierte oder unvollständige Arbeiten.
• Technische Feststellungen: betroffene Assets, Voraussetzungen, reproduzierbare Beobachtungen, geschwärzte Nachweise, Begründung des Schweregrads und Grenzen des Ergebnisses.
• Leitlinien zur Behebung: Sofortmaßnahmen, nachhaltige Korrekturen und Abnahmekriterien für das zuständige Entwicklungs- oder Plattformteam.
• Ergebnisse vereinbarter Nachtests: geänderte Versionen, wiederholte Testfälle und bestätigte Feststellungen: behoben, teilweise behoben, weiterhin offen oder nicht erneut getestet.

Sehen Sie sich die Berichtsergebnisse an oder werfen Sie einen Blick in den fiktiven Bericht der Megabank AG. Das Beispiel veranschaulicht das umfassendere Berichtsformat für Banken; es ist kein Nachweis für eine reale Prüfung des Mobile-Bankings.

Den Umfang eines App-Tests vorbereiten

Für Ihre erste Anfrage genügt eine allgemeine Beschreibung. Nutzen Sie den RFP-Generator, um Systeme, Ziele und Zeitplan zu skizzieren, oder senden Sie über das Kontaktformular ein bestehendes Briefing zusammen mit einer NDA zur Prüfung. Vereinbaren Sie einen sicheren Übertragungsweg, bevor Sie Builds, Zugangsdaten oder sensible Architekturangaben weitergeben.

• Plattformen und Version: iOS, Android, Webbanking, Build-Versionen und geplanter Release- oder Prüfungstermin.
• Nutzungspfade: Onboarding, Anmeldung, Kontowiederherstellung, Kontozugriff, Verwaltung von Zahlungsempfängern, Überweisungen, Freigaben und weitere kritische Funktionen.
• Rollen: Privatkunden, Geschäftsanwender, delegierte Benutzer, Genehmiger, Supportrollen und repräsentative Testbeziehungen.
• Abhängigkeiten: API-Dokumentation, Identitätsanbieter, Zahlungs-Sandboxes, Zuständigkeit Dritter und erforderliche Genehmigungen.
• Betriebsbedingungen: Umgebung, synthetische Daten, zulässige Methoden, Befugnis zum Abbruch, Überwachungskontakte und Bereinigung.
• Ergebnisse: Zielgruppe des Berichts, Erörterung der Behebung, Bedarf an Nachtests sowie gegebenenfalls erforderliche Zuordnungen für Beschaffung oder Vertrauensnachweise.

Dauer und Gebühren hängen von der Anzahl der Builds und Rollen, der Komplexität der Workflows, der API-Abdeckung, den Zugriffsregelungen und den Berichtsanforderungen ab. Eine eng umrissene Release-Prüfung und ein vollständiger Umfang für Mobil- und Webanwendungen erfordern unterschiedlichen Aufwand. Diese Annahmen vereinbaren wir vor der Angebotserstellung.

Erstellen Sie eine detaillierte Leistungsbeschreibung oder senden Sie Ihr RFP und fügen Sie eine NDA bei.

Fragen zum Banking-App-Pentest

Umfasst das Testen von Mobile-Banking-Apps auch Backend-APIs?

Der Umfang sollte die API-Vorgänge umfassen, die zur Prüfung der vereinbarten mobilen Nutzungspfade erforderlich sind; die genauen Dienste und Endpunkte sind im Leistungsumfang festzuhalten. Weitere API-Bestände, interne Mitarbeitersysteme und andere Kanäle erfordern separate Umfangsentscheidungen. Allein die Prüfung der App-Binärdatei kann nicht belegen, wie der Server jede Berechtigung durchsetzt.

Können Sie sowohl iOS als auch Android bewerten?

Ja. Geben Sie bei der Anfrage zum Leistungsumfang beide Plattformen an. Gemeinsame Produktfunktionen bedeuten nicht, dass plattformspezifische Speicherung, Berechtigungen, App-Verknüpfungen und Härtung identisch sind. Im Angebot werden die Builds sowie die Geräte- oder Betriebssystemabdeckung dokumentiert.

Können Tests in der Produktionsumgebung durchgeführt werden?

Nur unter ausdrücklich vereinbarten Bedingungen. Für zustandsändernde Zahlungsszenarien ist eine repräsentative Umgebung ohne tatsächliche Zahlungsabwicklung hilfreich. Arbeiten in der Produktionsumgebung erfordern eine schriftliche Genehmigung, kontrollierte Identitäten und Daten, betriebliche Grenzen sowie eine klar definierte Befugnis zum Abbruch. Der Bericht hält Abweichungen fest, aufgrund derer ein Ergebnis aus der Staging-Umgebung nicht ohne Weiteres auf die Produktion übertragen werden kann.

Benötigen Sie Quellcode oder Testkonten?

Repräsentative Konten machen Tests von Rollen und Kundengrenzen in der Regel aussagekräftiger. Quellcode und ein instrumentierbarer Build können bei bestimmten Fragestellungen hilfreich sein, sind jedoch Optionen für den Leistungsumfang. Das Angebot unterscheidet zwischen nicht authentifizierten, authentifizierten und unterstützten Arbeiten und hält fest, was ohne den angeforderten Zugriff nicht geprüft werden kann.

Ist dies dasselbe wie ein Pentest eines Banknetzwerks?

Nein. Dieser Service verfolgt kundenorientierte Anwendungsabläufe vom Gerät oder Browser bis zu den unterstützenden APIs. Eine Banknetzwerk- und Identitätsprüfung untersucht Infrastruktur und interne Vertrauenspfade. Beide können kombiniert werden, wenn das Ziel beides erfordert.

Wann sollten wir einen Penetrationstest für eine Banking-App anfordern?

Planen Sie frühzeitig, damit Behebungen und Wiederholungstests vor einer wichtigen Veröffentlichung möglich sind. Neue Authentifizierungs-, Wiederherstellungs-, Zahlungs- oder API-Funktionen können den erforderlichen Umfang erheblich verändern. Vereinbaren Sie wiederkehrende Prüfungen passend zu Ihrem Veröffentlichungszyklus und Risikoprogramm, statt davon auszugehen, dass eine Bewertung alle späteren Versionen abdeckt.

Testreferenzen und Abdeckung

Wir verwenden relevante OWASP-MASVS-Kontrollbereiche und MASTG-Testleitlinien, um den Umfang der mobilen Prüfung zu strukturieren. Die Leistungsbeschreibung benennt die anwendbaren Kontrollen und Testfälle; der Verweis auf diese Quellen ist keine Behauptung einer OWASP-Zertifizierung oder einer vollständigen Abdeckung aller Kontrollen.

Die Auswahl von API-Szenarien umfasst Autorisierung auf Objektebene und sensible Geschäftsabläufe aus den OWASP API Security Top 10. Diese Referenzen helfen bei der Strukturierung der Prüfung; die eigenen Konto-, Rollen- und Zahlungsregeln der Bank bestimmen, welche Entscheidungen erwartet werden.

Wenn der Auftrag ein regulatorisches Ziel verfolgt, benennen Sie es während der Abgrenzung und lesen Sie gemeinsam mit dem zuständigen Programmverantwortlichen unsere Leitlinien zu Banktests und regulatorischen Anforderungen.