The document provides an in-depth overview of the OWASP Mobile Top 10 risks in mobile application security, detailing vulnerabilities such as improper platform usage, insecure data storage, and inadequate cryptography. Each risk is accompanied by mitigation strategies to enhance mobile app security, emphasizing best practices like secure coding and proper authentication methods. The resources and guidelines mentioned serve as references for developers to protect against these security threats.

1. Prathan Phongthiproek
OWASP Mobile Team
OWASP Mobile Top 10 Deep-Dive presentation at OWASP Thailand Meeting July 26, 2018
Content is available under Creative Commons Attribution-ShareAlike unless otherwise noted.

2. M1
Improper
Platform Usage
M2
Insecure Data
Storage
M3
Insecure
Communication
M4
Insecure
Authentication
M5
Insufficient
Cryptography
M6
Insecure
Authorization
M7
Client Code
Quality
M8
Code
Tampering
M9
Reverse
Engineering
M10
Extraneous
Functionality
Source: Top 10 Mobile Risks-https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
OWASPMobileTop10Risks

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

4. Top10xMSTGxMASVS
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

5. 1 Improper
Platform Usage

6. Misuse of a platform feature or lack of platform
security controls for the Android, iOS and APIs.
Issues might include Android intents, platform
permissions, the Keychain and Insecure web
server configurations.

7. ThemostcommonattackvectorhereisanyexposedAPIs
Misconfigured AWS S3 Cloud Storage Buckets

8. MisconfigurationonWebserver,WebserviceandAPIs
Improper Network Configuration and patch management

9. Inputvalidationflaws
Improper Input validation (SQL Injection, Command Injection, JSON Deserialization)

10. Inputvalidationflaws
Improper Control of Interaction Frequency on API

11. Unintentionalmisuseofmobileplatform
Backup feature (Android)

12. Unintentionalmisuseofmobileplatform
Backup feature (iOS)

13. MisuseofAndroidIntent
Misuse of Android Intent Permission

14. MisuseofAndroidIntent
Misuse of Android Intent Permission
Source: Sieve PWN-https://github.com/tanprathan/sievePWN

15. Mitigation Measures
o Understand the additional risks mobile apps introduce into existing architectures.
o Following rules and guidelines created by platform.
o Following common best practices when developing your API is also a key.
o Secure coding and configuration practices must be used on server-side of the mobile
application:
• OWASP Proactive Controls
• OWASP ASVS
• REST Security Cheat Sheet

16. 2 Insecure
Data Storage

17. Vulnerabilities that leak sensitive information
or personal information through insecure data
storage and unintended data leakage that
provide access to hackers.

18. Insecuredatastorage
Unencrypted Data Storage on Database

19. Insecuredatastorage
Insecure Data Storage lead to Client-side based authentication flaw

20. Unintendeddataleakage
Side-Channel Data Leakage through Android Clipboard and iOS generalPasteboard

21. Unintendeddataleakage
Side-Channel Data Leakage through System Log

22. Mitigation Measures
o Do not store/cache any kind of credentials on the storage device.
o Secure storage (e.g. Keychain) should be used to store sensitive data and information by
leveraging the required API.
o If application need to store database file containing sensitive information, the database
should be encrypted (SQLCipher).
o Disable the auto-correct feature for any sensitive information, not just for password fields.
o Eliminate the option to copy can help avoid data exposure.
o Debug logs should be removed on production environment.
o Remove sensitive data from views when backgrounded.
o Mask sensitive data that will be exposed through the UI.

23. 3 Insecure
Communication

24. Insecure communication refers to
communications being sent in cleartext as well
as other insecure methods.

25. Lackofencryptionfortransmitteddata
Unencrypted communication protocol

26. Weakhandshakenegotiation(Ciphersuite)
Use of Insecure and Deprecated Encryption algorithms

27. Lackofcertificateinspection
Improper certificate validation

28. Mitigation Measures
o Apply TLS to transport channels that the mobile app will use to transmit sensitive
information, session tokens, or other sensitive data to a backend API or web service.
o Use strong, industry standard cipher suites with appropriate key lengths.
o Never allow self-signed certificates, and consider certificate pinning for security conscious
applications.
o If possible, apply a separate layer of encryption to any sensitive data before it is given to the
SSL channel (End-to-end encryption).

29. 4 Insecure
Authentication

30. Mobile apps need to securely identify a user
and maintain that user’s identity, especially
when users are calling and sending sensitive
data such as financial information.

31. Localauthentication
Improper Biometric authentication (Fingerprint)

32. Localauthentication
Bypassing passcode authentication

33. Weaknessesinsessionmanagement
Improper Session Termination

34. Usingdeviceidentifier(UDID,IP,MACaddress,IMEI)to
identifyauserorasession
Exposing Device Specific Identifiers in Attacker Visible Elements

35. Step-upAuthentication
Manipulating web service response

36. Mitigation Measures
o Where possible, ensure that all authentication requests are performed server-side.
o When using Touch ID for authentication, store the app’s secret in the Keychain with an ACL
assigned to that item.
o Do not use any spoof-able values for authenticating a user. This includes device identifiers
or geo-location.
o 2FA or Step-up authentication should be enforced.
o Session Timeout and Session termination should be properly implemented.
o Secure guidelines should be used on server-side of the mobile application:
• OWASP Authentication Cheat Sheet
• OWASP Session Management Cheat Sheet

37. 5 Insufficient
Cryptography

38. The process behind encryption and decryption
may allow a hacker to decrypt sensitive data.
The algorithm behind encryption and
decryption may be weak in nature.

39. PoorKeyManagementProcesses
Use of hard-coded cryptographic key

40. CreationandUseofCustomEncryptionProtocols
Use of custom encryption

41. UseofInsecureand/orDeprecatedAlgorithms
Application uses deprecated cryptographic protocols or algorithms

42. Mitigation Measures
o Avoid the use of hardcoded keys within your binary.
o Avoid custom cryptographic algorithms development.
o Always use modern algorithms that are accepted as strong by the security community or
standard.
o Secure guidelines should be used on server-side of the mobile application:
• OWASP Cryptographic Storage Cheat Sheet
• OWASP Password Storage Cheat Sheet

43. 6 Insecure
Authorization

44. Insecure authorization refers to the failure of a
server to properly enforce identity and
permissions as stated by the mobile app

45. InsecureDirectObjectReference(IDOR)vulnerabilities
IDOR Vulnerabilities

46. BusinessLogicflaws
Parameter Tampering

47. Mitigation Measures
o Verify the roles and permissions of the authenticated user using only information contained
in backend systems.
o Avoid relying on any roles or permission information that comes from the mobile device
itself.
o Backend code should independently verify that any incoming identifiers associated with a
request (operands of a requested operation) that come along with the identify match up and
belong to the incoming identity.
o Secure guidelines should be used on server-side of the mobile application:
• OWASP Transaction Authorization Cheat Sheet
• OWASP Access Control Cheat Sheet

48. 7 Poor
Code Quality

49. Risks that come from vulnerabilities like buffer
overflows, format-string vulnerabilities, and
various other code-level mistakes where the
solution is to rewrite some code that's running
on the mobile device.

50. CrossSiteScripting
XSS via start ContentActivity using 'html' parameter (https://hackerone.com/reports/189793)

51. InsecureProtocolHandling
Insecure URI Scheme Handling

52. Mitigation Measures
o In unmanaged code, memory is allocated, freed and used securely.
o Error handling logic in security controls denies access by default.
o All inputs from external sources and the user should be validated and if necessary sanitized.
This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and
network sources.
o All third party components used by the mobile app, such as libraries and frameworks, are
identified, and checked for known vulnerabilities.

53. 8 Code
Tampering

54. When attackers can either directly modify the
code, change the contents of memory
dynamically, change or replace the system APIs
that the application uses, or modify the
application's data and resources.

55. BinaryPatching
Bypassing root/jailbreak detection

56. RuntimeManipulation
Bypassing root detection
Source: Mobile Application Hacking Diary Ep.2

57. RuntimeManipulation
Manipulating on End-to-end encryption
Source: Mobile Application Hacking Diary Ep.2

58. RuntimeManipulation
Pokemon Go Joystick

59. Mitigation Measures
o Various technique can be implemented to defend against runtime analysis and
manipulation:
• Implementing root/jailbreak/emulator/simulator detection controls
• Implementing Anti-debugging and Anti-tampering techniques
• Code Integrity Checking

60. 9 Reverse
Engineering

61. Reverse engineering refers to the analysis of a
final binary to determine its source code,
libraries, algorithms, and more.

62. ImproperCodeObfuscation
Analyze minified application

63. Mitigation Measures
o Consider code obfuscation in order to make apps difficult and annoying to analyze:
• Splitting up code and data between Java bytecode and native code
• Encrypting strings
• Encrypting parts of the code and data within the program
• Encrypting whole binary files and class files
o OWASP Technical Risks of Reverse Engineering and Unauthorized Code Modification

64. 10 Extraneous
Functionality

65. Developers frequently include hidden backdoors
or security controls they do not plan on
releasing into production.
This error creates risk when a feature is
released to the wild that was never
intended to be shared.

66. DebugEnabledForApponProduction
Debuggable Flag is set to true

67. HiddenandExtraneousFunctionalities
Login Log Endpoint Exposed

68. Mitigation Measures
o Manual source code review should be performed by conducting:
• Examine the app's configuration settings to discover any hidden switches;
• Verify that all test code is not included in the final production build of the app;
• Examine all API endpoints accessed by the mobile app to verify that these endpoints are
well documented and publicly available;
• Examine all log statements to ensure nothing overly descriptive about the backend is
being written to the logs;

69. What-a-Terrible-FailureMobileBankingApplication
Boonpoj T. Krit S. Prathan P. Parameth E.

70. WaTF-BankxOWASPMobileTop10Risks
o Java, Objective-C and Python (Flask framework) as a backend server.
o Simulate a "real-world" web services-enabled mobile banking application.
o Over 30 vulnerabilities mapped with OWASP Mobile Top 10 risks
https://github.com/WaTF-Team/WaTF-Bank

71. WaTF-BankxOWASPMobileTop10Risks
OWASP Mobile Top 10 2016 Vulnerability Name
M1. Improper Platform Usage
• Excessive App Permissions
• Unsupported version of OS Installation Allowed
• Unrestricted Backup File
• Android Content provider Flaw
• Android Broadcast receiver Flaw
• Input Validation on API (SQL Injection, Negative value)
• Information Exposure through API Response Message
• Control of Interaction Frequency on API
M2. Insecure Data Storage
• Insecure Application Local Storage
• Insecure Keychain Usage
• Unencrypted Database File
• Sensitive Information on Application Backgrounding
• Information Disclosure Through Device Logs
• Copy/Paste Buffer Caching
• Keyboard Input Caching
• Lack of Sensitive Information Masking
M3. Insecure Communication • Insecure SSL Verification
M4. Insecure Authentication
• Client-Side Based Authentication Flaw
• Account Enumeration
• Account Lockout Policy
• Weak Password Policy for Password/PIN
• Misuse of Biometric Authentication
• Session Management Flaw
M5. Insufficient Cryptography
• Hardcoded Encryption Key
• Weak Cryptographic Algorithm
• Custom Encryption Protocol
M6. Insecure Authorization • Insecure Direct Object Reference • Business Logic Flaw
M7. Client Code Quality • SQL Injection on Content provider • Insecure URL Scheme Handler
M8. Code Tampering
• Unauthorized Code Modification (Application Patching)
• Weak Root/Jailbreak Detection
• Method Swizzling
M9. Reverse Engineering • Lack of Code Obfuscation
M10. Extraneous Functionality • Application Debuggable • Hidden Endpoint Exposure

72. • https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
• https://www.slideshare.net/nowsecure/owasp-mobile-top-10-68706528
• https://www.exploit-db.com/papers/44145/
• https://github.com/OWASP/owasp-mstg
• https://github.com/OWASP/owasp-masvs
• https://github.com/WaTF-Team/WaTF-Bank
References