This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Mobile Security Project"

From OWASP
Jump to: navigation, search
m (→‎Mobile Tools)
(→‎Secure Mobile Development)
Line 735: Line 735:
  
 
= Secure Mobile Development =
 
= Secure Mobile Development =
−
== Secure Mobile Development Guidelines Objective==
+
'''Secure Mobile Development Guidelines Objective'''
  
−
The OWASP Secure Development Guidelines will provide developers with the knowledge they need to build secure mobile applications. An extendable framework will be provided that includes the core security flaws found across nearly all mobile platforms. It will be a living reference where contributors can plug in newly exposed APIs for various platforms and provide good/bad code examples along with remediation guidance for those issues.
+
The OWASP Secure Development Guidelines provides developers with the knowledge they need to build secure mobile applications. An extendable framework will be provided that includes the core security flaws found across nearly all mobile platforms. It will be a living reference where contributors can plug in newly exposed APIs for various platforms and provide good/bad code examples along with remediation guidance for those issues.
  
 +
== Mobile Application Coding Guidelines ==
 +
The purpose of this section is to provide application developers guidelines on how to build secure mobile applications, given the differences in security threat between applications running on a typical desktop as compared to those running on a mobile device (such as tablets or cell phones).
 +
 +
Using the guidance provided here, developers should code their applications to mitigate these malicious attacks. While more general coding guidelines should still be followed as applicable, this page lists additional considerations and/or modifications to common guidelines and is written using the best knowledge available at this time.
 +
 +
=== Authentication and Password Management ===
 +
This is a set of controls used to verify the identity of a user, or other entity, interacting with the software, and also to ensure that applications handle the management of passwords in a secure fashion.
 +
<ol type="a">
 +
<li> Instances where the mobile application requires a user to create a password or PIN (say for offline access), the application should never use a PIN but enforce a password which follows a strong password policy.
 +
<li> Mobile devices may offer the possibility of using password patterns which are never to be utilized in place of passwords as sufficient entropy cannot be ensured and they are easily vulnerable to smudge-attacks.
 +
<li> Mobile devices may also offer the possibility of using biometric input to perform authentication which should never be used due to issues with false positives/negatives, among others.
 +
<li> Wipe/clear memory locations holding passwords directly after their hashes are calculated.
 +
<li> Based on risk assessment of the mobile application, consider utilizing two-factor authentication.
 +
<li> For device authentication, avoid solely using any device-provided identifier (like UID or MAC address) to identify the device, but rather leverage identifiers specific to the application as well as the device (which ideally would not be reversible). For instance, create an app-unique “device-factor” during the application install or registration (such as a hashed value which is based off of a combination of the length of the application package file itself, as well as the current date/time, the version of the OS which is in use, and a randomly generated number). In this manner the device could be identified (as no two devices should ever generate the same “device-factor” based on these inputs) without revealing anything sensitive. This app-unique device-factor can be used with user authentication to create a session or used as part of an encryption key.
 +
<li> In scenarios where offline access to data is needed, add an intentional X second delay to the password entry process after each unsuccessful entry attempt (2 is reasonable, also consider a value which doubles after each incorrect attempt).
 +
<li> In scenarios where offline access to data is needed, perform an account/application lockout and/or application data wipe after X number of invalid password attempts (10 for example).
 +
<li> When utilizing a hashing algorithm, use only a NIST approved standard such as SHA-2 or an algorithm/library.
 +
<li> Salt passwords on the server-side, whenever possible. The length of the salt should at least be equal to, if not bigger than the length of the message digest value that the hashing algorithm will generate.
 +
<li> Salts should be sufficiently random (usually requiring them to be stored) or may be generated by pulling constant and unique values off of the system (by using the MAC address of the host for example or a device-factor; see 3.1.2.g.). Highly randomized salts should be obtained via the use of a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). When generating seed values for salt generation on mobile devices, ensure the use of fairly unpredictable values (for example, by using the x,y,z magnetometer and/or temperature values) and store the salt within space available to the application.
 +
<li> Provide feedback to users on the strength of passwords during their creation.
 +
<li> Based on a risk evaluation, consider adding context information (such as IP location, etc…) during authentication processes in order to perform Login Anomaly Detection.
 +
<li> Instead of passwords, use industry standard authorization tokens (which expire as frequently as practicable) which can be securely stored on the device (as per the OAuth model) and which are time bounded to the specific service, as well as revocable (if possible server side).
 +
<li> Integrate a CAPTCHA solution whenever doing so would improve functionality/security without inconveniencing the user experience too greatly (such as during new user registrations, posting of user comments, online polls, “contact us” email submission pages, etc…).
 +
<li> Ensure that separate users utilize different salts.
 +
</ol>
 +
 +
=== Code Obfuscation ===
 +
This is a set of controls used to prevent reverse engineering of the code, increasing the skill level and the time required to attack the application.
 +
 +
<ol type="a">
 +
<li>Abstract sensitive software within static C libraries.
 +
<li> Obfuscate all sensitive application code where feasible by running an automated code obfuscation program using either 3rd party commercial software or open source solutions.
 +
<li> For applications containing sensitive data, implement anti-debugging techniques (e.g. prevent a debugger from attaching to the process; android:debuggable=”false”).
 +
<li> Ensure logging is disabled as logs may be interrogated other applications with readlogs permissions (e.g. on Android system logs are readable by any other application prior to being rebooted).
 +
<li> So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and above, Android 4.0 and above), Address Space Layout Randomization (ASLR) should be taken advantage of to hide executable code which could be used to remotely exploit the application and hinder the dumping of application’s memory.
 +
</ol>
 +
 +
=== Communication Security ===
 +
This is a set of controls to help ensure the software handles the sending and receiving of information in a secure manner.
 +
 +
<ol type="a">
 +
<li>Assume the provider network layer is insecure. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee a Wi-Fi network (if in-use by the mobile device) will be appropriately encrypted.
 +
<li> Ensure the application actually and properly validates (by checking the expiration date, issuer, subject, etc…) the server’s SSL certificate (instead of checking to see if a certificate is simply present and/or just checking if the hash of the certificate matches). To note, there are third party libraries to assist in this; search on “certificate pinning”.
 +
<li> The application should only communicate with and accept data from authorized domain names/systems. It is permissible to allow application updates which will modify the list of authorized systems and/or for authorized systems to obtain a token from an authentication server, present a token to the client which the client will accept.
 +
<li> To protect against attacks which utilize software such as SSLStrip, implement controls to detect if the connection is not HTTPS with every request when it is known that the connection should be HTTPS (e.g. use JavaScript, Strict Transport Security HTTP Header, disable all HTTP traffic).
 +
<li> The UI should make it as easy as possible for the user to find out if a certificate is valid (so the user is not totally reliant upon the application properly validating any certificates). 
 +
<li> When using SSL/TLS, use certificates signed by trusted Certificate Authority (CA) providers.
 +
</ol>
 +
 +
=== Data Storage and Protection ===
 +
This is a set of controls to help ensure the software handles the storing and handling of information in a secure manner. Given that mobile devices are mobile, they have a higher likelihood of being lost or stolen which should be taken into consideration here.
 +
 +
<ol type="a">
 +
<li>Only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.
 +
<li> Classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification
 +
<li> Store sensitive data on the server instead of the client-end device, whenever possible. Assume any data written to device can be recovered.
 +
<li> Beyond the time required by the application, don’t store sensitive information on the device (e.g. GPS/tracking).
 +
<li> Do not store temp/cached data in a world readable directory. Assume shared storage is untrusted.
 +
<li> Encrypt sensitive data when storing or caching it to non-volatile memory (using a NIST approved encryption standard such as AES-256, 3DES, or Skipjack).
 +
<li> Use the PBKDF2 function to generate strong keys for encryption algorithms while ensuring high entropy as much as possible. The number of iterations should be set as high as may be tolerated for the environment (with a minimum of 1000 iterations) while maintaining acceptable performance.
 +
<li> Sensitive data (such as encryption keys, passwords, credit card #’s, etc…) should stay in RAM for as little time as possible.
 +
<li> Encryption keys should not remain in RAM during the instance lifecycle of the app. Instead, keys should be generated real time for encryption/decryption as needed and discarded each time.
 +
<li> So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and above, Android 4.0 and above), Address Space Layout Randomization (ASLR) should be taken advantage of to limit the impact of attacks such as buffer overflows.
 +
<li> Do not store sensitive data in the keychain of iOS devices due to vulnerabilities in their cryptographic mechanisms.
 +
<li> Ensure that sensitive data (e.g. passwords, keys etc.) are not visible in cache or logs.
 +
<li> Never store any passwords in clear text within the native application itself nor on the browser (e.g. save password feature on the browser).
 +
<li> When displaying sensitive information (such as full account numbers), ensure that the sensitive information is cleared from memory (such as from the webView) when no longer needed/displayed.
 +
<li> Do not store sensitive information in the form of typical strings. Instead use character arrays or NSMutableString (iOS specific) and clear their contents after they are no longer needed. This is because strings are typically immutable on mobile devices and reside within memory even when assigned (pointed to) a new value.
 +
<li> Do not store sensitive data on external storage like SD cards if it can be avoided.
 +
<li> Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet app not usable if GPS data shows phone is outside Europe, car key not usable unless within 100m of car etc...).
 +
<li> 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, use a randomly generated number instead.
 +
<li> Make use of remote wipe and kill switch APIs to remove sensitive information from the device in the event of theft or loss.
 +
<li> Use a time based (expiry) type of control which will wipe sensitive data from the mobile device once the application has not communicated with its servers for a given period of time.
 +
<li> Automatic application shutdown and/or lockout after X minutes of inactivity (e.g. 5 mins of inactivity).
 +
<li> Avoid cached application snapshots in iOS: iOS can capture and store screen captures and store them as images when an application suspends. To avoid any sensitive data getting captured, use one or both of the following options: 1. Use the ‘willEnterBackground’ callback, to hide all the sensitive data. 2. Configure the application in the info.plist file to terminate the app when pushed to background (only use if multitasking is disabled).
 +
<li> Prevent applications from being moved and/or run from external storage such as via SD cards.
 +
<li> When handling sensitive data which does not need to be presented to users (e.g. account numbers), instead of using the actual value itself, use a token which maps to the actual value on the server-side. This will prevent exposure of sensitive information.
 +
</ol>
 +
 +
=== Paywall Controls ===
 +
This is a set of practices to ensure the application properly enforces access controls related to resources which require payment in order to access (such as access to premium content, access to additional functionality, access to improved support, etc…).
 +
 +
<ol type="a">
 +
<li> Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent to a trusted server backend – with user consent) and make them securely available to the end-user for monitoring.
 +
<li> Warn users and obtain consent for any cost implications for application behavior.
 +
<li> Secure account/pricing/billing/item information as it relates to users. If client has made any purchases via the application for instance, we should ensure that what they bought, the size of purchase, the quantity of the purchase, etc… should all be treated as sensitive information.
 +
<li> Use a white-list model by default for paid-for resource addressing.
 +
<li> Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g. significant change in location occurs, user-language changes, etc...
 +
</ol>
 +
 +
=== Server Controls ===
 +
This is a set of practices to ensure the server side program which interfaces with the mobile application is properly safeguarded. These controls would also apply in cases where the mobile application may be integrating with vended solutions hosted outside of the typical network.
 +
 +
<ol type="a">
 +
<li> Ensure that the backend system(s) are running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
 +
<li> Ensure adequate logs are retained on the backend in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
 +
<li> Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DoS type of attacks.
 +
<li> Carry out a specific check of your code for any sensitive data unintentionally transferred between the mobile application and the back-end servers, and other external interfaces (e.g. is location or other information included transmissions?).
 +
<li> Ensure the server rejects all unencrypted requests which it knows should always arrive encrypted.
 +
</ol>
 +
 +
=== Session Management ===
 +
This is a set of controls to help ensure mobile applications handle sessions in a secure manner.
 +
 +
<ol type="a">
 +
<li> Perform a check at the start of each activity/screen to see if the user is in a logged in state and if not, switch to the login state.
 +
<li> When an application’s session is timed out, the application should discard and clear all memory associated with the user data, and any master keys used to decrypt the data.
 +
<li> Session tokens should be revocable (particularly on the server side).
 +
<li> Use lower timeout values to invalidate expired sessions (in contrast to the typical timeout values on traditional (non-mobile) applications).
 +
</ol>
 +
 +
=== Use of 3rd Party Libraries/Code ===
 +
This is a set of practices to ensure the application integrates securely with code produced from outside parties.
 +
 +
<ol type="a">
 +
<li>Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g. making sure they come from a reliable source, will continue to be supported, contain no backdoors) and ensure that adequate internal approval is obtained to use the code/library.
 +
<li> Track all third party frameworks/API’s used in the mobile application for security patches and perform upgrades as they are released.
 +
<li> Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before incorporating their use into an application.
 +
</ol>
 +
 +
== Mobile Application Provisioning/Distribution/Testing ==
 +
This is a set of controls to ensure that software is tested and released relatively free of vulnerabilities, that there are mechanisms to report new security issues if they are found, and also that the software has been designed to accept patches in order to address potential security issues.
 +
 +
<ol type="a">
 +
<li> Design & distribute applications to allow updates for security patches.
 +
<li> Provide & advertise feedback channels for users to report security problems with applications (such as a MobileAppSecurity@ntrs.com email address).
 +
<li> Ensure that older versions of applications which contain security issues and are no longer supported are removed from app-stores/app-repositories.
 +
<li> Periodically test all backend services (Web Services/REST) which interact with a mobile application as well as the application itself for vulnerabilities using enterprise approved automatic or manual testing tools (including internal code reviews).
 +
<li> Based on risk assessment of the application, have the application go through Security Assessment for a review of security vulnerabilities following the Team’s internal security testing of the application.
 +
<li> Utilize the Enterprise provisioning process (e.g. IDM) to request and approve access for users on the mobile application.
 +
<li> Ensure the application is sufficiently obfuscated prior to release by conducting tests which attempt to reverse engineer the obfuscated application.
 +
<li> Distribute applications via an app-store type of interface (when appropriate) as many app-stores monitor applications for insecure code which we may benefit from.
 +
<li> Digitally sign applications using a code signing certificate obtained via a trusted Certificate Authority (CA).
 +
</ol>
  
 
= Top 10 Mobile Controls =
 
= Top 10 Mobile Controls =

Revision as of 15:37, 29 December 2014

OWASP Project Header.jpg

OWASP Mobile Security Project

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

Our primary focus is at the application layer. While we take into consideration the underlying mobile platform and carrier inherent risks when threat modeling and building controls, we are targeting the areas that the average developer can make a difference. Additionally, we focus not only on the mobile applications deployed to end user devices, but also on the broader server-side infrastructure which the mobile apps communicate with. We focus heavily on the integration between the mobile application, remote authentication services, and cloud platform-specific features.


We have a Google Doc where anyone who wants to be involved with the project can add their thoughts, suggestions, and take ownership of initiatives - Click here. There are various tasks that people have started over the past 6 months with varying levels of quality and completeness.

This project is still a work in progress. We are small group doing this work and could use more help! If you are interested, please contact one of the project leads or feel free to visit the mailing list as well!

Email List

Asvs-bulb.jpg Project Email List

Project Leaders

Mike Zusman @
Tony DeLaGrange @
Sarath Geethakumar @
Tom Eston @
Don Williams
Jason Haddix @

Contributors

Zach Lanier @
Jim Manico @
Ludovic Petit @
Swapnil Deshmukh @
Beau Woods @
Jonathan Carter @

Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Mobile_Security_Project&oldid=187368"