1. Eine Herausforderung

Ausgangslage: Man hat eine tolle Idee und steht als Anbieter/Betreiber nun vor der Herausforderung, eine App zu entwickeln, die personenbezogene Daten verarbeitet. Um die Daten der Nutzer/Kunden bestmöglich zu schützen, sollte man sich als Verantwortlicher bereits vor der Entwicklung einer App mit wichtigen Sicherheitsfragen auseinandersetzen. Ein »einfach mal drauf los« rächt sich meistens zu einem späteren Zeitpunkt in der Entwicklungsphase, da die Nachrüstung von Sicherheitsmaßnahmen meist (viel) höhere Kosten verursacht. Das böse Erwachen ereilt Verantwortliche dann spätestens mit dem ersten Datenleak, bei dem Betroffene über das Ausmaß des Datenabflusses informiert werden müssen. Ein Szenario, das mit allen Mitteln vermieden werden sollte.

Im vorliegenden Beitrag habe ich eine Security-Checkliste zusammengestellt, die die wichtigsten Bereiche einer App berücksichtigt und Verantwortliche bzw. Entwickler bei der Implementierung einer »sicheren« App unterstützen soll. Die Security-Checkliste basiert auf dem OWASP Mobile Security Testing Guide (MSTG), der ein umfassendes Handbuch für Sicherheitstests und Reverse Engineering von mobilen Apps darstellt.

Neben der Checkliste gebe ich ebenfalls einen kurzen Überblick über datenschutzrechtliche Themen, die Anbieter/Betreiber unbedingt im Blick haben sollten. Da die Datenverarbeitung von Apps auch zunehmend in den Fokus der Aufsichtsbehörden gerät, sind Verantwortliche gut beraten, bereits in der Planung (datenschutz-)rechtliche Anforderungen zu berücksichtigen.

2. App-Entwicklung: Checklisten

Im Internet kursieren diverse Quellen bzw. Checklisten, die Entwickler bei der App-Implementierung unterstützen sollen. Hervorzuheben ist eine Liste mit Mindestanforderungen von Google, die eine Android-App in Bezug auf Qualität erfüllen sollte. Die Liste von Google deckt dabei folgende Bereiche ab: Visual Experience, Funktionalität, Performance und Stabilität, Privatsphäre und Sicherheit. Gerade weil die Liste nur an der Oberfläche kratzt, sollte eigentlich jede App diese Mindestanforderungen erfüllen. Im Bereich Sicherheit und Datenschutz besteht allerdings noch viel Luft nach oben. Mit der nachfolgenden Security-Checkliste versuche ich dieses Vakuum zu füllen.

3. Security-Checkliste

Die nachfolgende Security-Checkliste basiert auf dem OWASP Mobile Security Testing Guide (MSTG), der ein umfassendes Handbuch für Sicherheitstests und Reverse Engineering von mobilen Apps darstellt. Das dort beschriebene Vorgehen zur Verifizierung bzw. Durchführung basiert auf dem OWASP Mobile Application Verification Standard (MASVS). Bei der Durchführung von Penetrationstests bzw. Sicherheitsprüfungen von Apps orientiere ich mich selbst am MSTG.

Hinweis

Die Security-Checkliste erhebt keinen Anspruch auf Vollständigkeit. Sie soll lediglich ein Hilfsmittel darstellen, um Sicherheitsmaßnahmen frühzeitig im Entwicklungsprozess einer App zu berücksichtigen und unnötige Fehler zu vermeiden.

Datenhaltung / Data Storage

Es werden keine sensiblen Daten ungeschützt/unverschlüsselt lokal gespeichert – Details (MSTG-STORAGE-1 und MSTG-STORAGE-2)
Es werden keine sensiblen Daten in Anwendungsprotokolle (Application Logs) geschrieben – Details (MSTG-STORAGE-3)
Es werden keine sensiblen Daten an Dritte weitergegeben, es sei denn, dies ist ein notwendiger Bestandteil der Architektur – Details (MSTG-STORAGE-4)
Der Tastatur-Cache ist bei Texteingaben, die sensible Daten verarbeiten, deaktiviert – Details (MSTG-STORAGE-5)
Es werden keine sensiblen Daten über IPC-Mechanismen offengelegt – Details (MSTG-STORAGE-6)
Es werden keine sensiblen Daten, wie bspw. Passwörter oder PINs, über die Benutzeroberfläche offengelegt – Details (MSTG-STORAGE-7)
In vom mobilen Betriebssystem erstellten Backups sind keine sensiblen Daten enthalten – Details (MSTG-STORAGE-8)
Die App entfernt sensible Daten aus Ansichten (Views), wenn sie in den Hintergrund verschoben wird – Details (MSTG-STORAGE-9)
Die App hält sensible Daten nicht länger als nötig im Speicher und der Speicher wird nach der Verwendung explizit/gezielt gelöscht – Details (MSTG-STORAGE-10)
Die App erzwingt eine Mindestrichtlinie für den Gerätezugriff, bspw. die Anforderung an den Benutzer, einen Gerätepasscode festzulegen – Details (MSTG-STORAGE-11)
Die App klärt den Benutzer über die Arten der verarbeiteten personenbezogenen Daten sowie über bewährte Sicherheitsverfahren auf, die der Benutzer bei der Verwendung der App befolgen sollte – Details (MSTG-STORAGE-12)

Netzwerk / Network

Die Daten werden im Netzwerk/Internet mit TLS verschlüsselt. Der sichere Kanal wird durchgängig verwendet – Details (MSTG-NETWORK-1)
Die TLS-Einstellungen entsprechen den aktuellen Best Practices bzw. kommen diesen so nahe wie möglich, wenn das mobile Betriebssystem die empfohlenen Standards nicht unterstützt – Details (MSTG-NETWORK-2)
Die App verifiziert das X.509-Zertifikat des entfernten Endpunkts, wenn der sichere Kanal aufgebaut wird. Es werden nur Zertifikate akzeptiert, die von einer vertrauenswürdigen CA signiert sind – Details (MSTG-NETWORK-3)
Die App verwendet entweder ihren eigenen Zertifikatspeicher oder sie speichert das Zertifikat oder den öffentlichen Schlüssel des Endpunkts und baut anschließend keine Verbindungen mit Endpunkten auf, die ein anderes Zertifikat oder einen anderen Schlüssel anbieten, selbst wenn sie von einer vertrauenswürdigen CA signiert sind – Details (MSTG-NETWORK-4)
Die App verlässt sich nicht auf einen einzigen unsicheren Kommunikationskanal (E-Mail oder SMS) für kritische Vorgänge, wie bspw. Anmeldungen und Kontowiederherstellung – Details (MSTG-NETWORK-5)
Die App integiert ausschließlich aktuelle Konnektivitäts- und Sicherheitsbibliotheken – Details (MSTG-NETWORK-6)

System-Interaktion / Platform Interaction

Die App fordert nur den minimalen Satz an erforderlichen Berechtigungen an – Details (MSTG-PLATFORM-1)
Alle Eingaben von externen Quellen und dem Benutzer werden validiert und ggf. bereinigt. Dazu gehören Daten, die über die Benutzeroberfläche, IPC-Mechanismen wie Intents, benutzerdefinierte URLs und Netzwerkquellen empfangen werden – Details (MSTG-PLATFORM-2)
Die App exportiert ohne entsprechenden Schutz keine sensible Funktionalität über benutzerdefinierte URL-Schemata – Details (MSTG-PLATFORM-3)
Die App exportiert ohne angemessenen Schutz keine sensiblen Funktionen über IPC-Mechanismen – Details (MSTG-PLATFORM-4)
JavaScript ist in WebViews deaktiviert, sofern nicht explizit erforderlich – Details (MSTG-PLATFORM-5)
WebViews sind so konfiguriert, dass sie nur die minimal erforderlichen Protokoll-Handler zulassen (idealerweise wird nur https unterstützt). Potenziell gefährliche Handler, wie file, tel und app-id, sind deaktiviert – Details (MSTG-PLATFORM-6)
Wenn native Methoden der App einer WebView ausgesetzt sind, rendert diese WebView nur das im App-Paket enthaltene JavaScript – Details (MSTG-PLATFORM-7)
Die Objektserialisierung wird (falls vorhanden) mit sicheren Serialisierungs-APIs implementiert – Details (MSTG-PLATFORM-8)

Kryptographie / Cryptography

Die App verlässt sich nicht auf symmetrische Kryptografie mit fest kodierten Schlüsseln als alleinige Methode der Verschlüsselung – Details (MSTG-CRYPTO-1)
Die App verwendet bewährte Implementierungen von kryptografischen Verfahren/Primitiven – Details (MSTG-CRYPTO-2)
Die App verwendet kryptografische Primitive, die für den jeweiligen Anwendungsfall geeignet sind und mit Parametern konfiguriert sind, die den Best Practices entsprechen – Details (MSTG-CRYPTO-3)
Die App verwendet keine kryptografischen Protokolle oder Algorithmen, die weithin als veraltet für Sicherheitszwecke angesehen werden – Details (MSTG-CRYPTO-4)
Die App verwendet denselben kryptografischen Schlüssel nicht für mehrere Zwecke wieder – Details (MSTG-CRYPTO-5)
Alle Zufallswerte werden mit einem ausreichend sicheren Zufallszahlengenerator erzeugt – Details (MSTG-CRYPTO-6)

Authentifizierung / Authentication

Wenn die App Benutzern den Zugriff auf einen Remote-Dienst ermöglicht, wird am Remote-Endpunkt eine akzeptable Form der Authentifizierung wie bspw. Benutzername/Passwort-Authentifizierung durchgeführt – Details (MSTG-AUTH-1)
Wenn Stateful Session Management verwendet wird, verwendet der entfernte Endpunkt zufällig generierte Sitzungskennungen, um Client-Anfragen zu authentifizieren, ohne die Anmeldedaten des Benutzers zu übermitteln – Details (MSTG-AUTH-2)
Wenn zustandslose tokenbasierte Authentifizierung verwendet wird, stellt der Server ein Token bereit, das mit einem sicheren Algorithmus signiert wurde – Details (MSTG-AUTH-3)
Der entfernte Endpunkt beendet die bestehende Sitzung, wenn sich der Benutzer abmeldet – Details (MSTG-AUTH-4)
Eine Kennwortrichtlinie ist vorhanden und wird am entfernten Endpunkt erzwungen – Details (MSTG-AUTH-5)
Der entfernte Endpunkt implementiert einen Mechanismus zum Schutz vor der übermäßigen Übermittlung von Anmeldeinformationen (Brute-Force) – Details (MSTG-AUTH-6)
Sitzungen werden am entfernten Endpunkt nach einer vordefinierten Zeit der Inaktivität ungültig gemacht und Zugriffstokens laufen ab – Details (MSTG-AUTH-7)
Die biometrische Authentifizierung, sofern vorhanden, ist nicht ereignisgebunden (bedeutet: sie verwendet keine API, die einfach „wahr“ oder „falsch“ zurückgibt). Stattdessen basiert sie auf der Entsperrung des Schlüsselbundes/Keystore – Details (MSTG-AUTH-8)
Am entfernten Endpunkt ist ein zweiter Authentifizierungsfaktor vorhanden und die 2FA-Anforderung wird konsequent durchgesetzt – Details (MSTG-AUTH-9)
Sensible Transaktionen erfordern eine Zwei-Faktor-Authentisierung – Details (MSTG-AUTH-10)
Die App informiert den Benutzer über alle sensiblen Aktivitäten mit seinem Konto. Benutzer können eine Liste von Geräten einsehen, Kontextinformationen (IP-Adresse, Standort usw.) anzeigen und bestimmte Geräte sperren – Details (MSTG-AUTH-11)

Code-Qualität / Code Quality

Die App ist mit einem gültigen Zertifikat signiert und provisioniert, dessen privater Schlüssel ordnungsgemäß geschützt ist – Details (MSTG-CODE-1)
Die App wurde im Release-Modus gebaut, mit Einstellungen, die für einen Release-Build geeignet sind (bspw. nicht debuggingfähig) – Details (MSTG-CODE-2)
Debugging-Symbole wurden aus den nativen Binärdateien entfernt – Details (MSTG-CODE-3)
Debugging-Code und Code zur Unterstützung der Entwickler (bspw. Testcode, Hintertüren, versteckte Einstellungen) wurden entfernt. Die App protokolliert keine ausführlichen Fehler oder Debugging-Meldungen – Details (MSTG-CODE-4)
Alle Komponenten von Drittanbietern, die von der mobilen App verwendet werden, wie bspw. Bibliotheken und Frameworks, sind identifiziert und auf bekannte Sicherheitslücken geprüft – Details (MSTG-CODE-5)
Die App fängt mögliche Ausnahmen ab und behandelt sie – Details (MSTG-CODE-6)
Die Fehlerbehandlungslogik in Sicherheitskontrollen verweigert standardmäßig den Zugriff – Details (MSTG-CODE-7)
In nicht verwaltetem Code wird Speicher sicher alloziert, freigegeben und verwendet – Details (MSTG-CODE-8)
Von der Toolchain angebotene freie Sicherheitsfunktionen, wie Byte-Code-Minifizierung, Stack-Schutz, PIE-Unterstützung und automatische Referenzzählung, sind aktiviert – Details (MSTG-CODE-9)

4. Datenschutz(-recht) | DSGVO

Grundsätzlich kann man sagen: Die Datenschutzgrundverordnung (DSGVO) findet fast immer Anwendung – außer eine App verarbeitet nur anonyme Daten, was in den seltensten Fällen vorkommt. Als Anbieter/Betreiber ist man für die Datenverarbeitung verantwortlich und sollte die DSGVO daher von Beginn an berücksichtigen. Nachfolgend möchte ich kurz einen Überblick über datenschutzrechtliche Themen geben, die Anbieter/Betreiber unbedingt im Blick haben sollten:

Datenverarbeitung: Die Verarbeitung personenbezogener Daten ist nur mit einer Rechtsgrundlage zulässig. Diese ist bspw. dann gegeben, wenn die erhobenen Informationen für die Vertragserfüllung (Art. 6 DSGVO Abs. 1 lit. b) erforderlich sind, ein berechtigtes Interesse (und das Interesse der betroffenen Person nicht überwiegt) (Art. 6 DSGVO Abs. 1 lit. f) des Unternehmens vorliegt oder wenn der Betroffene ausdrücklich, informiert und freiwillig in die Datenverarbeitung eingewilligt (Art. 6 DSGVO Abs. 1 lit. a) hat. Grundsätzlich gilt: Es sollten nur jene Daten erhoben und verarbeitet werden, die für die Funktionalität der App tatsächlich benötigt werden.
Analyse und Tracking: Die Zulässigkeit von Analyse- und Trackingdiensten ist höchst umstritten. Nach Ansicht diverser Aufsichtsbehörden ist ein Tracking nur dann zulässig, wenn eine ausdrückliche, informierte, freiwillige, aktive und vorherige Einwilligung des Nutzers vorliegt. Ebenso ist zu bedenken, dass eine mögliche Einwilligung jederzeit widerrufen werden kann, was ebenfalls über die GUI einer App abgebildet werden muss. Persönlich vertrete ich die Meinung, dass Tracking in Apps die Sicherheit und den Datenschutz unnötig gefährdet und Betreiber im Idealfall darauf verzichten.
Weitergabe an Dritte: Niemand muss das Rad ständig neu erfinden, sondern bestehendes Wissen kann einfach genutzt bzw. weitergegeben werden. Dieses Prinzip machen sich Programmierer zunutze, wenn sie Bibliotheken/Software Development Kits (SDK) in ihren Quellcode integrieren. Mit jedem Einbau von Fremdcode bzw. externen Bibliotheken/SDKs steigt allerdings die Komplexität der App. Damit geht nicht nur ein Risiko für die Sicherheit einher, sondern zwangsläufig auch eine nicht zu beherrschende Intransparenz der Datenverarbeitung, was einen Datenabfluss von Nutzerdaten zur Folge haben kann. Bei der Integration von Bibliotheken/SDKs sollten Entwickler/Betreiber prüfen, ob und welche Daten möglicherweise an Drittanbieter abfließen, mit denen kein Vertrag zur Auftragsverarbeitung geschlossen wurde.
Informationspflicht: Nach Art. 13 DSGVO hat der Verantwortliche/Betreiber die Pflicht, den Betroffenen zum Zeitpunkt der Datenerhebung zu informieren. Diese Informationspflicht kann über eine Datenschutzerklärung erfüllt werden, in der der Verantwortliche transparent über die Verarbeitung der personenbezogenen Daten aufklärt. Darin wird bspw. dargelegt, welche personenbezogenen Daten verarbeitet werden, wie lange diese gespeichert werden und auf welcher Rechtsgrundlage dies erfolgt.

Zu diesem Thema gibt es im Rahmen einer App-(Neu-)Entwicklung noch weitere Überlegungen anzustellen. Als Betreiber kann man sich bei Beratungsbedarf an die Aufsichtsbehörde wenden. Zuständig ist das Bundesland, wo der Anbieter/Betreiber der App seinen Sitz hat. Auf der folgenden Liste sind die Landesämter für den nicht-öffentlichen und öffentlichen Bereich einsehbar.

Unterstütze den Blog mit einem Dauerauftrag!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

5. Fazit

Um ein angemessenes Sicherheitsniveau zu erreichen und die datenschutzrechtlichen Vorgaben zu erfüllen, sind eine Vielzahl von Maßnahmen notwendig. Angesichts der damit verbundenen Anstrengungen ist es wenig verwunderlich, wenn diese beiden Bereiche noch ein eher stiefmütterliches Dasein fristen und bei Verantwortlichen als Kostentreiber gesehen werden. Hier muss allerdings ein Umdenken stattfinden bzw., sollte dieses nicht einsetzen, ein stetiger politischer und gesellschaftlicher Druck ausgeübt werden. Gerade in einer datengetriebenen Gesellschaft muss die Umsetzung von Mindestanforderungen an Sicherheits- und Datenschutzmaßnahmen Pflicht sein.

Für einen Verantwortlichen (Anbieter/Betreiber), der sich seiner Rolle bzw. Funktion bewusst geworden ist, kann die vorliegende Security-Checkliste ein wichtiges Hilfsmittel darstellen, um sich bereits vor der Entwicklung einer App mit wichtigen Sicherheitsfragen auseinanderzusetzen. Dazu zählt selbstverständlich auch die Berücksichtigung der DSGVO und den damit einhergehenden rechtlichen Anforderungen.

Bildquellen:

Agile Methodology: Freepik from www.flaticon.com is licensed by CC 3.0 BY

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

Unterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Diskussion

Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.

Artikel (400)

Android: Security-Checkliste für sichere App-Entwicklung