Mobile security development guide: An antidote to OWASP Mobile security requirements

Other popular blogs

• • Identifying app ideas and business cases for organization
  • A Primer: Mobile app development technologies and platforms
  • Data driven selection of mobile development platform selection
  • What should Mobility Road map Cover?

OWASP (Open Web Application Security Project) Foundation is an community focused in security testing standards. OWASP Mobile specification is focused on mobile testing standards. Though OWASP is focused on testing, Developer's need not be aware of these test cases and their respective development aspects. This article provides basic tips to each security requirement in OWASP Mobile checklist. 

V1	Architecture, design and threat modelling
	Security Requirement	Development tips
1.1	Verify all application components are identified and are known to be needed.	Remove stale and dead code and dependent libraries.
1.2	Verify all third party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities.	Keep track of vulnerabilities through out development and Maintenance phase. Subscribe to feeds of all the third party components, frameworks and libraries being used in project. Google Play Publishing Portal and iTunes Portal provide security alerts for upgrading popular frameworks.
1.3	Verify that security controls are never enforced only on the client side, but on the respective remote endpoints.	Session handling, XSS protection need to be done on server end points. However client side security controls like encryption, SSL pinning etc should be on server
1.4	Verify that a high-level architecture for the mobile app and all connected remote services has been defined and security has been addressed in that architecture.	All components in the architecture should be vetted out from security standpoint. If App requires multiple end points, aggregate them into a single API layer and have all security aspects in place.
1.5	Verify that data considered sensitive in the context of the mobile app is clearly identified.	Identify sensitive information and this information should not be stored in mobile stored in device storage or database. This exercise should be part of data design. Example 1: Store JWT(JSON Web Tokens) instead of login id and password. Example 2: Never log or store credit card numbers in device.
1.6	Verify all app components are defined in terms of the business functions and/or security functions they provide.	This checklist is best suited for all security requirements
1.7	Verify that a threat model for the mobile app and the associated remote services, which identifies potential threats and countermeasures, has been produced.	Again, This checklist is best suited for all security requirements, have all relevant counter measures in place
1.8	Verify all third party components have been assessed (associated risks) before being used or implemented. Additionally verify that a process is in place to ensure that each time a security update for a third party component is published, the change is inspected and the risk evaluated.	Keep track of vulnerabilities through out development and Maintenance phase. Subscribe to feeds of all the third party components, frameworks and libraries being used in project. Google Play Publishing Portal and iTunes Portal provide security alerts for upgrading popular frameworks.
1.9	Verify that all security controls have a centralized implementation.	Treat security as a feature in the App and not as an add on.
1.10	Verify that all components that are not part of the application but that the application relies on to operate, are clearly identified and the security implications of using those components are known.	Always use popular and standard components . Consider commercial security products as they are well tested and provide constant support. If open source code snippets are being used from sources like Git Hub. Go through the source code before using in your project. Search Stack Overflow for popularity of a component.
1.11	Verify that there is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57.	Use ready frameworks like Bouncy Castle, Open SSL, GNU Crypto, Kony EMM encryption, AWS s2n.
1.12	Verify that remote endoints ensure that connecting clients use the current version of the mobile app.	API Versioning and tracking Deprecation of API which are not in use Develop versioning system within the solution to alert the user to upgrade the app for further usage
1.13	Verify that security testing is performed as part of the development lifecycle. If some or all of the testing is automated, the configuration of the testing tools must be tailored to the specific app.	Applicable to tester. Developer has no say in this security requirement.
V2	Data Storage and Privacy
2.1	Verify that system credential storage facilities are used appropriately to store sensitive data, such as user credentials or cryptographic keys.	Identify sensitive information and this information should not be stored in mobile stored in device storage or database. This exercise should be part of data design. Example 1: Store JWT(JSON Web Tokens) instead of login id and password.
2.2	Verify that no sensitive data is written to application logs.	Never log or store credit card numbers in device. Logs should be switched off before going to production. If logging is required for prodcution support, Make sure appropriate log level(example: FATAL, ERROR etc) is set before going live. Too much logging can slow down app.
2.3	Verify that no sensitive data is shared with third parties unless it is a necessary part of the architecture.	Data architecture should take care of this security requirement. Sensitive data shared should be in encrypted format in the third party database.
2.4	Verify that the keyboard cache is disabled on text inputs that process sensitive data.	Disable keyboard cache for sensitive data entry like passwords and credit card. Ex: For android andorid:inputType="password" disables keyboard cache.
2.5	Verify that the clipboard is deactivated on text fields that may contain sensitive data.	Disable Copy, Paste, Select All etc. Disable screen capture. Users can still take a photograph from another mobile phone. There is no fix for this security requirement
2.6	Verify that no sensitive data is exposed via IPC mechanisms.	Data architecture must take care of this security requirement. Sensitive data must be shared in encrypted format and should be stored in encrypted format in the third party database.
2.7	Verify that no sensitive data, such as passwords and credit card numbers, is exposed through the user interface or leaks to screenshots.	Never show sensitive information on UI. Ex: Last four digits of credit card must be shown, instead of complete number.
2.8	Verify that no sensitive data is included in backups.	Identify sensitive information and this information should not be stored in mobile stored in device storage or database. This exercise should be part of data design. *Example 1: Store JWT(JSON Web Tokens) instead of login id and password. Server back up of sensitive information should be encrypted Make all stake holders aware of the extreme sensitivity of data.
2.9	Verify that the app removes sensitive data from views when backgrounded.	Transition the screens with sensitive information to a home, login or custom screen when app goes to background after 5 minutes. This transition should happen after 5 minutes as user might deliberately leave the app to attend phone call, look for OTP in messaging app, search for information etc.
2.10	Verify that the app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.	Clear sensitive data from in-device database and other cache when user leaves the app or app is in background for few minutes.
2.11	Verify that the app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.	Make sure app has its own authentication mechanism in place. Checking for lock screen, finger print authentication is secondary and intrusive.
2.12	Verify that the app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app.	Clearly define personal information is being used in Opt-in, Legal, Privacy Policy,Terms and Conditions. In app security alerts and regular mailers to users to educate on security.
V3	Cryptography
3.1	Verify that the app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.	Always get cryptographic keys from server
3.2	Verify that the app uses proven implementations of cryptographic primitives.	Use ready frameworks like Bouncy Castle, Open SSL, GNU Crypto, Kony EMM encryption, AWS s2n.
3.3	Verify that the app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices.	Use ready frameworks like Bouncy Castle, Open SSL, GNU Crypto, Kony EMM encryption, AWS s2n.
3.4	Verify that the app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes.	Always use latest versions of security frameworks. Keep a tab on the upgrades and upgrade regularly. Security frameworks upgrade rapidly as new vulnerabilities are discovered.
3.5	Verify that the app doesn't re-use the same cryptographic key for multiple purposes.	Keep changing the crptographic key at regular intervels. Server should be able to change and push cryptographic key at regular intervels
3.6	Verify that all random values are generated using a sufficiently secure random number generator.	Use SecureRandom in Java API and RNGCryptoServiceProvider in C# API. All random numbers should be generated in server rather than mobile device.
V4	Authentication and Session Management
4.1	Verify that if the app provides users with access to a remote service, an acceptable form of authentication such as username/password authentication is performed at the remote endpoint.	Authentication and authorization must be done at server side and not at client side.
4.2	Verify that the remote endpoint uses randomly generated access tokens to authenticate client requests without sending the user's credentials.	Use JWT(JSON Web Tokens) with expiry date. Store JWT in encrypted format in mobile phone DB. Do not store in shared preferences and text files.
4.3	Verify that the remote endpoint terminates the existing session when the user logs out.	JWT(JSON Web Tokens) should be expired on log out
4.4	Verify that a password policy exists and is enforced at the remote endpoint.	Password should not be stored in mobile storage or database. This exersize should be part of data design. Store JWT(JSON Web Tokens) instead of login id and password. Never log or store password in device. Server database must store password in encrypted format
4.5	Verify that the remote endpoint implements an exponential back-off, or temporarily locks the user account, when incorrect authentication credentials are submitted an excessive number of times.	Block user after pre-specified number of incorrect authentication attempts. Use (OTP) to registered mobile number to unlock the password.
4.6	Verify that 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.	Use bio-metric authentication along with key chains. iOS Example: Use Keychain C API along with Touch ID API.
4.7	Verify that sessions are terminated at the remote endpoint after a predefined period of inactivity.	Sessions and JWT tokens should have expiry time. This needs to be done on server side.
4.8	Verify that a second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced.	For sensitive apps like banking, wallets and trading use 2FA(Two Factor Authentication) Popular 2FA's are OTP(One Time Password), hardware token You can also simply ask for date of birth, school name, mothers maiden name etc
4.9	Verify that step-up authentication is required to enable actions that deal with sensitive data or transactions.	For sensitive apps like banking, wallets and trading use 2FA(Two Factor Authentication) Popular 2FA's are OTP(One Time Password), hardware token You can also simply ask for date of birth, school name, mothers maiden name etc
4.10	Verify that the app informs the user of all login activities with his or her account. Users are able view a list of devices used to access the account, and to block specific devices.	This can be part of Behavioral Security Strategy Track devices accessing the App and block or issue 2FA(Two Factor Authentication) challenge
V5	Network Communication
5.1	Verify that data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.	All REST and SOAP should use HTTPS For enhanced security use SOAP security certificates
5.2	Verify that the TLS settings are in line with current best practices, as far as they are supported by the mobile operating system.	Check the sanity of SLL certificate using online SSL Certificate Checker tools Android does not allow SSL commmunication if the certificate chain is not properly formed
5.3	Verify that the app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a valid CA are accepted.	Choose certificates based on your needs, SSL certificates vary from few 100 $ to few 1000 $. Check the sanity of SLL certificate using online SSL Certificate Checker tools
5.4	Verify that 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.	Implement SSL pinning to counter MITM(Man In The Middle) attack. SSL certificate must be packed in the app rather than dynamic download from the server. App will reject any other trusted or untrusted HTTPS source by "Man In The Middle"
5.5	Verify that the app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.	Not sure what this security requirement means. Registered email ID and OTP is a norm and used as 2FA. Security can be enhanced by expiring these passwords in 5 minutes Remember mails and SMS are stored by email and SMS providers for 1 to 3 months depending on security complaince rules of various countries. Expiring SMS and email passwords are a must for high security requirements.
V6	Environmental Interaction
6.1	Verify that the app only requires the minimum set of permissions necessary.	App must provide Opt-In for features used in app. Ex: Access to Phone Book permission must be used only when app uses this access. This bug is due to copy paste from earlier project. Developers forget to delete the permissions which were used by earlier project. Always use fresh manifest file. Instead of copying from earlier project If a feature is removed, remove respective permisions along with source code.
6.2	Verify that all inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.	All validations must be in place Though all XSS validations should be done on server. Care should be taken to validate data on mobile side.
6.3	Verify that the app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected.	Custom URLs like mailto, tel, sms, intent filters should be used properly with all permissions and data security in place
6.4	Verify that the app does not export sensitive functionality through IPC facilities, unless these mechanisms are properly protected.	Deep linking for SEO should be done carefully. If protected screen is invoked from web site screen should transition to login screen If an app A invokes screen from app B. Permissions need to properly configured in App B from data security perspective.
6.5	Verify that JavaScript is disabled in WebViews unless explicitly required.	JavaScript must be disabled from WebViews if they are not necessary. Cant do this for hybrid apps cause without JS hybrid apps will not work.
6.6	Verify that WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only https). Potentially dangerous handlers, such as file, tel and app-id, are disabled.	Disable handlers such as file, tel and app-id when not required. Especially in case of user generated content. White URL in the app Clear WebView history Disable debugging in WebView for final GoLive Disable cache in WebView
6.7	Verify that the app does not load user-supplied local resources into WebViews.	Disable access to local file system from WebView
6.8	Verify that if Java/Swift/Obj C objects are exposed in a WebView, verify that the WebView only renders JavaScript contained within the app package.	This access is not applicable for hybrid apps
6.9	Verify that object serialization, if any, is implemented using safe serialization APIs.	Stock serialization implementation is not safe. Encrypted serialization must be done for object serialization and de-serialization
6.10	Verify that the app detects whether it is being executed on a rooted or jailbroken device. Depending on the business requirement, users are warned, or the app is terminated if the device is rooted or jailbroken.	In data sensitive apps like banking and trading, Jail broken devices should be detected and app should not be allowed to run. Jail Broken devices throw open their file systems and can be hacked easily
V7	Code Quality and Build Settings
7.1	Verify that the app is signed and provisioned with valid certificate.	Android: Signed APK should be built for Go Live. iOS: Valid certificates should be generated using Apple Developer Account
7.2	Verify that the app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable).	Android: Signed APK should be built for Go Live. iOS: Valid certificates should be generated using Apple Developer Account debugging should be switched off
7.3	Verify that debugging symbols have been removed from native binaries.	All debugging, beta-testing code like crashlytics and debugging code should be removed.
7.4	Verify that debugging code has been removed, and the app does not log verbose errors or debugging messages.	log levels should be set properly
7.5	Verify that the app catches and handles possible exceptions.	Unhandled exceptions can reveal sensitive data. Code review must be done to remove all exceptions.
7.6	Verify that error handling logic in security controls denies access by default.	Like Exceptions, Errors can reveal sensitive data. Code review must be done to remove all exceptions.
7.7	Verify that in unmanaged code, memory is allocated, freed and used securely.	Code review, static and dynamic analysis should be done by developers and technical leads to check memory management.
7.8	Verify that security features offered by the compiler, such as stack protection, PIE support and automatic reference counting, are activated.	Code review, static and dynamic analysis should be done by developers and technical leads to check memory management.
7.9	Verify that Java bytecode has been minified.	Use ProGaurd and Grunt tools for obfuscation, minification and uglyfication. This is applicable for hybrid apps also.
V8	Resiliency Against Reverse Engineering Requirements
	App Isolation
8.1	Verify that the app provides a custom keyboard whenever sensitive data is entered.	Custom keyboards are not popular in mobile apps. You may use it. Seems to be direct lift from Web apps. Use input type as password. Disable keyboard cache.
8.2	Verify that custom UI components are used to display sensitive data. The UI components should not rely on immutable data structures.	Use immutable data structures and collections. This is advanced security and can be caught in code review.
	Impede Dynamic Analysis and Tampering
8.3	Verify that the app implements two or more functionally independent methods of root detection and responds to the presence of a rooted device either by alerting the user or terminating the app.	In data sensitive apps like banking and trading, Jail broken devices should be detected and app should not be allowed to run. Jail Broken devices throw open their file systems and can be hacked easily
8.4	Verify that the app implements multiple functionally independent debugging defenses that, in context of the overall protection scheme, force adversaries to invest significant manual effort to enable debugging. All available debugging protocols must be covered (e.g. JDWP and native).	Disable debugging All debugging, beta-testing code like crashlytics and debugging code should be removed. log levels should be set properly Unhandled exceptions can reveal sensitive data. Code review must be done to remove all exceptions. Like Exceptions, Errors can reveal sensitive data. Code review must be done to remove all exceptions. Code review, static and dynamic analysis should be done by developers and technical leads to check memory management.
8.5	Verify that the app detects, and responds to, tampering with executable files and critical data.	Use ProGaurd and Grunt tools for obfuscation, minification and uglyfication. This is applicable for hybrid apps also. Jailbroken and rooted devices are susceptible for tampering
8.6	Verify that the app detects the presence of widely used reverse engineering tools, such as code injection tools, hooking frameworks and debugging servers.	Use ProGaurd and Grunt tools for obfuscation, minification and uglyfication. This is applicable for hybrid apps also. Jailbroken and rooted devices are susceptible for tampering
8.7	Verify that the app detects, and response to, being run in an emulator using any method.	Jailbroken and rooted device device detection takes care of this security requirement
8.8	Verify that the app detects, and responds to, modifications of process memory, including relocation table patches and injected code.	Use ProGaurd and Grunt tools for obfuscation, minification and uglyfication. This is applicable for hybrid apps also. Jailbroken and rooted devices are susceptible for tampering
8.9	Verify that the app implements multiple different responses to tampering, debugging and emulation (requirements 9.2 - 9.6), including stealthy responses that don't simply terminate the app.	Use ProGaurd and Grunt tools for obfuscation, minification and uglyfication. This is applicable for hybrid apps also. Jailbroken and rooted devices are susceptible for tampering
8.10	Verify all executable files and libraries belonging to the app are either encrypted on the file level and/or important code and data segments inside the executables are encrypted or packed. Trivial static analysis should not reveal important code or data.	Use ProGaurd and Grunt tools for obfuscation, minification and uglyfication. This is applicable for hybrid apps also. Jailbroken and rooted devices are susceptible for tampering
8.11	Verify that obfuscating transformations and functional defenses are interdependent and well-integrated throughout the app.	Use ProGaurd and Grunt tools for obfuscation, minification and uglyfication. This is applicable for hybrid apps also. Jailbroken and rooted devices are susceptible for tampering
	Device Binding
8.12	Verify that the app implements a 'device binding' functionality when a mobile device is treated as being trusted. Verify that the device fingerprint is derived from multiple device properties.	This can be part of Behavioral Security Strategy Create device meta data and analyse app usage to find user behavior. This usage analysis needs to be done for first 5 to 10 times user is using the App. Create a master data of devices from which user is accessing the app Track devices accessing the App and block or issue 2FA(Two Factor Authentication) challenge when behaviour changes Use comercial library called Behaviosec for secure implementation.
	Impede Comprehension
8.13	Verify that the app uses multiple functionally independent means of emulator detection that, in context of the overall protection scheme, force adversaries to invest significant manual effort to run the app in an emulator (supersedes requirement 9.5).	Jail Broken device detection does emulator detection also.
8.14	Verify that if the architecture requires sensitive information be stored on the device, the app only runs on operating system versions and devices that offer hardware-backed key storage. Alternatively, the information is protected using obfuscation. Considering current published research, the obfuscation type and parameters are sufficient to cause significant manual effort to reverse engineers seeking to comprehend or extract the sensitive data.	Addressed in above sections
8.15	Verify that if the architecture requires sensitive computations be performed on the client-side, these computations are isolated from the operating system by using a hardware-based SE or TEE. Alternatively, the information is protected using obfuscation. Considering current published research, the obfuscation type and parameters are sufficient to cause significant manual effort to reverse engineers seeking to comprehend the sensitive portions of the code and/or data.	Addressed in above sections