Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

Top 10 mobile controls and design principles

1. Identify and protect sensitive data on the mobile device

Risks: Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

• • In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
  • Store sensitive data on the server instead of client-end device, if possible.
  • Leverage the encryption and key-store mechanism provided by the mobile OS/hardware (e.g. SIM card) to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
  • Do not store/cache sensitive data on removable media unless they are tamper-proof and password protected.
  • Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory) //define protected
  • Automatically delete data which is no longer required from device
  • Be aware of caches and temporary storage as a possible leakage channel
  • Be aware of shared data storage (e.g. address book, media gallery) as a possible leakage channel.
  • Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
  • Schedule deletion according to time, rather than on a push-pop basis (to prevent e.g. data remaining in caches indefinitely)
  • Use secure deletion procedures e.g. conforming to NIST 800-88 .
  • Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
  • Carry out a specific check of all communication with web-server backends and other interfaces with trust boundaries - (e.g. is location or other information transferred within file metadata)
  • Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
  • Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
  • Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
  • Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
  • Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
  • For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //todo research mor and hook to best practice.

2. Handle password credentials securely on the device

Risks: Spyware, Surveillance, Financial malware, UI impersonation User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

• • Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
  • In case passwords need to be stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
  • Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
  • Password credentials should be marked to avoid being copied to backups
  • Access to highly sensitive data (e.g. access to wallet) should be protected by a PIN.
  • Consider using visual/pattern based passwords to aid usability.
  • Ensure passwords and keys are not visible in cache or logs
  • We recommend that one-time codes or any kind of password (OTP) should not be forwarded via SMS where (as on most smartphones) an alternative, more secure channel is available. Consider using HTTPS with client authentication (see 3.) to prevent Zeus-in-the-mobile style attacks.

3. Ensure sensitive data is protected in transit

Risks: Network spoofing attacks, Surveillance Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

• • Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
  • Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
  • For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain.
  • Do not disable or ignore the SSL chain validation.
  • SMS, MMS or notifications should not be used to send sensitive data to mobile end points.
  • For one-time-password values, rather than SMS, consider using https with client authentication (i.e. OTP is sent to smartphone over https and smartphone is authenticated to prevent interception).
  • Consider use of GSM encryption-on flags to verify that GSM encryption is on.
  • Provide appropriate trust cues for linking to unknown third party applications.
  • Do not train users to follow untrusted paths (e.g. accept invalid certificates).
  • Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

Reference: Google vulnerability of Client Login account credentials on unprotected wifi [1]

4. Keep the back-end API and mobile platform secure //Downgrade this control Risks: Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

• • Web Services/ SOAP/ REST , security best practices (placeholder)
  • Input validation
  • Do not use a generic shared secret for integration to backend (like embedded password in code)
  • Use authentication that ties back to the end user identity (rather than the device identity)
  • Ensure authorization controls are done correctly in the backend APIs.
  • Ensure that the backend platform is running on a hardened configuration with latest security patches
  • Employ rate limiting and throttling, test for DDoS vulnerabilities

5. Implement user authentication/authorization and session management correctly Risks:

• • Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.
  • User authentication must be based on user's credentials. //??
  • Use unpredictable session identifier with high entropy
  • Do not use device id (UDID or IMEI) as a session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data.
  • Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains). //This sentence not clear
  • Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
  • Warn user and obtain consent for any cost implications for app behaviour. // and other consent best practices.

Reference: Google's ClientLogin implementation [2]

6. Ensure strong vulnerability and patch management in place //Downgrade and mix with #4

• • All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
  • Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
  • Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
  • Understand and test your patching process and its the interaction with the app-store - what is a typical time-frame are any updates possible (e.g. config files) without the approval of the app-store?
  • Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

7. Perform data integration with third party backend applications correctly Risks: Unintended disclosure

• • User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
  • No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. Link to 1. audit communication mechanisms to check for unintended leaks (e.g. image metadata). // ditto
  • Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
  • Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

8. Run the mobile client using minimal permission Risks: Data leakage, Surveillance, Spyware, Diallerware

• • Run with the minimum privilege required for the application on the operating system.
  • Don't authorize code/app to execute with root/sa privilege
  • Always perform testing as a standard user along with the privileged user
  • Least privilege. Be aware of privileges granted by default by API's and disable them.
  • Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.

9. Enforce higher security posture on the device for sensitive apps //Reword May need to go in a separate enterprise security management point

• • If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Still needs to be clarified
  • Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive applications
  • Banking Apps

//(Remote Management, PIN enforcement, encryption, application monitoring)

• • Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it...

10. Carefully check any runtime interpretation of code for errors Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls. Risks: Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware //Please check and add advice here.

• • Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data.
  • Run interpreters at minimal privilege levels
  • Fuzz test interpreters
  • Define comprehensive and complete escape syntax (not sure if this is theortically possible).
  • Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook... (Angry bird attack)

11. Employ the secure coding/development practices // Let's try to get rid of it and move the recommendation //Risk? Isn't this circular? I don't understand the principle here.

• • Input Validation and Output Encoding
  • Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)

• • Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration. (Vinay will expand it)
  • Leverage static and binary code analyzers to find security flaws.
  • Use safe string function, avoid buffer and Integer overflow //Is this mobile specific? (generic but important)
  • Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) - //Enterprise Apps (type of wifi, vpn, trused)
  • For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
  • Remove all test code before releasing the application
  • Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files -

//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps) //Vinay to add

Candidates (to be merged if needed)

11. No secrets in code/binary

Risk: Mobile application binaries can be easily reverse engineered.

• • Do not store any passwords or secrets in the application binary

12. Protect your application from other malicious applications on the device

Risk: User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

• • (?? What guidelines could be provided to developers)
  • User education on using due diligence while installing third party applications on mobile devices

Original list (kept for review)

1. Protect data at rest
2. Protect data in transport
3. Multi-factor authentication
4. Session management
5. Least privilege access control
6. Untrusted data validation
7. Output encoding
8. Enterprise device management
9. Keep business logic on the server
10. Platform security