The document discusses the Mobile Application Security Verification Standard (MASVS) project from OWASP. It provides an overview of the MASVS levels and describes the eight verification requirements areas: 1) Architecture, Design and Threat Modeling; 2) Data Storage and Privacy; 3) Cryptography; 4) Authentication and Session Management; 5) Network Communication; 6) Platform Interaction; 7) Code Quality and Build Setting; and 8) Resilience. Each verification requirement area includes example requirements and references related information. The goal of MASVS is to provide a standard way to verify the security of mobile apps and help developers build more secure apps.

1. Prathan Phongthiproek
Mobile Security Team, OWASP Jump-Start the MASVS presentation at MiSSxTalks Special Aug 25, 2018
Content is available under Creative Commons Attribution-ShareAlike unless otherwise noted.

2. What is Mobile app ?

3. Attack Surface on Web/Mobile Application

4. Attack Surface on Mobile Application

6. Mobile AppSec Verification (MASVS) Top 10 Mobile Risks Mobile Security Testing Guide (MSTG)
M1
M5
M2 M3 M4
M6
M7 M8 M9 M10
OWASP Mobile Security Project

7. Top 10 Mobile Risks Mobile Security Testing Guide (MSTG) Mobile AppSec Verification (MASVS)
M1. Improper Platform Usage
Platform APIs
Data Storage
V6: Environmental Interaction Requirements
M2. Insecure Data Storage Data Storage V2: Data Storage and Privacy Requirements
M3. Insecure Communication Network APIs V5: Network Communication Requirements
M4. Insecure Authentication Local Authentication
V4: Authentication and Session Management
Requirements
M5. Insufficient Cryptography Cryptographic APIs V3: Cryptography Requirements
M6. Insecure Authorization -
V4: Authentication and Session Management
Requirements
M7. Client Code Quality
Code Quality and Build Settings
Platform APIs
V7: Code Quality and Build Setting Requirements
M8. Code Tampering Tampering and Reverse Engineering
V8: Resiliency Against Reverse Engineering
Requirements
M9. Reverse Engineering
Tampering and Reverse Engineering
Anti-Reversing Defenses
V8: Resiliency Against Reverse Engineering
Requirements
M10. Extraneous Functionality Code Quality and Build Settings
V1: Architecture, Design and Threat Modeling
Requirements
Top 10 x MSTG x MASVS

8. OWASP MASVS
https://github.com/OWASP/owasp-masvs

9. The MASVS Levels
R
L2
L1
Standard Security
• Follows security best practices
• Appropriate for all mobile apps
Defense-in-Depth
• Well-defined security model and added controls
• Appropriate for apps that handle sensitive data
Resiliency Against Reverse Engineering and Tampering
• Adds client side protection (e.g. Tampering, Reverse engineering)
• Optional protective layer for Intellectual property and data

10. Health-Care Industry : Mobile apps that store personally identifiable information that can be
used for identity theft or a variety of fraud schemes.
Financial Industry : Apps that enable access to highly sensitive information like credit card
Game Industry : Games with an essential need to prevent modding and cheating, such as
competitive online games.
Financial Industry: Online banking apps that allow the user to move funds, where techniques
code injection and instrumentation on compromised devices pose a risk.
All mobile apps. MASVS-L1 lists security best practices that can be followed with a reasonable
impact on development cost and user experience.
The MASVS Verification Type
L2
L1
L1+R
L2+R

11. The Verification Requirements
V1: Architecture, Design and Threat Modeling
V2: Data Storage and Privacy V3: Cryptography
V4: Authentication and
Session Management
V5: Network Communication V6: Platform Interaction
V7: Code Quality and Build
Setting
V8: Resilience

12. 1 Architecture,
Design and
Threat Modeling

13. V1: Requirements

14. Related Information
o OWASP Mobile Top 10: M10 - Extraneous Functionality
o OWASP Security Architecture Cheat Sheet
o OWASP Threat Modeling
o OWASP Secure SDLC Cheat Sheet
o Microsoft SDL
o NIST SP 800-57

15. 2 Data Storage
and Privacy

16. V2: Requirements

17. Example 2.1: System credential storage facilities are used appropriately to
store sensitive data, such as PII, user credentials or cryptographic keys

18. Example 2.7: No sensitive data, such as passwords or pins, is
exposed through the user interface

19. Example 2.8: No sensitive data is included in backups
generated by the mobile operating system

20. Example 2.9: The app removes sensitive data from views
when backgrounded

21. Related Information
o OWASP Mobile Top 10: M2 - Insecure Data Storage
o OWASP Mobile Security Testing Guide for Android and iOS - Testing Data
Storage

22. 3 Cryptography

23. V3: Requirements

24. Example 3.1: The app does not rely on symmetric cryptography
with hardcoded keys as a sole method of encryption

25. Example 3.1: The app does not rely on symmetric cryptography
with hardcoded keys as a sole method of encryption

26. Example 3.1: The app does not rely on symmetric cryptography
with hardcoded keys as a sole method of encryption

27. Related Information
o OWASP Mobile Top 10: M5 - Insufficient Cryptography
o OWASP Mobile Security Testing Guide for Android and iOS - Testing
Cryptography
o OWASP Cryptographic Storage Cheat Sheet
o OWASP Password Storage Cheat Sheet
o For example:
• Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
• Message Integrity: HMAC-SHA2
• Message Hash: SHA2 256 bits
• Asymmetric encryption: RSA 2048 bits
• Symmetric-key algorithm: AES 256 bits
• Password Hashing: Argon2, PBKDF2, Scrypt, Bcrypt.

28. 4 Authentication
and Session
Management

29. V4: Requirements

30. Example 4.1: If the app provides users access to a remote service, some form of
authentication, such as username/password authentication, is performed at the
remote endpoint

31. Example 4.1: If the app provides users access to a remote service, some form of
authentication, such as username/password authentication, is performed at the
remote endpoint
DEMO

32. Example 4.4: The remote endpoint terminates the existing
session when the user logs out

33. Example 4.7: Biometric authentication, if any, is not event-bound (i.e. using an
API that simply returns "true" or "false"). Instead, it is based on unlocking the
keychain/keystore.
DEMO

34. Example 4.10: Sensitive transactions require step-up authentication

35. Related Information
o OWASP Mobile Top 10: M4 - Insecure Authentication
o OWASP Mobile Top 10: M6 - Insecure Authorization
o OWASP Mobile Security Testing Guide for Android and iOS - Testing
Authentication and Session Management
o OWASP Authentication Cheat Sheet
o OWASP Session Management Cheat Sheet
o OWASP Transaction Authorization Cheat Sheet
o OWASP Access Control Cheat Sheet

36. 5 Network
Communication

37. V5: Requirements

38. Example 5.3: The app verifies the X.509 certificate of the remote endpoint when
the secure channel is established. Only certificates signed by a trusted CA are
accepted
SSL/TLS

39. Example 5.4: The app either uses its own certificate store, or pins the endpoint
certificate or public key, and subsequently does not establish connections with
endpoints that offer a different certificate or key, even if signed by a trusted CA
SSL/TLS

40. Related Information
o OWASP Mobile Top 10: M3 - Insecure Communication
o OWASP Mobile Security Testing Guide for Android and iOS - Testing
Network Communication
o OWASP Transport Layer Protection Cheat Sheet
o OWASP Certificate Pinning Cheat Sheet

41. 6 Platform
Interaction

42. V6: Requirements

43. Example 6.4: The app does not export sensitive functionality
through IPC facilities, unless these mechanisms are properly
protected

44. Example 6.4: The app does not export sensitive functionality
through IPC facilities, unless these mechanisms are properly
protected

45. Example 6.4: The app does not export sensitive functionality
through IPC facilities, unless these mechanisms are properly
protected
DEMO

46. Example 6.5: JavaScript is disabled in WebViews unless
explicitly required

47. Example 6.5: JavaScript is disabled in WebViews unless
explicitly required

48. Related Information
o OWASP Mobile Top 10: M1 - Improper Platform Usage
o OWASP Mobile Security Testing Guide for Android and iOS - Testing
Platform Interaction

49. 7 Code Quality and
Build Setting

50. V7: Requirements

51. Example 7.2: The app has been built in release mode, with
settings appropriate for a release build (e.g. non-debuggable)

52. Example 7.4: Debugging code has been removed, and the app
does not log verbose errors or debugging messages
DEMO

53. Related Information
o OWASP Mobile Top 10: M7 - Client Code Quality
o OWASP Mobile Security Testing Guide for Android and iOS - Testing Code
Quality and Build Settings

54. 8 Resilience

55. V8: Requirements

56. V8: Requirements (Cont’d)

57. Related Information
o OWASP Mobile Top 10: M8 - Code Tampering
o OWASP Mobile Top 10: M9 - Reverse Engineering
o OWASP Mobile Security Testing Guide for Android and iOS - Testing
Resiliency Against Reverse Engineering
o OWASP Reverse Engineering Threats
o OWASP Reverse Engineering and Code Modification Prevention

58. • OWASP Securing the SDLC (Jim Manico)
• OWASP Geneva-Chapter Meeting (Jeremy Matos)
• OWASP Mobile Top 10 Deep-Dive (Prathan Phongthiproek)
• https://github.com/OWASP/owasp-masvs
References