OWASP Mobile Top 10 Secure Coding Challenges

[hamza]

Please find below a list of secure coding challenges for OWASP Mobile Top 10. The goal in each challenge is to fix the security vulnerability in the app. These are mix of free and Pro challenges. The challenges are for Android and iOS.

To get started with SecDim’s challenges, first complete the Start Here challenge:
Start Here.android Or Start Here.ios

M1: Improper Credential Usage

1. StartHere.android: Hardcoding secrets such as API keys, encryption keys, or sensitive credentials in mobile apps is a critical security risk because attackers can decompile or reverse-engineer the app to extract these secrets, even if obfuscated. This exposure can lead to unauthorised access to backend services, data breaches, and compromise of the app’s integrity. Mobile apps operate in untrusted environments where users have full control over the device, making it unsafe to embed sensitive information.
2. StartHere.ios: Hardcoding secrets such as API keys, encryption keys, or sensitive credentials in mobile apps is a critical security risk because attackers can decompile or reverse-engineer the app to extract these secrets, even if obfuscated. This exposure can lead to unauthorised access to backend services, data breaches, and compromise of the app’s integrity. Mobile apps operate in untrusted environments where users have full control over the device, making it unsafe to embed sensitive information.

M3: Insecure Authentication/Authorization

1. Biometric.android: Android’s biometric authentication provides a secure way for users to authenticate using their fingerprint, facial recognition, or iris scan. It leverages the Android Biometric API, which allows developers to integrate biometric authentication into their apps for enhanced security. A key aspect of secure biometric implementation is the use of a crypto object, which binds the biometric data to cryptographic operations, ensuring the authentication process is tied to secure transactions or sensitive data. Without a crypto object, the biometric authentication is merely a gateway for user verification and is not securely linked to any cryptographic functions. This challenge explores a fix for this weakness in biometric implementation in Android.
2. Biometric.ios: Biometric authentication in iOS apps, such as Face ID or Touch ID, allows users to securely access app features or data using their unique biological traits. However, it must be securely configured to ensure its effectiveness and protect sensitive user information. Misconfigurations or improper handling of biometric data can expose apps to vulnerabilities, such as replay attacks or unauthorised access through fallback mechanisms. In this challenge we will learn how to address insecure biometric configuration in iOS.

M4: Insufficient Input/Output Validation

1. Intent.android: Android Intent is a messaging object used to request an action from another app component, facilitating tasks such as launching activities, services, or broadcasting messages. Intents can carry data between components, enabling communication within and across applications. From a security standpoint, it’s crucial to validate the data passed through Intents to prevent potential security vulnerabilities such as Intent spoofing or data injection attacks. This challenge examine insecure Intent usage and ways to remediate it.

M5: Insecure Communication

1. SSL.android: A strong SSL/TLS cipher in Android protects data during transmission by encrypting it in a way that is difficult for attackers to break. Weak or outdated ciphers can expose data to vulnerabilities, such as man-in-the-middle attacks or eavesdropping, compromising the confidentiality and integrity of sensitive information. This challenge explores a weak implementation of SSL/TLS and a way to fix it in Android.

M6: Inadequate Privacy Controls

1. GarbageCollector.android: In Android, static references to Activity or View classes can lead to significant memory leaks because static objects persist for the lifetime of the application. When an Activity or View is referenced statically, it prevents the garbage collector from reclaiming the memory, even after the activity or view is no longer in use. This results in memory that is unnecessarily retained, leading to a gradual depletion of available memory and potential application crashes due to OutOfMemoryErrors. This challenge examines memory leaks in static references and ways to address it.
2. PII.android: Keyboard caching improves user convenience, but it poses a significant security risk when handling personally identifiable information (PII) such as passwords, credit card numbers, or sensitive personal details. If PII is cached, it could be easily retrieved by unauthorised users or apps, leading to data breaches or identity theft. This challenge explores a how to address disclose of sensitive data in Android.

M7: Inadequate Privacy Controls

1. BroadcastReciever.android: An Android BroadcastReceiver is a component that allows apps to listen for and respond to broadcast messages from the system or other applications. It’s commonly used to handle system-wide events like battery changes, network connectivity, or incoming calls. However, improper implementation of BroadcastReceivers can lead to memory leaks, particularly when they are registered in an activity and not unregistered when the activity is destroyed. This can cause the activity to be held in memory, leading to memory leaks and degraded app performance. This challenge examines memory leaks in BroadcastReceiver and ways to address it.
2. ProGuard.android: ProGuard is a tool in Android development that optimises, shrinks, and obfuscates code in an app. It makes reverse engineering more difficult by renaming classes, methods, and variables to obscure names, making it harder for attackers to understand the logic and structure of the app. This challenge explores a weak implementation of this feature and ways to address it.

M8: Inadequate Privacy Controls

1. Permission.android: Android permissions are a security mechanism that controls an app’s access to sensitive data and system features, such as the camera, location, or contacts. Users must grant these permissions for apps to function as intended. Excessive or unnecessary permissions increase the app’s attack surface, potentially exposing sensitive user data to misuse or malicious activities. This challenge explores a weakness in usage of permission and ways to address it.
2. Webview.ios: WebViews in iOS are components that allow apps to display web content within the app using a browser-like interface. They are often used to integrate online resources, display custom web pages, or create hybrid applications. However, enabling JavaScript in WebViews introduces security risks because it allows web content to execute scripts, which can potentially be exploited by attackers. If the WebView loads untrusted or compromised content, malicious JavaScript could execute within the WebView’s context, leading to cross-site scripting (XSS) attacks or unauthorised access to sensitive data. The risk is heightened when WebViews interact with native app functionality via JavaScript bridges, as attackers could exploit vulnerabilities to manipulate app behaviour or access protected resources. In this challenge we will learn how to address this vulnerability in an iOS app.

M9: Inadequate Privacy Controls

1. SharedPrefs.android: SharedPreferences in Android is a lightweight mechanism for storing key-value pairs of primitive data types such as booleans, floats, ints, longs, and strings. This storage method is ideal for persisting small amounts of data, such as user preferences or configuration settings, across user sessions. However, from a security perspective, SharedPreferences is not inherently secure as it stores data in plain text within the app’s file system. This challenge examines the insecure usage of SharedPreferences and ways to remediate it.
2. UserDefaults.ios: UserDefaults is a lightweight storage mechanism in iOS for saving small amounts of data, such as user preferences, app settings, and basic information, that needs to persist between app launches. It is part of Apple’s Foundation framework and provides a simple key-value storage model. However, UserDefaults is insecure because the data it stores is not encrypted by default, making it vulnerable to access and modification by malicious users or attackers with access to the device’s filesystem. As such, sensitive information like passwords, tokens, or private data should never be stored in UserDefaults; more secure alternatives like the Keychain should be used for such purposes.
3. Keychain.ios: The Keychain in iOS is a secure storage system designed for storing sensitive information like passwords, cryptographic keys, and authentication tokens. It utilises strong encryption and hardware-backed security to protect data, ensuring it remains isolated from other apps and unauthorised access. However, it should not be exportable or should be securely configured to prevent the stored data from being extracted or misused if the device is compromised. In this challenge we will learn how to address insecure keychain configuration in iOS.

M10: Inadequate Privacy Controls

1. Random.android: A random number generator (RNG) in Android is a system function that produces unpredictable numbers used in security-critical tasks like generating encryption keys, session tokens, and nonces. From a security standpoint, predictable random numbers can lead to vulnerabilities, allowing attackers to guess keys or tokens, compromising data integrity and security. A secure RNG ensures that cryptographic operations remain robust and resistant to attacks by generating truly random and unpredictable values. In this challenge we will learn how to address insecure random number generator in Android.
2. Random.ios: A random number generator (RNG) is a system function that produces unpredictable numbers used in security-critical tasks like generating encryption keys, session tokens, and nonces. From a security standpoint, predictable random numbers can lead to vulnerabilities, allowing attackers to guess keys or tokens, compromising data integrity and security. A secure RNG ensures that cryptographic operations remain robust and resistant to attacks by generating truly random and unpredictable values. In this challenge we will learn how to address insecure random number generator in iOS.

We host many other challenges that are not part of OWASP Top 10 but appears in today’s modern apps. You can find these challenges by

1. browsing through vulnerabilities related to iOS and Android apps: Browse Challenges
2. Viewing the iOS game or Android game

Finally, you can win SecDim OWASP Mobile TOP 10 Secure Developer in Android Badge and SecDim OWASP Mobile TOP 10 Secure Developer in iOS Badge to show your proficiency in building secure apps aligned with OWASP Mobile TOP 10 recommendations.