Mobile-App-Pentest bezahlen — gibt es eine Sicherheits-Checkliste, die wir selbst durchgehen können?

Lasst euer Team gleich morgen diese drei Checks machen: 1) App-Logs abschalten, in Console-Ausgaben dürfen niemals Kunden- oder Token-Daten auftauchen. 2) Dafür sorgen, dass sensible Daten, die in die Zwischenablage des Geräts kopiert werden, automatisch gelöscht werden. 3) Testen, wie sich die App auf Geräten mit Root-Zugriff verhält.

Ihr könnt Open-Source-Tools zur statischen Analyse in euren Build-Prozess einbinden. Es gibt kostenlose Tools, die euren Code automatisch scannen und versteckte Keys sowie unsichere Speicherfunktionen in wenigen Minuten auflisten. Ich würde sagen, gebt kein Geld für externe Tests aus, ohne die vorher laufen zu lassen.

Wir haben letztes Jahr denselben Fehler gemacht. 4.200 Pfund bezahlt und den Test gemacht, 9 von 12 Findings im Bericht waren Test-Keys, die im Code vergessen wurden, und unverschlüsselte lokale Cache-Dateien. Hätten wir vorher reingeschaut, hätten sich die Prüfer auf den Payment-Flow konzentrieren können, an dem sie wirklich hätten herumbohren müssen.

Eure eigene Checkliste ist eine super Idee, aber seht sie niemals als Ersatz für den offiziellen Pentest. Wenn man im selbst geschriebenen Code nach Lücken sucht, ist Betriebsblindheit unvermeidlich. Diese Checks sollten nicht gemacht werden, um den Test abzusagen sondern um das ausgegebene Geld wirklich zu nutzen.

wir nutzen eine hybride Infrastruktur die App läuft also eigentilch in einer Web-Ansicht und gelten die genannten Checks zum lokalen Speicher und zu Zertifikaten bei hybriden Apps genauso?

passt extrem auf die sache mit den vergessenen secret api keys im code-repo auf. unser team hatte den temporären key den es für die testumgebung geschrieben hatte, in die produktion geschickt, wir haben es in letzter sekunde gemerkt. die dinger findet man sogar mit einer einfachen suche im repo.

Vor zwei Jahren hat es in der ersten Version unserer Liefer-App ein Kunde geschafft, sich mit einem einfachen Proxy-Tool dazwischenzuschalten und seinen eigenen Bestellbetrag auf 0 Pfund zu setzen. Weil wir die Preisberechnung in der Mobile-App gemacht und so an den Server geschickt haben. Seit dem Tag gehen wir mit null Vertrauen an den Mobile-Client ran.

Ihr seid auf einem sehr guten Weg. Sicherheitsfirmen liefern für jedes Test-Finding Standard-Lösungsvorschläge, aber euren Code reparieren müsst trotzdem ihr. Wenn ihr eure eigene Liste abarbeitet und mit einer sauberen Struktur zur Firma geht, läuft die Testzeit viel effizienter und der Bericht wird bei Firmenverkäufen zum Prestige-Dokument.

das wusste ich nicht.

Bei uns war es so. Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

Bei mobile app sicherheits checkliste ist es meiner Meinung nach schwierig, so eindeutig zu sprechen. also die Zeit, die ihr braucht um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

Wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Hier lauert eine Falle, die ich nicht unerwähnt lassen möchte. Überstürzte Entscheidungen sind oft solche die man sechs Monate später korrigieren muss.

Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig.

Ich würde mich freuen, wenn du das Ergebnis postest.

Danke fürs Schreiben.

Der am häufigsten übersehene Punkt bei mobile app sicherheits checkliste ist dieser: Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Wenn es jemand anders macht, würde mich das auch interessieren.

Lasst uns die Begriffe trennen, sie werden oft verwechselt. Die meisten Vorfälle beginnen nicht mit einer Schwachstelle, sondern mit einem geleakten Passwort.

Wenn es jemand anders macht, würde mich das auch interessieren.

Ein Thema, das gerade aktuell ist. Verlasst euch nicht auf eine einzige Maßnahme; geht schichtweise vor.

Du hast recht.