Sie sind auf Seite 1von 54

(German Translation)

Version v1.4.2
OWASP Mobile Application Security Verification Standard

Version v1.4.2 20. Januar 2022


OWASP Mobile Application Security Verification Standard v1.4.2

Inhaltsverzeichnis

Vorwort 5

Über den Standard 8


Copyright and License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Sponsoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Der Mobile Application Security Verification Standard 12


Das Mobile AppSec Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Bewertung und Zertifizierung 17


OWASP’s Standpunkt zu MASVS Zertifizierungen und Gütesiegeln . . . . . . . . 17
Anleitung zur Zertifizierung von mobilen Apps . . . . . . . . . . . . . . . . . . 17
Andere Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

V1: Anforderungen an Architektur, Design und Bedrohungsanalysen 20


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Security Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

V2: Anforderungen an Datenspeicherung und Datenschutz 23


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

V3: Anforderungen an Kryptografie 27


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

V4: Anforderungen an Authentifizierung und Session Management 29


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

V5: Anforderungen an Netzwerkkommunikation 32


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

V6: Anforderungen zur Plattform-Interaktion 35


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3
OWASP Mobile Application Security Verification Standard v1.4.2

Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

V7: Anforderungen zu Code Qualität und Build-Einstellungen 38


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

V8: Anforderungen an Manipulationssicherheit/Resilienz 41


Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Appendix A: Glossar 46

Appendix B: Referenzen 50

Versionshistorie 51
V1.3 - 13 May 2021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
V1.2 - 7 März 2020 - Internationale Veröffentlichung . . . . . . . . . . . . . . . 51
V1.2-RC - 5 Oktober 2019 - Pre-Release . . . . . . . . . . . . . . . . . . . . . 51
V1.1.4 - 4 Juli 2019 - Summit edition . . . . . . . . . . . . . . . . . . . . . . . 52
V1.1.3 - 9 Januar 2019 - Kleine Fehlerbehebungen . . . . . . . . . . . . . . . . 53
V1.1.2 - 3 Januar 2019 - Sponsoren und Internationalisierung . . . . . . . . . . 53
V1.1.0 - 14 Juli 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
V1.0 - 12 Januar 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4
OWASP Mobile Application Security Verification Standard v1.4.2

Vorwort

Technologierevolutionen können sehr schnell gehen. Noch vor 10 Jahren waren Smart-
phones klobige Geräte mit kleinen Tastaturen - teure Spielgeräte für technikverliebte Ge-
schäftsleute. Heute sind Smartphones ein wesentlicher Bestandteil unseres Lebens. Wir
hängen inzwischen von ihnen ab und nutzen sie zur Information, Navigation und Kommu-
nikation. Sie sind allgegenwärtig - in der Geschäftswelt und im privaten Umfeld.
Jede neue Technologie bringt neue Sicherheitsrisiken mit sich. Eine der größten Heraus-
forderungen für alle, die im Sicherheitsumfeld arbeiten, ist Schritt zu halten mit der fort-
laufenden Weiterentwicklung. Das blaue Team (Verteidigerseite) liegt dabei immer eini-
ge Schritte hinter dem roten Team (Angreiferseite) zurück. Viele unterlagen deshalb zu
Beginn dem Trugschluss, altbekannte Vorgehensweisen direkt auf das mobile Umfeld an-
zuwenden im Sinne von: “Smartphones sind im Prinzip nur kleine PCs und mobile Apps
sind wie klassische Software - folglich gelten die gleichen Sicherheitsanforderungen”. Je-
doch funktioniert das so nicht. Mobile Betriebssysteme unterscheiden sich von Desktop-
Betriebssystemen und mobile Apps sich von Webanwendungen. Zum Beispiel macht die
klassische Methode Virenprüfungen auf Basis von Signaturen durchzuführen in moder-
nen mobilen Betriebssystemumgebungen keinen Sinn. Es ist nicht nur inkompatibel zur
Art und Weise, wie mobile Apps verteilt werden, sondern darüber hinaus aufgrund des
Betriebssystemdesigns (Sandbox-Isolation) von Apps technisch überhaupt nicht umsetz-
bar. Bei gewöhnlichen 08/15-Apps sind zudem eine Reihe von Schwachstellen wie Buffer
overflows und XSS weniger relevant als in Webanwendungen und Desktopanwendungen
(Ausnahmen möglich). Über die Zeit hat sich das gewandelt und die Securitybranche hat
nun eine bessere Vorstellung für die mobile Bedrohungslage entwickelt.
Der Datenschutz steht im Mittelpunkt mobiler Sicherheit. Apps speichern persönliche
Informationen, Fotos, Aufnahmen, Notizen, Kontodaten, Geschäftsdaten, Standortdaten
und viele mehr. Sie dienen uns als tägliche Helfer um uns mit Daten- und Kommunika-
tionsdiensten zu verbinden, die jede einzelne der Nachrichten, die wir mit anderen aus-
tauschen, verarbeiten. Übernimm die Kontrolle über ein Smartphone und Du erhältst un-
gefilterten Zugriff auf das Leben der betreffenden Person. Wenn man sich vorstellt, dass
Mobilgeräte durchaus verloren gehen oder gestohlen werden können und sich mobile
Schadsoftware im Aufwärtstrend befindet, wird der hohe Bedarf an Datenschutz noch-
mals mehr deutlich. Ein Sicherheitsstandard für mobile Apps muss deshalb klar im Fokus
haben, wie mobile Apps mit sensiblen Daten umgehen, sie verarbeiten und speichern.
Moderne mobile Betriebssysteme wie iOS und Android bieten gute APIs für sichere Da-
tenspeicherung und Kommunikation - Diese müssen allerdings auch implementiert und
dabei korrekt genutzt werden, um effektiv zu sein. Datenspeicherung, Interprozesskom-
munikation, korrekte Nutzung kryptografischer APIs und sichere Netzwerkkommunikation
sind nur ein paar der Aspekte die eine sorgfältige Betrachtung erfordern.
Eine wichtige Frage, die man sich stellen muss, ist, wie weit und wie umfangreich Schutz-

5
OWASP Mobile Application Security Verification Standard v1.4.2

maßnahmen umzusetzen sind und wo die Grenze liegt. Zum Beispiel würden die meisten
zustimmen, dass eine mobile App das Serverzertifikat bei einem TLS-Handshake prüfen
muss. Was ist jedoch mit SSL-Zertifikat-Pinning? Führt es direkt zu einer Schwachstelle, es
nicht umzusetzen? Sollte dies eine Anforderung sein, wenn eine App sensible Daten ver-
arbeitet oder ist es eventuell sogar contra-produktiv? Müssen wir Daten in einer SQLite-
Datenbank verschlüsseln, wenn doch das Betriebssystem bereits ein Sandbox-Konzept
mitbringt? Was für die eine App angemessen ist, kann für eine andere App unrealistisch
sein. Der MASVS ist ein Versuch, diese Anforderungen zu standardisieren und Prüf-Level
einzuführen die zu unterschiedlichen Bedrohungsszenarien passen.

Darüber hinaus hat das Erscheinen von Root-Malware und Remote-Administrations-Tools


gezeigt, dass mobile Betriebssysteme selbst ausnutzbare Schwachstellen haben. Um
Client-seitige Manipulation zu verhindern und den Schutz sensibler Daten zu erhöhen,
kommen vermehrt zusätzliche Container-basierte Isolations-Technologien zum Einsatz.
An dieser Stelle wird es kompliziert. Es gibt Hardware-basierte Sicherheitsmechanismen
und Betriebssystemseitige Container-Lösungen wie Android for Work und Samsung Knox
aber nicht durchgängig für alle Geräte. Als Notlösung sind Software-basierte Schutzme-
chanismen möglich jedoch existieren leider keine Standards sowie Testprozesse zu deren
Prüfung.

Als Folge davon existieren zahlreiche mobile Sicherheitstestberichte bei denen die Tester
fehlende Obfuskierung oder fehlende Root-Erkennung in einer Android-App als “Sicher-
heitslücke” werten. Auf der anderen Seite werden Maßnahmen wie Verschlüsselung von
Zeichenketten, Erkennung von Debuggern oder Kontrollfluss-Obfuskierung nicht als ver-
pflichtend erachtet. Letztlich ergibt dieses “schwarz-weiss Denken” keinen Sinn, denn
Resilienz ist keine binäre Eigenschaft, sondern hängt davon ab gegen welche konkreten
Client-seitigen Bedrohungen man sich schützen möchte. Software-Schutzmaßnahmen
zur Erhöhung der Resilienz bringen gewissen Nutzen jedoch können sie definitiv umgan-
gen werden und dürfen deshalb niemals als Ersatz für Sicherheitsmaßnahmen dienen.

Das übergeordnete Ziel des MASVS ist es mit dem MASVS-L1 ein solides Basis-
Sicherheitsniveau, mit dem MASVS-L2 ein erhöhtes Sicherheitsniveau sowie kontext-
bezogen weitere Defense-in-Depth-Maßnahmen gegen Client-seitige Bedrohungen
(MASVS-R) für mobile App-Sicherheit anzubieten.

Folgendes soll mit dem MASVS erreicht werden:

• Bereitstellen von Sicherheitsanforderungen für Softwarearchitekten und Entwickler


um sichere mobile Applikationen zu entwickeln;
• Definition eines Branchenstandards, gegen den mobile Apps in Sicherheits-Reviews
getestet werden können;
• Schärfung und Klarstellung der Rolle von Schutzmechanismen in der mobilen Sicher-
heit und Definition von Anforderungen um deren Effektivität zu prüfen;
• Aussprechen von individuellen Empfehlungen zur Anwendung von mobilen Sicher-

6
OWASP Mobile Application Security Verification Standard v1.4.2

heitsmechanismen für verschiedene Anwendungsfälle.

Wir sind uns bewusst, dass ein 100%-iger Konsens innerhalb der Sicherheitsbranche un-
möglich zu erreichen ist. Nichtsdestotrotz hoffen wir, dass der MASVS eine nützliche Hil-
festellung für alle Phasen mobiler Softwareentwicklung und Tests darstellt. Als offener
Standard soll der MASVS sich über die Zeit weiterentwickeln und wir begrüßen jede Un-
terstützung und Vorschläge.

Von Bernhard Mueller

7
OWASP Mobile Application Security Verification Standard v1.4.2

Über den Standard

Willkommen beim Mobile Application Security Verification Standard (MASVS). Der MASVS
ist eine Community-Initiative mit dem Ziel ein Rahmenwerk von Security-Anforderungen
für Design, Entwicklung und Test von mobilen Apps unter iOS und Android zu etablieren.

Der MASVS vereint Community Engagement und Feedback aus der Praxis. Wir gehen
davon aus, dass der Standard sich über die Zeit weiter entwickelt und begrüßen jedes
Feedback aus der Community. Der beste Weg mit uns in Kontakt zu treten ist der OWASP
Mobile Project Slack Channel: https://owasp.slack.com/messages/.

Nutzerkonten können unter folgender URL angelegt werden: https://owasp.slack.com/join.

Copyright and License

Copyright © 2021 The OWASP Foundation. Dieses Dokument ist veröffentlicht unter der
Creative Commons Attribution ShareAlike 3.0 Lizenz. Für jedwede Wiederverwendung
oder Vertrieb müssen diese Lizenzbestimmungen klar kommuniziert werden.

Danksagungen

8
OWASP Mobile Application Security Verification Standard v1.4.2

Project Lead Lead Mitwirkende and Reviewer


Author

Sven Schleier and Bernhard Alexander Antukh, Mesheryakov Aleksey, Elderov Ali,
Carlos Holguera Mueller, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de
Sven Boer, Damien Clochard, Ben Cheney, Will Chilcutt,
Schleier, Stephen Corbiaux, Manuel Delgado, Ratchenko
Jeroen Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner,
Willem- Anton Glezman, Josh Grossman, Sjoerd Langkemper,
sen and Vinícius Henrique Marangoni, Martin Marsicano,
Carlos Roberto Martelloni, @PierrickV, Julia Potapenko,
Holguera Andrew Orobator, Mehrad Rafii, Javier Ruiz, Abhinav
Sejpal, Stefaan Seys, Yogesh Sharma, Prabhant
Singh, Nikhil Soni, Anant Shrivastava, Francesco
Stillavato, Abdessamad Temmar, Pauchard Thomas,
Lukasz Wierzbicki

Sprache Übersetzer und Gutachter

Chinesisch Peter Chi, and Lex Chien, Henry Hu, Leo Wang
(Traditionell)

Chinesisch Bob Peng, Harold Zang, Jack S


(Vereinfacht)

Deutsch Rocco Gränitz, Sven Schleier (Review)

Französisch Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review)

Hindi Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra
Kumar Sinha, Vikrant Shah

Japanisch Koki Takeyama, Riotaro Okada (Review)

Koreanisch Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung

Persisch (Farsi) Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari,
Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel

Portugiesisch Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza,


(Brasilien) Fernando Galves

9
OWASP Mobile Application Security Verification Standard v1.4.2

Sprache Übersetzer und Gutachter

Portugiesisch Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia
Dias

Russisch Gall Maxim, Eugen Martynov, Chelnokov Vladislav (Review), Oprya


Egor (Review), Tereshin Dmitry (Review)

Spanisch Martin Marsicano, Carlos Holguera

Dieses Dokument basiert auf einem Fork des OWASP Application Security Verification
Standard verfasst von Jim Manico.

Sponsoren

Obwohl beide Projekte, der MASVS und der MSTG, auf freiwilliger Basis im Rahmen der
Community erarbeitet wurden und weiter gepflegt werden, ist manchmal ein wenig Hilfe
von außen nötig. Wir danken deshalb den Sponsoren, mit deren Hilfe wir technische Edi-
toren akquirieren können. Der Inhalt des MASVS oder MSTG ist in keinster Weise durch
etwaige Sponsoren beeinflusst. Eine nähere Beschreibung der Sponsoren-Pakete befindet
sich im OWASP Projekt Wiki.

God Mode

OWASP MSTG

OWASP Bay Area Chapter

Honorable Benefactor

OWASP MSTG

OWASP MSTG

Good Samaritan

OWASP MSTG

10
OWASP Mobile Application Security Verification Standard v1.4.2

Als Nächstes möchten wir uns beim OWASP Bay Area Chapter für das Sponsoring bedan-
ken. Zum Schluss möchten wir uns bei allen bedanken, die das Buch von Leanpub gekauft
und uns auf diese Weise gesponsert haben.

11
OWASP Mobile Application Security Verification Standard v1.4.2

Der Mobile Application Security Verification


Standard

Der MASVS kann genutzt werden um das Sicherheitsniveau von mobilen Apps nachweisen
zu können. Die Anforderungen wurden auf Basis folgender Ziele entwickelt:

• Nutzung als Metrik - Um Entwicklern und Applikations-Verantwortlichen einen Secu-


rity Standard anzubieten gegen den existierende mobile Apps verglichen werden
können;
• Nutzung als Hilfestellung - Um Hilfe zu bieten in allen Phasen mobiler App-
Entwicklung und Tests.
• Nutzung bei Beschaffung/Kauf von mobilen Apps - Um als Baseline zur Prüfung der
Security von mobilen Apps zu dienen.

Das Mobile AppSec Model

Der MASVS definiert zwei Prüf-Level (L1 und L2), sowie eine Reihe von Sicherheitsmaß-
nahmen zur Robustheit gegen Reverse Engineering (MASVS-R). Diese sind flexibel, d.h.
adaptierbar an ein App-spezifisches Threat Model. MASVS-L1 enthält generische Sicher-
heitsanforderungen und wird für alle mobilen Apps empfohlen, während MASVS-L2 für
Apps verwendet werden sollte die hochsensible Daten verarbeiten. MASVS-R deckt zu-
sätzliche Schutzmaßnahmen ab, die anzuwenden sind, um Client-seitigen Threats vorzu-
beugen.

Eine App die alle Anforderungen aus MASVS-L1 erfüllt, folgt Security Best Practices und
vermeidet damit typische Schwachstellen. MASVS-L2 fügt weitere Defense-In-Depth Maß-
nahmen wie SSL-Pinning hinzu, um ein erhöhtes Schutzniveau gegen komplexere Angriffe
zu bieten. Dabei gilt die Annahme, dass das mobile Betriebssystem intakt und der Endnut-
zer nicht als potenzieller Angreifer betrachtet wird. Die Anforderungen aus dem MASVS-R
ganz oder teilweise zu erfüllen, hilft dabei spezifische client-seitige Threats (böswilliger
Nutzer o. kompromittiertes Betriebssystem) zu verhindern bzw. zu erschweren.

I: Die Schutzmaßnahmen enthalten in MASVS-R und beschrieben im OWASP Mo-


bile Testing Guide können letztlich alle umgangen werden und dürfen nicht als
Ersatz für Sicherheitsmaßnahmen (L1/L2) genutzt werden. Stattdessen sind sie
dazu gedacht, um zusätzliche Threat-spezifische Schutzmaßnahmen zu Apps
hinzuzufügen, die bereits die MASVS Anforderungen L1 oder L2 erfüllen.

II: Bitte beachte das alle Anforderungen, die in MASVS-R aufgelistet und im
OWASP Mobile Security Testing Guide beschrieben sind, immer umgangen wer-
den können. Daher sollten diese auch nie als Ersatz für Sicherheitsmaßnahmen
verwendet werden. Stattdessen ist die Intention von MASVS-R zusätzliche be-

12
OWASP Mobile Application Security Verification Standard v1.4.2

drohungsspezifische Gegenmaßnahmen für Apps zu definieren, die bereits die


Anforderungen in MASVS-L1 oder MASVS-L2 erfüllen.

Dokumentstruktur

Der erste Teil des MASVS enthält eine Beschreibung des Security Modells und der Prüf-
Level, gefolgt von Empfehlungen zur Nutzung des Standards in der Praxis. Die detail-
lierten Sicherheitsanforderungen und ihre Einordnung in die Prüf-Level befinden sich im
zweiten Teil. Die Anforderungen wurden in acht Kategorien (V1 bis V8), basierend auf
technischen Zielen/Scopes, eingeteilt. Die folgende Nomenklatur wird durchgehend im
MASVS und MSTG genutzt:

• Anforderungs Kategorie: MASVS-Vx, z.B. MASVS-V2: Datenspeicherung und Daten-


schutz
• Anforderung: MASVS-Vx.y, z.B. MASVS-V2.2: “Keine sensiblen Daten werden in Ap-
plikations Logs geschrieben.”

Prüf-Level im Detail

MASVS-L1: Standard Security

Eine mobile App die MASVS-L1 entspricht, erfüllt Mobile Application Best Practices. Sie
erfüllt Basis-Anforderungen in Bezug auf Codequalität, Umgang mit sensiblen Daten und
Interaktion mit dem mobilen Umfeld. Es gibt einen Testprozess, um die Effektivität der
Security Maßnahmen zu prüfen. Dieser Level eignet sich für alle mobilen Applikationen.

13
OWASP Mobile Application Security Verification Standard v1.4.2

MASVS-L2: Defense-in-Depth

MASVS-L2 führt erweiterte Sicherheitsmaßnahmen ein, die über die Standardanforderun-


gen hinausgehen. Um L2 zu erfüllen, muss ein Threat Model existieren und Security muss
ein integraler Teil der App-Architektur sein. Dieser Level ist angedacht für alle Apps, die
sensible Daten verarbeiten wie z.B. Apps für mobiles Bezahlen.

MASVS-R: Resilienz gegen Reverse Engineering and Manipulation

Die App hat state-of-the-art Security und ist resilient (robust) gegen spezifische, klar de-
finierte Client-seitige Angriffe wie Manipulation, Modifizierung oder Reverse Engineering
um sensiblen Quellcode oder Daten zu extrahieren. Solch eine App nutzt Hardware Secu-
rity Funktionen oder ausreichend starke und überprüfbare Software-Schutzmaßnahmen.
MASVS-R ist geeignet für Apps, die hochsensible Daten verarbeiten, um geistiges Eigen-
tum zu schützen oder um eine App manipulationssicher zu machen.

Empfohlene Nutzung

Nach vorheriger Bewertung des Risikos und des erforderlichen Sicherheitsniveaus kön-
nen Apps gegen MASVS L1 oder L2 geprüft werden. L1 ist geeignet für alle mobilen Apps,
während L2 für Apps mit mehr sensiblen Daten oder sensibler Funktionalität empfohlen
wird. MASVS-R (oder Teile davon) können genutzt werden um zusätzlich zu bereits im-
plementierten Sicherheitsfunktionen die Resilienz der App gegen spezifische Threats wie
Repackaging oder Extraktion von sensiblen Daten zu prüfen.

Insgesamt gibt es folgende Prüfkombinationen:

• MASVS-L1
• MASVS-L1+R
• MASVS-L2
• MASVS-L2+R

Die Kombinationen stellen verschiedene Graduierungen der Security und Resilienz dar.
Das Ziel ist Flexibilität: Eine Gaming-App z.B. wird aus Usability-Gesichtspunkten darauf
verzichten, MASVS-L2 Maßnahmen wie 2-Faktor Authentifizierung zu nutzen hat jedoch
aus Business-Sicht hohen Schutzbedarf gegen Code-Manipulation (Tampering).

Prüfvariante wählen

Die Anforderungen aus MASVS L2 zu implementieren erhöht die Sicherheit - dies kann sich
jedoch negativ auf die Endnutzerakzeptanz auswirken (klassischer Kompromiss). Zeit-
gleich steigen die Entwicklungskosten.

14
OWASP Mobile Application Security Verification Standard v1.4.2

Beispiele

MASVS-L1

• Geeignet für alle mobilen Apps. MASVS-L1 benennt Security Best Practices mit ak-
zeptablen Auswirkungen auf Entwicklungskosten und Nutzererlebnis. Sollte für jede
App genutzt werden die keinen höheren Level erfordert.

MASVS-L2

• Gesundheitswesen: Mobile Apps, die personenbezogene Daten speichern, die für


Identitätsdiebstahl, Zahlungsbetrug und eine Reihe anderer Betrugsvorhaben ge-
nutzt werden können. Zu den für den US-Gesundheitsbereich geltenden Compliance-
Regeln gehören der Health Insurance Portability and Accountability Act (HIPAA), Da-
tenschutz, Security und Vorgaben/Regeln zur Benachrichtigung bei Datenpannen
sowie Patientensicherheit.
• Banken/Finanzwesen: Apps mit Zugriff auf hochsensible Daten wie Kreditkarten,
personenbezogene Daten oder die Zahlungsflüsse erlauben. Diese Apps erfordern
erweiterte Security Maßnahmen, um Betrug zu vermeiden. Finanz-Apps müssen
Compliance-Anforderungen aus dem Payment Card Industry Data Security Standard
(PCI DSS), Gramm Leech Bliley Act und Sarbanes-Oxley Act (SOX) erfüllen.

MASVS L1+R

• Mobile Apps für die der Schutz des geistigen Eigentums geschäftskritisch ist. Die
Resilienz-Maßnahmen aus MASVS-R dienen dazu, für Angreifer den Aufwand zu er-
höhen um an den Original-Quellcode zu gelangen und Manipulation der Apps (Tam-
pering/Cracking) zu erschweren.
• Gaming Industrie: Spiele mit hohem Bedarf Modding und Cheating zu verhindern,
wie Online-Games. Cheating ist ein großes Problem in Online-Spielen, da eine hohe
Anzahl von Cheatern die regulären Nutzer verärgern und ein erfolgreiches Game
letztlich zum Scheitern bringen kann. MASVS-R bietet Basis-Maßnahmen, um den
Aufwand für Cheater zu erhöhen.

MASVS L2+R

• Finanzwesen: Online Banking Apps, die Nutzern Geldtransfers erlauben und bei de-
nen Techniken wie Code-Injektion oder Instrumentierung auf kompromittierten Gerä-
ten Risiken darstellen. In diesem Fall können Maßnahmen aus dem MASVS-R genutzt
werden, um Manipulationen zu erschweren und den Aufwand für Malware Autoren
zu erhöhen.

• Alle mobilen Apps, die sensible Daten auf dem mobilen Gerät speichern und gleich-
zeitig eine hohe Kompatibilität zu diversen Geräten und Betriebssystemversionen
bieten müssen. In diesem Fall können Resilienz-Maßnahmen als defense-in-depth

15
OWASP Mobile Application Security Verification Standard v1.4.2

genutzt werden um den Aufwand für Angreifer, die sensible Daten extrahieren wol-
len, zu erhöhen.

• Apps die In-App Bezahlung anbieten, sollten die Anforderungen in MASVS-L2 und
server-seitige Schutzmaßnahmen benutzen, um bezahlte Inhalte zu beschützen. In
Fällen in denen server-seite Schutzmaßnahmen nicht verwendet werden können,
sollten die Anforderungen von MASVS-R berücksichtigt werden, um Reverse Engi-
neering zu erschweren.

16
OWASP Mobile Application Security Verification Standard v1.4.2

Bewertung und Zertifizierung

OWASP’s Standpunkt zu MASVS Zertifizierungen und Gütesiegeln

OWASP ist eine herstellerunabhängige Non-Profit-Organisation und führt keine Zertifizie-


rungen von Herstellern, Prüfern oder Software durch.

OWASP distanziert sich von derartigen Bescheinigungen, Qualitätssiegeln oder Zertifika-


ten. Diese sind in keinem Fall durch OWASP freigegeben, registriert oder zertifiziert. Eine
Organisation/Unternehmen sollte vorsichtig und misstrauisch gegenüber derartigen Gü-
tesiegeln sein.

Dies sollte Organisationen nicht davon abhalten Dienstleistungen auf Basis des (M)ASVS
Standard anzubieten, solange keine offiziellen OWASP Zertifikate ausgestellt werden.

Anleitung zur Zertifizierung von mobilen Apps

Der empfohlene Weg um eine mobile App gegen den MASVS zu prüfen ist das offene
Review-Format. Dabei erhalten Tester Zugriff auf Schlüsselressourcen wie Architekten
und App-Entwickler, Projekt-Dokumentation, Quellcode und authentifizierten Zugriff auf
API-Endpunkte (mindestens ein Nutzeraccount für jede Rolle)

Es ist wichtig zu erwähnen, dass der MASVS nur die Security auf der client-seitigen mo-
bilen App und der Netzwerkkommunikation zwischen App und API-Endpunkt(en) sowie
einige Basisanforderungen in Bezug auf Nutzerauthentifizierung und Session Manage-
ment abdeckt. Er enthält darüber hinaus keine spezifischen Security-Anforderungen für
remote Services z.B. Webservices die von der App genutzt werden. Jedoch schreibt MAS-
VS V1 vor, dass API-Endpunkte von einem übergreifenden Threat Model berücksichtigt
und gegen entsprechende Standards wie ASVS geprüft werden müssen.

Eine Zertifizierungsstelle muss in jedem Report den Scope der Überprüfung (insbe-
sondere wenn eine Schlüsselkomponente out of scope ist), eine Zusammenfassung
der Prüfungs-Findings, inklusive einer Auflistung aller erfolgreich durchgeführten sowie
gescheiterten Tests sowie klare Lösungshinweise zu allen gescheiterten Tests aufführen.
Eine Sammlung detaillierter Arbeitspapiere, Screenshots oder Demo-Videos, Skripte
um eine gefundene Schwachstelle zuverlässig und wiederholt zu exploiten aber auch
elektronische Aufzeichnungen/Logs wie Traffic-Mitschnitte durch einen Proxy und zuge-
hörige Notizen wie z.B. eine ToDo-Liste oder Cleanup-Liste aufzubewahren gilt als “Best
Practice”. Es ist unzureichend einfach nur ein Tool zu starten und die Findings zu berich-
ten. Stattdessen ist es wichtig Beweise zu liefern, dass alle geforderten Themenpunkte
gründlich getestet wurden. Für den Fall von Streitigkeiten sollten ausreichend Nachweise
vorliegen um darlegen zu können, dass jede zu prüfende Anforderung tatsächlich
getestet wurde.

17
OWASP Mobile Application Security Verification Standard v1.4.2

Nutzung des OWASP Mobile Security Testing Guide (MSTG)

Der OWASP MSTG ist eine Anleitung zum Testen der Sicherheit von mobilen Apps. Der
Guide beschreibt den technischen Prozess zur Überprüfung der Anforderungen aus dem
MASVS. Der MSTG enthält eine Liste von Testfällen. Jeder Testfall referenziert eine einzel-
ne Anforderung im MASVS. Während der MASVS eher grobe und generische Anforderun-
gen enthält, bietet der MSTG detaillierte Empfehlungen und Testprozeduren je mobilem
Betriebssystem.

Die Rolle von Werkzeugen für automatisierte Security Tests

Die Nutzung von Quellcode-Scannern und Black-Box-Test-Werkzeugen erhöht die Effizi-


enz und wird klar empfohlen. Allerdings ist eine vollständige MASVS Überprüfung allein
mit automatisierten Werkzeugen unmöglich. Jede mobile App ist unterschiedlich und ein
Verständnis der Gesamtarchitektur, der Geschäftslogik und technischer Fallstricke ge-
nutzter Technologien und Frameworks ist eine zwingende Voraussetzung um die Sicher-
heit einer App zu prüfen.

Andere Anwendungsfälle

Als detaillierter Security-Architektur-Guide

Der MASVS ist eine wertvolle Ressource für Security Architekten. Den 2 wichtigsten
Security-Architektur-Frameworks SABSA und TOGAF fehlen wesentliche Teile um Security-
Architektur-Reviews für mobile Apps durchführen zu können. Der MASVS kann genutzt
werden, um diese Lücken zu schließen und ist eine wertvolle Hilfe bei der Auswahl
geeigneter Security Maßnahmen im Bereich mobiler Apps.

Als Ersatz für pauschale Secure Coding Checklisten

Viele Organisationen können davon profitieren, den MASVS zu adaptieren, indem Sie ei-
nen geeigneten Level wählen oder den MASVS als Ausgangsbasis nutzen (Forking) und
die Inhalte entsprechend zum Risikoprofil und Domänen-Kontext der jeweiligen App an-
passen. Dieser Weg des Forkens wird empfohlen wobei darauf zu achten ist, die Nach-
verfolgbarkeit der einzelnen Themenpunkte zu gewährleisten. So sollte z.B. Anforderung
4.1 auch nach zukünftigen Änderungen die gleiche semantische Bedeutung behalten.

18
OWASP Mobile Application Security Verification Standard v1.4.2

Als Basis für Security Tests

Eine gute Testmethodik für Security Tests mobiler Apps sollte alle Anforderungen aus
dem MASVS abdecken. Der OWASP MSTG beschreibt Black-box und White-box Testfälle
für jede Anforderungen aus dem MASVS.

Als Vorgabe für automatisierte Unit- und Integrationstests

Um die Anzahl von Findings in der Vorproduktions-Phase zu reduzieren, sollten bereits


während der Entwicklung automatische Unit-, Integrations- und Akzeptanztests durchge-
führt werden. Um dies zu unterstützen wurde der MASVS mit starkem Fokus auf Testbar-
keit entwickelt. Eine Ausnahme bilden die Anforderungen aus dem Bereich Architektur.
Teams, die die Anforderungen aus dem ASVS (über automatisierte Tests) umsetzen erhö-
hen dadurch nicht nur die Qualität der entwickelten Apps, sondern verbessern auch die
Security Awareness der Entwickler.

Zum Training für sichere Software-Entwicklung

Der MASVS kann darüber hinaus genutzt werden, um die Merkmale zu beschreiben, die
eine sichere mobile App haben sollte. Viele Kurse für “sichere Softwareentwicklung” sind
simple Kurse über Hacking-Techniken und bieten kaum wertvolle Tipps für Entwickler.
Kurse die auf Basis des MASVS proaktive Schutz-Maßnahmen in den Vordergrund stellen,
anstatt z.B. die Top 10 Schwachstellen zu behandeln, bieten wesentlichen Mehrwert für
Entwickler.

19
OWASP Mobile Application Security Verification Standard v1.4.2

V1: Anforderungen an Architektur, Design und


Bedrohungsanalysen

Zielsetzung

In einer perfekten Welt würde Security über alle Phasen der Softwareentwicklung berück-
sichtigt werden. In der Realität wird Security jedoch meist erst spät im Entwicklungspro-
zess berücksichtigt. Neben den technischen Maßnahmen fordert der MASVS auch organi-
satorische Maßnahmen die sicherstellen, dass Security in der Planungsphase sowie beim
Design der mobilen App entsprechend Berücksichtigung gefunden hat. Für jede Kompo-
nente der App muss der fachliche Funktionsumfang und Sicherheitsfunktionen klar defi-
niert und bekannt sein. Die meisten Apps kommunizieren mit entfernten Schnittstellen
(API-Endpunkten). Deshalb müssen auch für diese API-Endpunkte angemessene Security
Standards umgesetzt sein. Der isolierte Test einer mobilen App ohne die Endpunkte ist
unzureichend!

Die Kategorie “V1” enthält Sicherheitsanforderungen an die Architektur und das Design
einer App. Aufgrund dessen ist dies die einzige Kategorie die nicht auf technische Testfälle
in den OWASP Mobile Testing Guide referenziert. Um Themen wie Bedrohungsanalyse,
sichere Softwareentwicklungsprozesse und Schlüssel-Management abzudecken, sollten
Anwender des MASVS die jeweiligen OWASP Projekte und/oder Standards wie die unten
verlinkten Dokumente berücksichtigen.

Security Anforderungen

Die Anforderungen für MASVS-L1 und MASVS-L2 sind nachfolgend aufgelistet.

# MSTG-ID Beschreibung L1 L2

1.1 MSTG-ARCH-1 Alle Komponenten der mobilen App sind x x


identifiziert und für den Betrieb der App
erforderlich.

1.2 MSTG-ARCH-2 Sicherheitsfunktionen sind niemals nur auf x x


Client-Seite implementiert, sondern immer auch
im entsprechenden entfernten API-Endpunkt.

1.3 MSTG-ARCH-3 Es existiert eine Architekturübersicht über die x x


mobile App und alle verbundenen
API-Endpunkte und Security wurde in der
Gesamtarchitektur berücksichtigt.

20
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung L1 L2

1.4 MSTG-ARCH-4 Alle sensiblen Daten im Kontext der mobilen x x


App wurden klar identifiziert.

1.5 MSTG-ARCH-5 Für jede Komponente der App ist der x


angebotene fachliche Funktionsumfang
und/oder Sicherheitsfunktionen/-mechanismen
klar definiert.

1.6 MSTG-ARCH-6 Für die mobile App und die genutzten x


API-Endpunkte wurde eine Bedrohungsanalyse
durchgeführt und potenzielle Bedrohungen und
Gegenmaßnahmen identifiziert.

1.7 MSTG-ARCH-7 Alle Sicherheitsfunktionen wurden in Form von x


zentralen Komponenten implementiert.

1.8 MSTG-ARCH-8 Eine dedizierte Richtlinie zum Management von x


kryptografischen Schlüsseln (falls in der App
genutzt) beschreibt den sicheren Umgang mit
Schlüsseln über den gesamten Lebenszyklus,
idealerweise basierend auf Standards wie NIST
SP 800-57.

1.9 MSTG-ARCH-9 Es gibt einen Mechanismus in der mobilen App, x


um App-Aktualisierungen zu erzwingen.

1.10 MSTG-ARCH-10 Security wird in allen Teilen des x


Softwareentwicklungszyklus berücksichtigt.

1.11 MSTG-ARCH-11 Eine “Responsible Disclosure Policy” ist x


vorhanden und wird umgesetzt.

1.12 MSTG-ARCH-12 Die App sollte Datenschutzgesetze und x x


Regulierungen befolgen.

Referenzen

Für weitere Informationen:

• OWASP Mobile Top 10: M10 (Extraneous Functionality) - https://owasp.org/www-


project-mobile-top-10/2016-risks/m10-extraneous-functionality

21
OWASP Mobile Application Security Verification Standard v1.4.2

• OWASP Threat Modeling - https://owasp.org/www-community/Application_Threat_M


odeling
• OWASP Secure SDLC Cheat Sheet - https://github.com/OWASP/CheatSheetSeries/bl
ob/master/cheatsheets_excluded/Secure_SDLC_Cheat_Sheet.md
• Microsoft SDL - https://www.microsoft.com/en-us/sdl/
• NIST SP 800-57 (Recommendation for Key Management) - https://csrc.nist.gov/publ
ications/detail/sp/800-57-part-1/rev-5/final
• security.txt - https://securitytxt.org/

22
OWASP Mobile Application Security Verification Standard v1.4.2

V2: Anforderungen an Datenspeicherung und


Datenschutz

Zielsetzung

Der Schutz sensibler Daten wie Nutzer-Anmeldedaten und privaten Informationen ist
ein Schwerpunkt im Bereich mobiler Sicherheit. Zum Beispiel können sensible Daten
ungewollt anderen Apps auf dem mobilen Gerät zur Verfügung gestellt werden, falls
Betriebssystem-Mechanismen wie Interprozesskommunikation auf unsichere Weise ge-
nutzt werden. Datenlecks können ungewollt im Bereich Cloud-Daten-Speicherung, Back-
ups oder dem Tastatur-Cache auftreten. Darüber hinaus können mobile Geräte leichter
verloren gehen oder gestohlen werden. Die Wahrscheinlichkeit für physische Angriffe ist
höher als bei anderen Geräten. In diesem Fall können zusätzliche Schutzmaßnahmen
implementiert werden, um den Zugriff auf sensible Daten zu erschweren. Im MASVS
steht die App im Mittelpunkt und nicht das mobile Gerät. Security-Lösungen für mobiles
Gerätemanagement (MDM) werden aus OWASP Sicht zwar zur Umsetzung von Security-
Richtlinien im Unternehmens-Umfeld empfohlen, werden im MASVS jedoch nicht berück-
sichtigt.

Definition sensibler Daten

Sensible Daten im Kontext des MASVS sind jegliche Nutzer-Anmeldedaten sowie alle üb-
rigen Daten die entsprechend ihrem Kontext sensibel sind:

• Personenbezogene Daten, die für Identitätsdiebstahl genutzt werden können: Sozi-


alversicherungsnummern, Kreditkarteninformationen, Bankdaten und Gesundheits-
daten;
• Hoch sensible Daten deren Kompromittierung zu hohem Reputationsverlust oder
finanziellen Aufwänden führen würde: Vertragsinformationen, Informationen die
durch Verschwiegenheitserklärungen geschützt sind, Management Informationen;
• Alle Daten die durch gesetzliche Bestimmungen oder aufgrund regulatorischer Vor-
gaben (Compliance) zu schützen sind.

Anforderungen

Ein Großteil von Datenpannen kann bereits durch Einhaltung einfacher Regeln vermieden
werden. Die meisten der Sicherheitsmaßnahmen in dieser Kategorie sind deshalb für alle
Prüf-Levels zwingend erforderlich.

23
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung L1 L2

2.1 MSTG-STORAGE-1 Die App verwendet die vom jeweiligen x x


Betriebssystem angebotenen sicheren
Speichermechanismen, um sensible Daten zu
speichern wie personenbezogene Daten,
Anmeldedaten oder kryptografische Schlüssel.

2.2 MSTG-STORAGE-2 Es werden keine sensiblen Daten außerhalb des x x


App-Containers oder außerhalb des vom
jeweiligen Betriebssystem angebotenen
sicheren Speichermechanismus abgelegt.

2.3 MSTG-STORAGE-3 Es werden keine sensiblen Daten in die Logfiles x x


der App geschrieben.

2.4 MSTG-STORAGE-4 Es werden keine sensiblen Daten mit Dritten x x


geteilt - es sei denn dies wurde in der
App-Architektur definiert und ist zur Erfüllung
des Zwecks der App erforderlich.

2.5 MSTG-STORAGE-5 Der Tastatur-Cache ist für alle sensiblen x x


Texteingaben deaktiviert.

2.6 MSTG-STORAGE-6 Es werden keine sensiblen Daten über x x


Interprozesskommunikation zur Verfügung
gestellt.

2.7 MSTG-STORAGE-7 Es werden keine sensiblen Daten wie Passwörter x x


oder Pins über die Benutzeroberfläche
exponiert.

2.8 MSTG-STORAGE-8 Es ist sichergestellt, dass x


betriebssystemgesteuerte Backups keine
sensiblen App-Daten enthalten.

2.9 MSTG-STORAGE-9 Die App entfernt sensible Daten aus der x


aktuellen Ansicht, wenn der Hintergrundmodus
aktiviert wird.

2.10 MSTG-STORAGE-10 Die App hält sensible Daten nur solange wie x
nötig im Speicher und betroffene
Speicherbereiche werden nach Nutzung explizit
gelöscht.

24
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung L1 L2

2.11 MSTG-STORAGE-11 Die App erzwingt ein Minimum an x


Geräteschutz-Richtlinien wie das Definieren
eines Gerätepassworts.

2.12 MSTG-STORAGE-12 Die App klärt den Nutzer über die Art und Weise x x
der verarbeiteten personenbezogenen Daten
auf und gibt dem Nutzer
Security-Best-Practice-Empfehlungen zum
Umgang mit der App.

2.13 MSTG-STORAGE-13 Sensible Daten sollten nicht lokal auf dem x


mobilen Gerät gespeichert werden. Daten
sollten stattdessen direkt vom API-Endpunkt
abgerufen und nur im Arbeitsspeicher
vorgehalten werden.

2.14 MSTG-STORAGE-14 Falls doch sensible Daten lokal vorgehalten x


werden müssen, sollten diese mit einem
Schlüssel verschlüsselt werden der im vom
jeweiligen Betriebssystem angebotenen
sicheren Speichermechanismus abgelegt ist.
Der Zugriff auf den Schlüssel sollte
Authentifizierung erfordern.

2.15 MSTG-STORAGE-15 Der lokale Speicher von der App sollte gelöscht x
werden, nach Erreichen einer exzessiven Anzahl
von fehlgeschlagenen Login-Versuchen.

Referenzen

Der OWASP Mobile Security Testing Guide bietet detaillierte Anleitungen, um die Anfor-
derungen aus dieser Kategorie zu überprüfen.

• Android: Testing Data Storage - https://github.com/OWASP/owasp-mstg/blob/mast


er/Document/0x05d-Testing-Data-Storage.md
• iOS: Testing Data Storage - https://github.com/OWASP/owasp-mstg/blob/master/D
ocument/0x06d-Testing-Data-Storage.md

Weitere Informationen unter:

25
OWASP Mobile Application Security Verification Standard v1.4.2

• OWASP Mobile Top 10: M1 (Improper Platform Usage) - https://owasp.org/www-


project-mobile-top-10/2016-risks/m1-improper-platform-usage
• OWASP Mobile Top 10: M2 (Insecure Data Storage) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m2-insecure-data-storage
• CWE 117 (Improper Output Neutralization for Logs) - https://cwe.mitre.org/data/def
initions/117.html
• CWE 200 (Information Exposure) - https://cwe.mitre.org/data/definitions/200.html
• CWE 276 (Incorrect Default Permissions) - https://cwe.mitre.org/data/definitions/2
76.html
• CWE 311 (Missing Encryption of Sensitive Data) - https://cwe.mitre.org/data/definit
ions/311.html
• CWE 312 (Cleartext Storage of Sensitive Information) - https://cwe.mitre.org/data/d
efinitions/312.html
• CWE 316 (Cleartext Storage of Sensitive Information in Memory) - https://cwe.mitr
e.org/data/definitions/316.html
• CWE 359 (Exposure of Private Information (‘Privacy Violation’)) - https://cwe.mitre.
org/data/definitions/359.html
• CWE 522 (Insufficiently Protected Credentials) - https://cwe.mitre.org/data/definitio
ns/522.html
• CWE 524 (Information Exposure Through Caching) - https://cwe.mitre.org/data/def
initions/524.html
• CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - https://cwe.
mitre.org/data/definitions/530.html
• CWE 532 (Information Exposure Through Log Files) - https://cwe.mitre.org/data/def
initions/532.html
• CWE 534 (Information Exposure Through Debug Log Files) - https://cwe.mitre.org/
data/definitions/534.html
• CWE 634 (Weaknesses that Affect System Processes) - https://cwe.mitre.org/data/d
efinitions/634.html
• CWE 798 (Use of Hard-coded Credentials) - https://cwe.mitre.org/data/definitions/7
98.html
• CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - https:
//cwe.mitre.org/data/definitions/921.html
• CWE 922 (Insecure Storage of Sensitive Information) - https://cwe.mitre.org/data/d
efinitions/922.html

26
OWASP Mobile Application Security Verification Standard v1.4.2

V3: Anforderungen an Kryptografie

Zielsetzung

Kryptografie ist ein wesentlicher Eckpfeiler zum Schutz von Daten, die auf mobilen Gerä-
ten gespeichert werden. Es ist aber auch eine Kategorie, bei der vieles falsch gemacht
werden kann, besonders wenn man keine Standard-Konventionen einhält. Die Kategorie
soll sicherstellen, dass eine überprüfte App Kryptografie-Best-Practices nach dem Stand
der Technik nutzt:

• Nutzung bewährter Krypto-Bibliotheken,


• Richtige Auswahl und Konfiguration kryptografischer Primitive,
• Nutzung eines geeigneten Zufallszahlengenerators, wenn kryptografisch sichere Zu-
fallszahlen erforderlich sind.

Anforderungen

# MSTG-ID Beschreibung L1 L2

3.1 MSTG-CRYPTO-1 Verschlüsselung in der App basiert nicht nur auf x x


symmetrischer Kryptografie mit hart-codierten
Schlüsseln.

3.2 MSTG-CRYPTO-2 Die App nutzt bewährte Implementierungen zur x x


Umsetzung kryptografischer Primitive.

3.3 MSTG-CRYPTO-3 Die App nutzt kryptografische Primitive passend x x


zum spezifischen Anwendungsfall, konfiguriert
nach Best-Practice Vorgaben dem Stand der
Technik entsprechend.

3.4 MSTG-CRYPTO-4 Die App nutzt keine kryptografischen Protokolle x x


oder Algorithmen die allgemein als veraltet und
unsicher gelten.

3.5 MSTG-CRYPTO-5 Die App verwendet einen kryptografischen x x


Schlüssel für genau einen Zweck und nicht für
mehrere Zwecke.

3.6 MSTG-CRYPTO-6 Alle Zufallswerte werden über einen x x


ausreichend sicheren kryptografischen
Zufallszahlengenerator erzeugt.

27
OWASP Mobile Application Security Verification Standard v1.4.2

Referenzen

Der OWASP Mobile Security Testing Guide bietet detaillierte Anleitungen, um die Anfor-
derungen aus dieser Kategorie zu überprüfen.

• Android: Testing Cryptography - https://github.com/OWASP/owasp-mstg/blob/mast


er/Document/0x05e-Testing-Cryptography.md
• iOS: Testing Cryptography - https://github.com/OWASP/owasp-mstg/blob/master/D
ocument/0x06e-Testing-Cryptography.md

Weitere Informationen unter:

• OWASP Mobile Top 10: M5 (Insufficient Cryptography) - https://owasp.org/www-


project-mobile-top-10/2016-risks/m5-insufficient-cryptography
• CWE 310 (Cryptographic Issues) - https://cwe.mitre.org/data/definitions/310.html
• CWE 321 (Use of Hard-coded Cryptographic Key) - https://cwe.mitre.org/data/defin
itions/321.html
• CWE 326 (Inadequate Encryption Strength) - https://cwe.mitre.org/data/definitions
/326.html
• CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - https://cwe.mitre.or
g/data/definitions/327.html
• CWE 329 (Not Using a Random IV with CBC Mode) - https://cwe.mitre.org/data/def
initions/329.html
• CWE 330 (Use of Insufficiently Random Values) - https://cwe.mitre.org/data/definit
ions/330.html
• CWE 337 (Predictable Seed in PRNG) - https://cwe.mitre.org/data/definitions/337.h
tml
• CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator
(PRNG)) - https://cwe.mitre.org/data/definitions/338.html

28
OWASP Mobile Application Security Verification Standard v1.4.2

V4: Anforderungen an Authentifizierung und


Session Management

Zielsetzung

Ein integraler Teil der Architektur einer mobilen App ist der Login eines Nutzers an ei-
nem entfernten Service. Obwohl sich ein Großteil der Logik an dem Endpunkt abspielt,
definiert der MASVS eine Reihe von Basisanforderungen an Nutzerkonten und Session-
Management.

Anforderungen

# MSTG-ID Beschreibung L1 L2

4.1 MSTG-AUTH-1 Falls die App Nutzern Zugriff auf entfernte x x


Service APIs bietet, wird am API-Endpunkt eine
Authentifizierung z.B. mit Nutzername/Passwort
durchgeführt.

4.2 MSTG-AUTH-2 Kommt Session-Management am API-Endpunkt x x


zum Einsatz, so werden zufällig generierte
Session-IDs erzeugt, um Client-Anfragen zu
authentifizieren und keine
Nutzer-Anmeldedaten versandt.

4.3 MSTG-AUTH-3 Kommt statuslose Token-basierte x x


Authentifizierung zum Einsatz, so werden die
Token am Server mit einem sicheren
Algorithmus signiert.

4.4 MSTG-AUTH-4 Der API-Endpunkt beendet die existierende x x


Nutzersitzung, sobald sich der Nutzer abmeldet.

4.5 MSTG-AUTH-5 Es existiert eine Passwort-Richtlinie, die am x x


entfernten API-Endpunkt erzwungen wird.

4.6 MSTG-AUTH-6 Der entfernte API-Endpunkt implementiert einen x x


Mechanismus, um sich gegen eine exzessive
Anzahl von Login-Versuchen zu schützen.

29
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung L1 L2

4.7 MSTG-AUTH-7 Nach einer definierten Inaktivitätsdauer werden x x


Nutzersitzungen am entfernten API-Endpunkt
beendet und Zugriffs-Tokens werden nach
Ablauf der Gültigkeitsdauer abgelehnt.

4.8 MSTG-AUTH-8 Biometrische Authentifizierung basiert auf dem x


Betriebssystem-basierten Entsperren des
Keystores (Android)/der Keychain (iOS) und
nicht auf einer z.B. event-basierten API die
einfach “true” oder “false” zurück liefert.

4.9 MSTG-AUTH-9 Es gibt einen 2. Authentifizierungsfaktor und er x


wird am entfernten API-Endpunkt konsistent
erzwungen.

4.10 MSTG-AUTH-10 Sensible Transaktionen erfordern eine x


zusätzliche Authentifizierung (durch einen
weiteren Authentifizierungsfaktor).

4.11 MSTG-AUTH-11 Die App informiert den Nutzer über alle x


Anmelde-Vorgänge am Nutzerkonto. Nutzer
können eine Liste aller mit dem Konto
verbundenen Geräte sowie kontextbezogene
Informationen (IP Adresse, Lokation usw.) sehen
und ausgewählte Geräte blockieren.

4.12 MSTG-AUTH-12 Authentifizierung wird am API-Endpunkt x


definiert und überprüft.

Referenzen

Der OWASP Mobile Security Testing Guide bietet detaillierte Anleitungen, um die Anfor-
derungen aus dieser Kategorie zu überprüfen.

• General: Authentication and Session Management - https://github.com/OWASP/o


wasp-mstg/blob/master/Document/0x04e-Testing-Authentication-and-Session-
Management.md
• Android: Testing Local Authentication - https://github.com/OWASP/owasp-mstg/blo
b/master/Document/0x05f-Testing-Local-Authentication.md
• iOS: Testing Local Authentication - https://github.com/OWASP/owasp-mstg/blob/ma

30
OWASP Mobile Application Security Verification Standard v1.4.2

ster/Document/0x06f-Testing-Local-Authentication.md

Weitere Informationen unter:

• OWASP Mobile Top 10: M4 (Insecure Authentication) - https://owasp.org/www-proj


ect-mobile-top-10/2016-risks/m4-insecure-authentication
• OWASP Mobile Top 10: M6 (Insecure Authorization) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m6-insecure-authorization
• CWE 287 (Improper Authentication) - https://cwe.mitre.org/data/definitions/287.h
tml
• CWE 307 (Improper Restriction of Excessive Authentication Attempts) - https://cwe.
mitre.org/data/definitions/307.html
• CWE 308 (Use of Single-factor Authentication) - https://cwe.mitre.org/data/definitio
ns/308.html
• CWE 521 (Weak Password Requirements) - https://cwe.mitre.org/data/definitions/5
21.html
• CWE 604 (Use of Client-Side Authentication) - https://cwe.mitre.org/data/definitions
/604.html
• CWE 613 (Insufficient Session Expiration) - https://cwe.mitre.org/data/definitions/6
13.html

31
OWASP Mobile Application Security Verification Standard v1.4.2

V5: Anforderungen an Netzwerkkommunikation

Zielsetzung

Der Zweck dieser Kategorie ist es die Vertraulichkeit und Integrität übertragener Daten
zwischen mobiler App und entferntem Server zu gewährleisten. Dazu muss eine mobile
App einen sicheren, verschlüsselten Kanal zur Netzwerkkommunikation unter Nutzung
des TLS-Protokolls mit adäquaten TLS-Einstellungen aufbauen. Level 2 benennt zusätzli-
che Defense-in-Depth Maßnahmen wie SSL-Pinning.

Anforderungen

# MSTG-ID Beschreibung L1 L2

5.1 MSTG-NETWORK-1 Daten werden zur Netzwerkkommunikation x x


innerhalb der App durchgängig mit TLS
verschlüsselt.

5.2 MSTG-NETWORK-2 Die TLS-Einstellungen entsprechen aktuellen x x


Best Practices, oder erfüllen die Best Practices
so gut wie möglich, falls das mobile
Betriebssystem die Empfehlung nicht
unterstützt.

5.3 MSTG-NETWORK-3 Die App überprüft das X.509-Zertifikat des x x


Servers beim TLS-Handshake. Die App
akzeptiert nur Zertifikate die von einer
vertrauenswürdigen Zertifizierungsstelle
signiert wurden.

5.4 MSTG-NETWORK-4 Die App nutzt entweder ihren eigenen x


Zertifikatspeicher oder nutzt Public Key-/
Zertifikats-Pinning und akzeptiert deshalb keine
Verbindungen zu Endpunkten die andere
Zertifikate/Schlüssel präsentieren - selbst wenn
die Zertifikate von einer vertrauenswürdigen
Zertifizierungsstelle signiert sind.

5.5 MSTG-NETWORK-5 Die App nutzt keine unsicheren x


Kommunikationskanäle wie E-Mail oder SMS für
kritische Operationen wie Konten-Registrierung
oder Konten-Reaktivierung.

32
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung L1 L2

5.6 MSTG-NETWORK-6 Die App nutzt aktuelle Bibliotheken zum Aufbau x


von sicheren Kommunikationsverbindungen.

Referenzen

Der OWASP Mobile Security Testing Guide bietet detaillierte Anleitungen, um die Anfor-
derungen aus dieser Kategorie zu überprüfen.

• General: Testing Network Communication - https://github.com/OWASP/owasp-


mstg/blob/master/Document/0x04f-Testing-Network-Communication.md
• Android: Testing Network Communication - https://github.com/OWASP/owasp-mstg
/blob/master/Document/0x05g-Testing-Network-Communication.md
• iOS: Testing Network Communication - https://github.com/OWASP/owasp-mstg/blo
b/master/Document/0x06g-Testing-Network-Communication.md

Weitere Informationen unter:

• OWASP Mobile Top 10: M3 (Insecure Communication) - https://owasp.org/www-


project-mobile-top-10/2016-risks/m3-insecure-communication
• CWE 295 (Improper Certificate Validation) - https://cwe.mitre.org/data/definitions/2
95.html
• CWE 296 (Improper Following of a Certificate’s Chain of Trust) - https://cwe.mitre.or
g/data/definitions/296.html
• CWE 297 (Improper Validation of Certificate with Host Mismatch) - https://cwe.mitr
e.org/data/definitions/297.html
• CWE 298 (Improper Validation of Certificate Expiration) - https://cwe.mitre.org/data
/definitions/298.html
• CWE 308 (Use of Single-factor Authentication) - https://cwe.mitre.org/data/definitio
ns/308.html
• CWE 319 (Cleartext Transmission of Sensitive Information) - https://cwe.mitre.org/
data/definitions/319.html
• CWE 326 (Inadequate Encryption Strength) - https://cwe.mitre.org/data/definitions
/326.html
• CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - https://cwe.mitre.or
g/data/definitions/327.html
• CWE 780 (Use of RSA Algorithm without OAEP) - https://cwe.mitre.org/data/definit
ions/780.html
• CWE 940 (Improper Verification of Source of a Communication Channel) - https:
//cwe.mitre.org/data/definitions/940.html

33
OWASP Mobile Application Security Verification Standard v1.4.2

• CWE 941 (Incorrectly Specified Destination in a Communication Channel) - https:


//cwe.mitre.org/data/definitions/941.html

34
OWASP Mobile Application Security Verification Standard v1.4.2

V6: Anforderungen zur Plattform-Interaktion

Zielsetzung

Die Anforderungen aus dieser Kategorie sollen sicherstellen, dass Plattform-Komponenten


und Standard-Komponenten von der App auf sichere Weise genutzt werden. Zusätzlich
decken die Anforderungen auch die Kommunikation (IPC) zwischen Apps ab.

Anforderungen

# MSTG-ID Beschreibung L1 L2

6.1 MSTG-PLATFORM-1 Die App fordert vom Nutzer nur die unbedingt x x
erforderlichen App-Berechtigungen.

6.2 MSTG-PLATFORM-2 Alle Eingaben von externen Quellen und dem x x


Nutzer werden validiert und falls erforderlich
bereinigt. Dazu gehören Daten aus der GUI, IPC
Mechanismen wie Intents oder spezifische
URL-Schemas und Netzwerk-Daten.

6.3 MSTG-PLATFORM-3 Die App bietet keine sensible Funktionalität über x x


App-eigene URL-Schemas an - wenn doch, ist
der Mechanismus angemessen geschützt.

6.4 MSTG-PLATFORM-4 Die App bietet keine sensible Funktionalität über x x


Interprozesskommunikation (IPC) an - wenn
doch, ist der Mechanismus angemessen
geschützt.

6.5 MSTG-PLATFORM-5 JavaScript ist in WebViews deaktiviert, wenn es x x


nicht unbedingt erforderlich ist.

6.6 MSTG-PLATFORM-6 WebViews sind so konfiguriert, dass nur die x x


minimal nötigen Protokoll-Handler erlaubt sind
(Idealerweise nur HTTPS). Potenziell gefährliche
Handler wie file, tel und app-id sind deaktiviert.

35
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung L1 L2

6.7 MSTG-PLATFORM-7 Wenn eine WebView über Javascript Zugriff auf x x


native Methoden einer App bekommt, ist
sichergestellt, dass die WebView nur
vorgegebenes Javascript aus der App rendert
und kein Javascript aus externen Quellen.

6.8 MSTG-PLATFORM-8 Objektserialisierung wird, falls vorhanden, über x x


eine sichere Serialisierungs-API implementiert.

6.9 MSTG-PLATFORM-9 Die App verwendet Mechanismen, um sich vor x


Screen Overlay Angriffen zu schützen (nur
Android).

6.10 MSTG-PLATFORM-10 Cache, Speicher und geladene Ressourcen x


(JavaScript usw.) eines WebViews sollten
gelöscht werden bevor der WebView
geschlossen wird.

6.11 MSTG-PLATFORM-11 Die App sollte verhindern das 3rd Party x


Tastaturen verwendet werden, wenn sensible
Daten eingegeben werden (nur iOS).

Referenzen

Der OWASP Mobile Security Testing Guide bietet detaillierte Anleitungen, um die Anfor-
derungen aus dieser Kategorie zu überprüfen.

• Android: Testing Platform Interaction - https://github.com/OWASP/owasp-mstg/blo


b/master/Document/0x05h-Testing-Platform-Interaction.md
• iOS: Testing Platform Interaction - https://github.com/OWASP/owasp-mstg/blob/ma
ster/Document/0x06h-Testing-Platform-Interaction.md

Weitere Informationen unter:

• OWASP Mobile Top 10: M1 (Improper Platform Usage) - https://owasp.org/www-


project-mobile-top-10/2016-risks/m1-improper-platform-usage
• OWASP Mobile Top 10: M7 (Poor Code Quality) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m7-client-code-quality
• CWE 20 (Improper Input Validation) - https://cwe.mitre.org/data/definitions/20.html
• CWE 79 (Improper Neutralization of Input During Web Page Generation) - https:
//cwe.mitre.org/data/definitions/79.html

36
OWASP Mobile Application Security Verification Standard v1.4.2

• CWE 200 (Information Leak / Disclosure) - https://cwe.mitre.org/data/definitions/2


00.html
• CWE 250 (Execution with Unnecessary Privileges) - https://cwe.mitre.org/data/defin
itions/250.html
• CWE 672 (Operation on a Resource after Expiration or Release) - https://cwe.mitre.
org/data/definitions/672.html
• CWE 749 (Exposed Dangerous Method or Function) - https://cwe.mitre.org/data/def
initions/749.html
• CWE 772 (Missing Release of Resource after Effective Lifetime) - https://cwe.mitre.
org/data/definitions/772.html
• CWE 920 (Improper Restriction of Power Consumption) - https://cwe.mitre.org/data
/definitions/920.html
• CWE 925 (Improper Verification of Intent by Broadcast Receiver) - https://cwe.mitre.
org/data/definitions/925.html
• CWE 926 (Improper Export of Android Application Components) - https://cwe.mitre.
org/data/definitions/926.html
• CWE 927 (Use of Implicit Intent for Sensitive Communication) - https://cwe.mitre.or
g/data/definitions/927.html
• CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - https://cwe.
mitre.org/data/definitions/939.html

37
OWASP Mobile Application Security Verification Standard v1.4.2

V7: Anforderungen zu Code Qualität und


Build-Einstellungen

Zielsetzung

Das Ziel dieser Kategorie ist, sicherzustellen, dass bei der App-Entwicklung Basis-
Security-Praktiken eingehalten werden und die enthaltenen Sicherheits-Funktionen des
Compilers aktiviert sind.

Anforderungen

# MSTG-ID Beschreibung L1 L2

7.1 MSTG-CODE-1 Die App ist signiert und mit einem gültigen x x
Zertifikat provisioniert dessen privater Schlüssel
angemessen geschützt ist.

7.2 MSTG-CODE-2 Die App wurde im Release-Modus gebaut und x x


mit passenden Release-Einstellungen (kein
Debugging).

7.3 MSTG-CODE-3 Debugging Symbole wurden von nativen x x


Binärdateien entfernt.

7.4 MSTG-CODE-4 Debugging Code und “Entwicklerüberbleibsel” x x


(z.B. Test Code, backdoors oder versteckte
Einstellungen) wurden entfernt und die
App-Logdateien enthalten keine ausführlichen
Fehler oder Debug-Meldungen.

7.5 MSTG-CODE-5 Bibliotheken und Frameworks von x x


Drittanbietern, die die App nutzt, wurden auf
Schwachstellen geprüft.

7.6 MSTG-CODE-6 Die App führt eine sichere Fehlerbehandlung x x


durch, indem sie Exceptions abfängt und
kontrolliert behandelt.

7.7 MSTG-CODE-7 Treten in Sicherheitsfunktionen Fehler auf, lehnt x x


die App-Fehlerbehandlung die Zugriffe
standardmäßig ab.

38
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung L1 L2

7.8 MSTG-CODE-8 Das Speichermanagement (Allokation und x x


Freigabe von Speicher) erfolgt in unmanaged
code auf sichere Weise.

7.9 MSTG-CODE-9 Angebotene Sicherheitsfunktionen der x x


Entwicklungsumgebung wie Byte-Code
Minimierung, Stack-Protection, PIE-Support und
automatisches Reference-Counting sind
aktiviert.

Referenzen

Der OWASP Mobile Security Testing Guide bietet detaillierte Anleitungen, um die Anfor-
derungen aus dieser Kategorie zu überprüfen.

• Android: Testing Code Quality and Build Settings - https://github.com/OWASP/owasp-


mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md
• iOS: Testing Code Quality and Build Settings - https://github.com/OWASP/owasp-
mstg/blob/master/Document/0x06i-Testing-Code-Quality-and-Build-Settings.md

Weitere Informationen unter:

• OWASP Mobile Top 10: M7 (Poor Code Quality) - https://owasp.org/www-project-


mobile-top-10/2016-risks/m7-client-code-quality
• CWE 20 (Improper Input Validation) - https://cwe.mitre.org/data/definitions/20.html
• CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) -
https://cwe.mitre.org/data/definitions/89.html
• CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval
Injection’)) - https://cwe.mitre.org/data/definitions/95.html
• CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
- https://cwe.mitre.org/data/definitions/119.html
• CWE 215 (Information Exposure through Debug Information) - https://cwe.mitre.or
g/data/definitions/215.html
• CWE 388 (7PK - Errors) - https://cwe.mitre.org/data/definitions/388.html
• CWE 489 (Leftover Debug Code) - https://cwe.mitre.org/data/definitions/489.html
• CWE 502 (Deserialization of Untrusted Data) - https://cwe.mitre.org/data/definitio
ns/502.html
• CWE 511 (Logic/Time Bomb) - https://cwe.mitre.org/data/definitions/511.html
• CWE 656 (Reliance on Security through Obscurity) - https://cwe.mitre.org/data/def
initions/656.html

39
OWASP Mobile Application Security Verification Standard v1.4.2

• CWE 676 (Use of Potentially Dangerous Function) - https://cwe.mitre.org/data/defin


itions/676.html
• CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vul-
nerabilities) - https://cwe.mitre.org/data/definitions/937.html

40
OWASP Mobile Application Security Verification Standard v1.4.2

V8: Anforderungen an
Manipulationssicherheit/Resilienz

Zielsetzung

Diese Kategorie behandelt Defense-in-Depth-Maßnahmen empfohlen für Apps, die Zu-


griff auf sensible Daten oder sensible Funktionalitäten beinhalten. Sind diese Maßnahmen
nicht umgesetzt, führt dies nicht unmittelbar zu einer Schwachstelle - jedoch erhöhen die
Maßnahmen die Robustheit der App gegen Client-seitige Angriffe und Reverse Enginee-
ring.

Die Schutzmechanismen in diesem Abschnitt sollten nach Bedarf angewendet werden.


Anhand einer Risikoprüfung sollten Risiken wie unerlaubte Manipulation der App oder Re-
verse Engineering des Codes bewertet werden. Es wird empfohlen das OWASP Dokument
“Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse En-
gineering and Code Modification Prevention” (siehe Referenzen) zu nutzen um eine Liste
mit Geschäftsrisiken und zugeordneten technischen Bedrohungen zu identifizieren.

Um die hier aufgeführten Schutzmechanismen effektiv umsetzen zu können muss eine


App mindestens alle Anforderungen aus MASVS-L1 sowie die jeweiligen Anforderungen
aus Kategorie V8 in aufsteigender Reihenfolge umsetzen. So setzen die Schutzmaßnah-
men unter “Nachvollziehbarkeit verhindern” voraus, dass auch die Anforderungen aus
“Dynamische Analyse und Manipulation verhindern” und “Gerätebindung” umgesetzt
werden.

Achtung: Diese Software-Schutzmaßnahmen sind kein Ersatz für die Umset-


zung adäquater Sicherheitsmaßnahmen. Die Maßnahmen aus MASVR-R sind
gedacht, um auf Basis App-spezifischer konkreter Bedrohungen zusätzliche
Schutzmaßnahmen über die bereits umgesetzten Sicherheitsmaßnahmen aus
MASVS hinaus umzusetzen.

Folgende Eckpunkte gelten:

1. Eine Bedrohungsanalyse wurde durchgeführt. Darin werden wesentliche Client-


seitige Bedrohungen und Gegenmaßnahmen sowie der erforderliche Schutzbedarf
dargestellt. Ein Aspekt zum Schutzbedarf könnte beispielsweise sein den Aufwand
zum manuellen Reverse Engineering einer App für Malware-Autoren, die die App
instrumentieren wollen, signifikant zu erhöhen.

2. Die Bedrohungsanalyse muss realistisch und vernünftig erfolgen. Zum Beispiel nützt
es nichts, einen kryptografischen Schlüssel in einer White-Box-Implementierung zu
“verbergen” wenn doch der Angreifer ohne weiteres an den Code kommt.

3. Die Effektivität der Schutzmaßnahmen sollte immer von einem Experten mit aus-
gewiesener Erfahrung im Bereich Anti-Code-Manipulation und Code-Obfuskierung

41
OWASP Mobile Application Security Verification Standard v1.4.2

überprüft werden (siehe auch Kapitel “reverse engineering” and “assessing soft-
ware protections” im Mobile Security Testing Guide).

Dynamische Analyse und Manipulation verhindern

# MSTG-ID Beschreibung R

8.1 MSTG-RESILIENCE-1 Die App erkennt und reagiert auf ein gerootetes x
Gerät oder Geräte mit Jailbreak, indem der
Nutzer gewarnt oder die App beendet wird.

8.2 MSTG-RESILIENCE-2 Die App verhindert Debugging und/oder erkennt x


und reagiert auf einen Debugger. Alle
verfügbaren Debugging-Protokolle müssen
abgedeckt werden.

8.3 MSTG-RESILIENCE-3 Die App erkennt und reagiert auf Manipulationen x


an ausführbaren Dateien und kritischen Daten
innerhalb der App-eigenen Sandbox.

8.4 MSTG-RESILIENCE-4 Die App erkennt und reagiert auf typische und x
allgemein bekannte Reverse Engineering Tools
und Frameworks auf dem Gerät.

8.5 MSTG-RESILIENCE-5 Die App erkennt und reagiert darauf, wenn sie in x
einem Emulator ausgeführt wird.

8.6 MSTG-RESILIENCE-6 Die App erkennt und reagiert auf Manipulation x


von Code und Daten im eigenen
Arbeitsspeicherbereich.

8.7 MSTG-RESILIENCE-7 Die App realisiert mehrere Mechanismen in jeder x


Kategorie (8.1 bis 8.6). Die Resilienz steigt mit
der Anzahl, Vielfalt und Originalität der genutzten
Mechanismen.

8.8 MSTG-RESILIENCE-8 Die Erkennungsmechanismen der App lösen x


verschiedene Arten von Reaktionen aus z.B.
verzögerte, versteckte oder heimliche
Reaktionen.

42
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung R

8.9 MSTG-RESILIENCE-9 Programmatische Abwehrmaßnahmen werden x


durch Obfuskierung geschützt was wiederum
De-Obfuskierung mittels dynamischer Analyse
verhindert.

Gerätebindung

# MSTG-ID Beschreibung R

8.10 MSTG-RESILIENCE-10 Die App implementiert einen Mechanismus zur x


Gerätebindung, bei dem der
Geräte-Fingerabdruck aus mehreren
einzigartigen Geräteeigenschaften ermittelt wird.

Nachvollziehbarkeit verhindern

# MSTG-ID Beschreibung R

8.11 MSTG-RESILIENCE-11 Alle ausführbaren Dateien und Bibliotheken der x


App sind entweder auf Dateiebene verschlüsselt
und/oder wichtige Code- und Datensegmente in
ausführbaren Dateien sind verschlüsselt oder
durch Packing obfuskiert. Triviale statische
Analyse offenbart keinen wichtigen Code oder
Daten.

43
OWASP Mobile Application Security Verification Standard v1.4.2

# MSTG-ID Beschreibung R

8.12 MSTG-RESILIENCE-12 Wenn das Ziel der Obfuskierung der Schutz x


sensibler Logik wie Algorithmen oder
Berechnungen ist, so wird ein angemessener
Obfuskierungsmechanismus, dem Stand der
Technik entsprechend, genutzt der resilient
gegen manuelle und automatisierte
De-Obfuskierungsangriffe ist. Die Wirksamkeit
der Obfuskierungsmethode muss durch manuelle
Tests überprüft werden. Es ist zu beachten, dass
hardware-basierte Isolations-Mechanismen
softwarebasierter Obfuskierung vorzuziehen sind.

Abhören erschweren

# MSTG-ID Beschreibung R

8.13 MSTG-RESILIENCE-13 Neben einer gehärteten Kommunikation zwischen x


Client und API-Endpunkt, sollte auch der
übertragene Payload verschlüsselt werden, um
das Abhören von Daten zu erschweren.

Referenzen

Der OWASP Mobile Security Testing Guide bietet detaillierte Anleitungen, um die Anfor-
derungen aus dieser Kategorie zu überprüfen.

• Android: Testing Resiliency Against Reverse Engineering - https://github.com/OWA


SP/owasp-mstg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-
Engineering.md
• iOS: Testing Resiliency Against Reverse Engineering - https://github.com/OWASP
/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-
Engineering.md

Weitere Informationen unter:

• OWASP Mobile Top 10: M8 (Code Tampering) - https://owasp.org/www- project-


mobile-top-10/2016-risks/m8-code-tampering

44
OWASP Mobile Application Security Verification Standard v1.4.2

• OWASP Mobile Top 10: M9 (Reverse Engineering) - https://owasp.org/www-project-


mobile-top-10/2016-risks/m9-reverse-engineering
• OWASP Reverse Engineering Threats - https://wiki.owasp.org/index.php/Technical
_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification
• OWASP Reverse Engineering and Code Modification Prevention - https://wiki.owasp
.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_P
roject

45
OWASP Mobile Application Security Verification Standard v1.4.2

Appendix A: Glossar

• Address Space Layout Randomization (ASLR) – Eine Technik um Angriffe auf


Arbeitsspeicherbereiche zu erschweren.
• Akzeptanztest (UAT) – Eine Testumgebung die sich ähnlich verhält wie die Produk-
tivumgebung, in der Tests vor dem go-live ausgeführt werden.
• Applikationssicherheit – Applikationssicherheit ist fokussiert auf Sicherheits-
aspekte und Angriffe auf Anwendungsebene d.h. Applikationskomponenten und
-funktionen korrespondierend zur Anwendungsschicht im Open Systems Intercon-
nection Reference Model (OSI Modell). Der Fokus liegt nicht auf Betriebssystem-
oder Netzwerkaspekten.
• Authentifizierung – Die Überprüfung der angegebenen Identität eines Nutzers.
• Automatisierte Prüfungen – Die Nutzung automatisierter Werkzeuge (dynami-
sche/statische Analyse oder beides) die Schwachstellen anhand von Signaturen iden-
tifizieren.
• Bedrohungsanalyse – Eine Methodik die dazu dient Sicherheitsschwachstellen im
Design einer Anwendung zu identifizieren und Gegenmaßnahmen zu entwickeln,
um die Sicherheitsarchitektur zu verbessern. Dabei werden relevante Gruppen von
Angreifern, Sicherheitszonen, Sicherheitsmechanismen sowie technische und fach-
liche Wertgegenstände identifiziert und einbezogen.
• Black box Tests – Ist eine Testmethode bei der die Funktionalität einer Komponente
oder Anwendung “von außen” ohne Wissen über interne Strukturen und Mechanis-
men getestet wird.
• Cross-Site Scripting (XSS) – Eine Sicherheitsschwachstelle die typischerweise in
Web-Applikationen vorkommt die das Einschleusen von Client-seitigem Script-Code
in den Seiteninhalt zulassen.
• CWE – Common Weaknesses Enumeration - CWE ist eine Community-basierte
Sammlung von allgemeinen Software Security Schwächen. Sie dient als gemeinsa-
me Sprache, als Messlatte für Software-Sicherheits-Tools und als Grundlage für die
Identifizierung von Schwachstellen sowie für Maßnahmen zur Schadensbegrenzung
und -vermeidung.
• DAST – Dynamische Applikations-Security Tests (DAST) dienen der Erkennung von
Sicherheitsschwachstellen einer Applikation zur Laufzeit.
• Dynamische Prüfungen – Die Nutzung automatisierter Werkzeuge um zur Lauf-
zeit einer Applikation Sicherheitsschwachstellen auf Basis von Signaturprüfungen
zu finden.
• Eingabe-Validierung – Überführung in eine standardisierte Form (Kanonisierung)
und Prüfung von Eingabedaten denen nicht vertraut wird z.B. Nutzereingaben oder
Request-Parameter.
• Globally Unique Identifier(GUID) – Eine einzigartige Referenz-Nummer die als
Identifikator in einer Software genutzt werden kann.

46
OWASP Mobile Application Security Verification Standard v1.4.2

• Hartcodierte Schlüssel – Kryptografische Schlüssel die auf unsichere Weise direkt


im Quellcode oder der Anwendungskonfiguration hinterlegt sind.
• Hyper Text Transfer Protocol (HTTP) – Ein Kommunikations-Protokoll für verteilte
Informationssysteme auf Basis von Hypermedia und damit die Basis der Datenkom-
munikation im weltweiten Internet.
• IPC – Interprozesskommunikation - Mit IPC kommunizieren Prozesse über
Betriebssystem-Mechanismen mit dem Kernel und untereinander um Aktivitä-
ten zu koordinieren oder Daten auszutauschen.
• Java Bytecode – Java Bytecode ist der Befehlssatz der Java Virtual Machine (JVM).
Ein Bytecode besteht aus einem oder in einigen Fällen zwei Bytes die einen Befehl
(OP-Code) repräsentieren sowie optional weitere Bytes die als Parameter für den
OP-Code dienen.
• Komponente – Eine Zusammenfassung einzelner Code-Elemente zu einer eigen-
ständigen Einheit mit Zugriffen auf Speicher- und Netzwerkschnittstellen um mit
anderen Komponenten zu kommunizieren.
• Kryptographisches Modul – Hardware, Software, und/oder Firmware, die krypto-
grafische Algorithmen und/oder erzeugte kryptografische Schlüssel nutzt.
• Malicious Code – Bösartiger Code der während der Entwicklung, verborgen vor
dem Applikationsverantwortlichen, in die Applikation eingebracht wird. Der einge-
schleuste Code umgeht dabei gezielt Sicherheitsrichtlinien und ist dadurch nicht
vergleichbar mit Malware wie einem Virus oder einem Wurm!
• Malware – Ausführbarer Code der zur Laufzeit ohne Wissen des Nutzers oder Admi-
nistrators in die Zielanwendung injiziert wird.
• Open Web Application Security Project (OWASP) – Open Web Application Se-
curity Project (OWASP) ist eine weltweite freie, offene und herstellerunabhängige
Community mit Fokus auf Verbesserung der Applikationssicherheit. Unsere Mission
ist es Applikationssicherheit sichtbar zu machen, sodass Einzelpersonen und Organi-
sationen klare und bewusste Entscheidungen über Sicherheitsrisiken treffen können.
Mehr unter: https://www.owasp.org/
• Personenbezogene Daten – Personenbezogene Daten sind Daten die genutzt wer-
den können um eine Person direkt oder indirekt zu identifizieren, kontaktieren oder
lokalisieren bzw. eine Person in einem Zusammenhang zu identifizieren.
• PIE – Position-independent executable (PIE) - Positionsunabhängiger Code ist Ma-
schinencode der an einer beliebigen Stelle im primären Speicher ausgeführt werden
kann. (unabhängig von der absoluten Speicheradresse)
• PKI – Public Key Infrastruktur - PKI basiert darauf, dass öffentliche Schlüssel an eine
Identität gebunden werden. Die Bindung erfolgt durch einen Registrierungsprozess
und das Ausstellen eines Zertifikats durch eine Zertifizierungsstelle, in Englisch Cer-
tificate Authority (CA).
• Prüfer – Eine Person oder ein Team, dass eine Anwendung gegen den OWASP MASVS
prüft.

47
OWASP Mobile Application Security Verification Standard v1.4.2

• Prüfung zur Applikationssicherheit – Die technische Prüfung einer Applikation


gegen den OWASP MASVS.
• Prüfbericht zur Applikationssicherheit – Ein Prüfbericht, für eine Applikation,
der die Analyseschritte eines Prüfers sowie die Gesamtergebnisse dokumentiert.
• SAST – Statische Applikations-Security-Tests (SAST) sind eine Reihe von Techniken,
die dazu genutzt werden können, potenzielle Sicherheitsschwachstellen in Quell-
code, Bytecode und Binärdateien zu identifizieren. SAST Lösungen analysieren eine
Applikation typischerweise zur Entwicklungs- oder Buildzeit jedoch nicht zur Lauf-
zeit.
• SDLC – Software development lifecycle.
• Sicherheitsarchitektur – Eine Abstraktion des Applikations-Designs einer Anwen-
dung bei der dokumentiert wird an welchen Stellen und in welchem Maße Sicher-
heitsmechanismen genutzt werden. Darüber hinaus wird beschrieben an welchen
Stellen im System sensible Nutzer- und Anwendungsdaten verarbeitet werden.
• Sicherheitsarchitekturanalyse – Die technische Prüfung der Sicherheitsarchitek-
tur einer Applikation.
• Sicherheitskonfiguration – Die Laufzeitkonfiguration einer Anwendung; enthält
Optionen, die die Sicherheitsfunktionen beeinflussen.
• Sicherheitsmechanismus – Eine Sicherheitsfunktion oder Komponente die Sicher-
heitsprüfungen durchführt z.B. eine Autorisierungsprüfung oder das Erzeugen eines
Eintrags im Audit-Log beim Login eines Administrators.
• SQL Injection (SQLi) – Eine Technik um Code in datengetriebene Anwendungen
einzuschleusen. Dabei werden schadhafte SQL-Anweisungen in Nutzereingaben ein-
geschleust und in der Datenbank zur Ausführung gebracht.
• SSO Authentifizierung – Single Sign On(SSO) bedeutet, ein Nutzer muss sich an
einer Applikation einloggen und ist dann automatisch an weiteren Anwendungen
angemeldet. Damit können sich Nutzer u.U. über mehrere unterschiedliche Plattfor-
men, Technologien und Domains anmelden. Zum Beispiel ist man bei Google nach
der Nutzeranmeldung automatisch auch für Youtube, Google-Docs und Google-Mail
angemeldet.
• Transport Layer Security (TLS) – Kryptografisches Protokoll um die Vertraulich-
keit, Integrität und Authentizität von Daten während der Übertragung im Internet
abzusichern.
• URI/URL/URL Fragmente – Eine URI (Uniform Resource Identifier) ist eine Zeichen-
folge um einen Namen oder eine Webressource zu identifizieren. Ein URL (Uniform
Resource Locator) wird oft als Referenz auf eine Webressource genutzt.
• Whitelist – Eine Liste erlaubter Operationen zum Beispiel eine Liste erlaubter Buch-
staben die zur Eingabe-Validierung genutzt werden soll.
• X.509 Zertifikat – Ein X.509 Zertifikat ist ein digitales Zertifikat das eine interna-
tional standardisierten PKI-Standard nutzt, um nachzuweisen, dass ein öffentlicher
Schlüssel zu einem Nutzer, einem Computer oder einer Serviceidentität, aufgeführt

48
OWASP Mobile Application Security Verification Standard v1.4.2

in dem Zertifikat, gehört.

49
OWASP Mobile Application Security Verification Standard v1.4.2

Appendix B: Referenzen

Die folgenden OWASP Projekte könnten für Anwender dieses Standards nützlich sein:

• OWASP Mobile Security Project - https://owasp.org/www-project-mobile-security/


• OWASP Mobile Security Testing Guide - https://owasp.org/www-project-mobile-
security-testing-guide/
• OWASP Mobile Top 10 Risks - https://owasp.org/www-project-mobile-top-10/
• OWASP Reverse Engineering and Code Modification Prevention - https://wiki.owasp
.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_P
roject

Die folgenden Webseiten könnten ebenfalls für Anwender dieses Standards nützlich
sein:

• MITRE Common Weakness Enumeration - http://cwe.mitre.org/


• PCI Security Standards Council - https://www.pcisecuritystandards.org
• PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Pro-
cedures https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

50
OWASP Mobile Application Security Verification Standard v1.4.2

Versionshistorie

V1.3 - 13 May 2021

We are proud to announce the introduction of a new document build pipeline, which is
a major milestone for our project. The build pipeline is based on Pandocker and Github
Actions. This significantly reduces the time spent on creating new releases and will also
be the foundation for the OWASP MSTG and will be made available for the OWASP ASVS
project.

Changes

• 4 more translations are available, which are Hindi, Farsi, Portuguese and Brazilian
Portuguese
• Added requirement MSTG-PLATFORM-11

Special Thanks

• Jeroen Willemsen for kick-starting this initiative last year!


• Damien Clochard and Dalibo for supporting and professionalizing the build pipeline.
• All our Hindi, Farsi, Portuguese and Brazilian Portuguese collaborators for the excel-
lent translation work.

V1.2 - 7 März 2020 - Internationale Veröffentlichung

Die folgenden Änderungen sind Teil von Version 1.2:

• Übersetzung des MASVS in verinfachtes Chinesisch verfügbar.


• Änderung des Titles auf dem Cover des MASVS.
• Mobile Top 10 und CWE Referenzen wurden aus dem MSTG entfernt und zu existie-
renden Referenzen im MASVS hinzugefügt.

V1.2-RC - 5 Oktober 2019 - Pre-Release

Die folgenden Änderungen sind Teil von Version 1.2-RC:

• “Flagship Status” von OWASP erhalten.


• Anforderung MSTG-Storage-1 verändert.
• Anforderung MSTG-STORAGE-13, MSTG-STORAGE-14 und MSTG-STORAGE-15 wur-
den hinzugefügt mit Fokus auf Datenschutz.

51
OWASP Mobile Application Security Verification Standard v1.4.2

• Anforderung MSTG-CODE-4 wurde aktualisiert um mehr Fälle als nur Debugging ab-
zudecken.
• Anforderung MSTG-AUTH-11 wurde aktualisiert um “kontextbezogene Informatio-
nen”.
• Anforderung MSTG-PLATFORM-10 wurde hinzugefügt für einen weiteren Fall um Web-
Views sicher zu verwenden.
• Anforderung MSTG-AUTH-12 wurde hinzugefügt um Entwickler daran zu erinnern
Autorisierung zu implementieren, vor allem im Fall von multi-user Apps.
• Beschreibung hinzugefügt, wie der MASVS in einem Risk Assessment verwendet
werden sollte.
• Beschreibung hinzugefügt für Bezahl-Inhalte.
• Anforderung MSTG-ARCH-11 wurde hinzugefügt um Responsible Disclosure Policies
zu implementieren.
• Anforderung MSTG-ARCH-12 wurde hinzugefügt um Datenschutzgesetze zu befol-
gen.
• Anforderung MSTG-PLATFORM-11 wurde hinzugefügt um 3rd Party Tastaturen zu ver-
bieten.
• Anforderung MSTG-RESILIENCE-13 wurde hinzugefügt um das Abhören von Apps zu
erschweren.
• Die folgenden Sprachen in denen der MASVS verfügbar ist wurden aktualisiert: Chi-
nesisch (ZHTW), Englisch, Deutsch, Französisch, Russisch, Spanisch und Japanisch

V1.1.4 - 4 Juli 2019 - Summit edition

Die folgenden Änderungen sind Teil von Version 1.1.4:

• Markdown Fehler wurden alle behoben.


• Französische und Spanische Übersetzung wurden aktualisiert.
• Versionshistorie wurde übersetzt in Chinesisch (ZHTW) und Japanisch.
• Automatische überprüfung der Markdown Syntax und Erreichbarkeit von URLs.
• Jede Anforderung hat eine ID erhalten um die Suche nach Anforderungen und Test-
fällen zu vereinfachen. Die IDs werden in der kommenden Version des MSTG einge-
arbeitet.
• Größe des Github Repositories wurde reduziert und das Verzeichnis Generated wur-
de zum .gitignore hinzugefügt.
• “Code of Conduct” und “Contributing Guidelines” wurden hinzugefügt.
• Ein Pull-Request Template wurde hinzugefügt.
• Die Synchronisation zwischen dem MASVS Repository das für Gitbook genutzt wird
und Gitbook wurde aktualisiert.
• Die Skripte zum Erzeugen von XML/JSON/CSV von allen Sprachen wurden aktuali-
siert.

52
OWASP Mobile Application Security Verification Standard v1.4.2

• Das Vorwort wurde in Chinesisch (ZHTW) übersetzt.

V1.1.3 - 9 Januar 2019 - Kleine Fehlerbehebungen

Die folgenden Änderungen sind Teil von Version 1.1.3:

• Fix für Spanische Übersetzung von Anforderung 7.1.


• Neue Tabelle für Übersetzer in Danksagungen.
• Kleine fixes in der Japanischen Version.

V1.1.2 - 3 Januar 2019 - Sponsoren und Internationalisierung

Die folgenden Änderungen sind Teil von Version 1.1.2:

• Danksagung für alle Käufer, die das Buch von Leanpub gekauft haben.
• Fehlender link für Authentifizierung und Session Management hinzugefügt und ka-
putten link in V4 aktualisiert.
• Anforderung 4.7 und 4.8 ausgetauscht in englischer Version.
• Erste internationale Version!

– Fehler behoben in spanischer Version. Übersetzung ist auf gleichem Stand mit
englischer Version (1.1.2).
– Fehler behoben in russischer Version. Übersetzung ist auf gleichem Stand mit
englischer Version (1.1.2).
– Erste Version auf Chinesisch (ZHTW), Französisch, Deutsch und Japanisch!

• Dokument vereinfacht um Übersetzung zu erleichtern.


• Anleitung für automatische Erstellung von neuen MASVS Versionen hinzugefügt.

V1.1.0 - 14 Juli 2018

Die folgenden Änderungen sind Teil von Version 1.1:

• Anforderung 2.6 “The clipboard is deactivated on text fields that may contain sensi-
tive data.” wurde entfernt.
• Anforderung 2.2 “Es werden keine sensiblen Daten außerhalb des App-Containers
oder außerhalb des vom jeweiligen Betriebssystem angebotenen sicheren Speicher-
mechanismus abgelegt.” wurde hinzugefügt.
• Anforderung 2.1 wurde umformuliert zu “Die App speichert sensible Daten wie perso-
nenbezogene Daten, Anmeldedaten oder kryptographische Schlüssel unter Nutzung
der vom jeweiligen Betriebssystem angebotenen sicheren Speichermechanismen.”.

53
OWASP Mobile Application Security Verification Standard v1.4.2

V1.0 - 12 Januar 2018

Die folgenden Änderungen sind Teil von Version 1.0:

• Anforderung 8.9 wurde entfernt, da redundant zu 8.12


• Anforderung 4.6 wurde allgemeiner formuliert
• Kleine fixes (typos etc.)

54

Das könnte Ihnen auch gefallen