What is OWASP?
The OWASP (Open Web Application Security Project) Founded in 2001 as an open-source security community centered around the goal of spreading application security awareness.
OWASP is a non-profit organization dedicated to providing unbiased, practical information about application security. OWASP Top 10 represents a broad consensus about the most critical security risks to web applications.
Adopting the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.
OWASP has started Mobile security project for the top 10 vulnerabilities just like for web applications.
Goal of the OWASP Mobile Security Project:
As per the OWASP, the goal of the project is
“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 with which the mobile apps communicate. We focus heavily on the integration between the mobile application, remote authentication services, and cloud platform-specific features”
Top 10-2016 OWASP Mobile Vulnerabilities: Detail Explanation and Prevention Techniques:
The OWASP Mobile Top 10-2016 Most Critical Mobile Application Security Risks are:
M1:2016 – Improper Platform Usage
M2:2016 – Insecure Data Storage
M3:2016 – Insecure Communication
M4:2016 – Insecure Authentication
M5:2016 – Insufficient Cryptography
M6:2016 – Insecure Authorization
M7:2016 – Client Code Quality
M8:2016 – Code Tampering
M9:2016 – Reverse Engineering
M10:2016 – Extraneous Functionality
OWASP Top 10 is useful for application security efforts. Please don’t hesitate to contact OWASP with your questions, comments, and ideas at our GitHub project repository: https://github.com/OWASP/Top10/issues
You can find the OWASP Top 10 project and translations here: https://www.owasp.org/index.php/top10
M1: Improper Platform Usage:
Description:
This vulnerability covers misuse of the platform or its security controls such as Android intents, platform permissions, and misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.
The exposed service or API call is implemented using insecure coding techniques that produce OWASP Top Ten vulnerability within the server. So through the mobile interface, an attacker will be able to feed malicious inputs to the vulnerable server eventually exploiting the Owasp top 10 vulnerability on the server.
For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 – XSS Category.
Prevention Techniques:
- Secure coding and configuration practices must be used on server-side of the mobile application.
- All the development guidelines from the manufacturer (Android, iOS, Windows) should be followed properly.
Ex: iOS keychain should be used for secure storage instead of local storage.
Through security, testing should be done to avoid unintentional misuse of app features.
M2: Insecure Data Storage:
Description:
When an attacker gets physical access to a mobile device, an attacker can connect the device to a computer with any freely available software to see all the third-party applications directories that often contain stored personally identifiable information (PII) or other sensitive information assets. Attackers can construct malware or modify a legitimate app to steal such information assets.
Sensitive information in data stores on a mobile device’s filesystem is easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores.
Usage of poor encryption libraries is to be avoided. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data.
Insecure data may result in the following business impacts as Identity theft, Privacy violation, Fraud, Reputation damage, External policy violation (PCI), or Material loss.
Most data is stored insecurely in places such as SQL databases, Log files, XML data stores ou manifest files, Binary data stores, Cookie stores, SD cards, Cloud synced.
Rooted or Jailbroken devices are one of the attack vectors to exploit this vulnerability.
Prevention Techniques:
Owasp foundation has given the best guidance to secure mobile devices from this vulnerability i.e.
It is important to threat model your mobile app, OS, platforms, and frameworks to understand the information assets the app processes and how the APIs handle those assets. It is crucial to see how they handle the following types of features:
- URL caching (both request and response);
- Keyboard press caching;
- Copy/Paste buffer caching;
- Application backgrounding;
- Intermediate data
- Logging;
- HTML5 data storage;
- Browser cookie objects;
- Analytics data sent to 3rd parties.
M3: Insecure Communication:
Description:
Threat agents might exploit vulnerabilities to intercept sensitive data while it’s traveling across the medium. Threat agents could be An adversary that shares your local network (compromised or monitored Wi-Fi), Carrier or network devices (routers, cell towers, proxies, etc), or Malware on your mobile device.
Generally, mobile apps may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception. Observe apps network traffic and inspect the design of the application to identify basic flaws for insecure communication.
If exploited, User confidential data might be compromised, session id can be hijacked. If the Admin session-id is hijacked, the entire site can be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.
This risk includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc.
Failing to properly set up and validate a TLS connection (e.g., certificate checking, weak ciphers, other TLS configuration problems) are all here in insecure communication.
Prevention Techniques:
- Setup SSL/TLS communication channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.
- Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.
- Use strong cipher suites with appropriate key lengths.
- Use trusted third party certificates and do not allow self-signed certificates.
- Apply certificate pinning for applications.
- Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain and give an alert to user if self-signed certificate.
- Apply a separate layer of encryption to any sensitive data before it is given to the SSL channel as a secondary defense.
- Below are platform specific recommendations by OWASP adding to above general recommendations.
iOS Specific Best Practices:
Default classes in the latest version of iOS handle SSL cipher strength negotiation very well. Trouble comes when developers temporarily add code to bypass these defaults to accommodate development hurdles. In addition to the above general practices:
- Ensure that certificates are valid and fail closed.
- When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.
- After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self-signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
- Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.
Android Specific Best Practices
- Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.
- If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly implemented so that server certificate is correctly checked.
M4: Insecure Authentication:
Description: This category includes session management issues, privacy issues related to authentication, and issues where user identification tokens are compromised.
Typically this kind of attack is done by automated tools. Attackers may try to bypass direct interaction with the mobile app and send malicious requests to the app’s backend server to exploit the vulnerability. This requests submission process is typically done via mobile malware within the device or botnets owned by the attacker.
Weaker authentication in mobile apps is prevalent due to its mobile device’s poor form factor such as short passwords, 4-digit PINs.
Authentication requirements for mobile apps can be quite different from traditional web authentication schemes due to availability requirements.
In traditional web apps, users are expected to be online and authenticate in real-time with a backend server. Throughout their session, there is a reasonable expectation that they will have continuous access to the Internet.
In mobile apps, users are not expected to be online at all times during their sessions. Mobile internet connections are much less reliable or predictable than traditional web connections.
Hence, mobile apps may have uptime requirements that require offline authentication. This offline requirement can have profound ramifications on things that developers must consider when implementing mobile authentication.
To detect poor authentication schemes, testers can perform binary attacks against the mobile app while it is in ‘offline’ mode. Through the attack, the tester will force the app to bypass offline authentication and then execute functionality that should require offline authentication.
As well, testers should try to execute any backend server functionality anonymously by removing any session tokens from any POST/GET requests for the mobile app functionality.
Authentication failures may expose underlying authorization failures as well. When authentication controls fail, the solution is unable to verify the user’s identity. This identity is linked to a user’s role and associated permissions.
If an attacker is able to anonymously execute sensitive functionality, it highlights that the underlying code is not verifying the permissions of the user issuing the request for the action. Hence, anonymous execution of code highlights failures in both authentication and authorization controls
Prevention Techniques:
- If mobile application is equivalent of web application, then the authentication mechanism and requirements should match that of web application.
- Make sure that authentication requests are validated at server side then only application data should be loaded to app.
- If client-side storage of data is required, the data need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that data is accessible only after user credentials are provided.
- Password should not be stored on device for persistent authentication (remember me).
- Mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device.
- Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location
- Persistent authentication should be implemented as on Opt-in but not by default.
- Better not to use 4-digit pins as password for apps.
- Avoid authenticating a user locally/offline authentication that can lead to client-side bypass vulnerabilities.
If there is a requirement for offline authentication, make sure for local integrity checks within the code to detect any unauthorized code changes.
M5: Insufficient Cryptography:
Description:
Anyone with physical access to data in the device (where improper encryption is applied) or mobile malware can exploit this vulnerability. This vulnerability can be exploited due to weak encryption algorithms or flaws within the encryption process to decrypt the encrypted data. This will result in the unauthorized retrieval of sensitive information from the mobile device.
Typically, broken cryptography will result in Privacy Violations, Information Theft, Code Theft, Intellectual Property Theft, or Reputational Damage.
Prevention Techniques:
- Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform.
- Avoid the storage of any sensitive data on a mobile device where possible.
- Apply cryptographic standards that will withstand the test of time for at least 10 years into the future; and
- Follow the NIST guidelines on recommended algorithms.
M6: Insecure Authorization:
Description:
Typically this vulnerability will be exploited by automated attacks that use available or custom-built tools. Once the adversary understands how the authorization scheme is vulnerable, they log in to the application as a legitimate user. They successfully pass the authentication control.
Once authentication is successful, they typically force-browse to a vulnerable endpoint to execute administrative functionality. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.
To test for poor authorization schemes, testers can perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege while the mobile app is in ‘offline’ mode.
Over-privileged execution of remote or local administration functionality by attackers may result in the destruction of systems or access to sensitive information.
Prevention Techniques:
- Verify the roles and permissions of the authenticated user using only information contained in backend systems. Avoid relying on any roles or permission information that comes from the mobile device itself;
- 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
M7: Poor Code Quality:
Description: Poor code-quality issues are typically exploited via malware or phishing scams. Buffer overflows within older versions of Safari (a poor code quality vulnerability) led to high-risk drive-by Jailbreak attacks.
Carefully crafted malicious inputs are passed onto code that resides within the mobile device where exploitation takes place. Typical types of attacks will exploit memory leaks and buffer overflows.
It is typically difficult to detect these types of issues through manual code review. Instead, attackers will use third-party tools that perform static analysis or perform fuzzing. These types of tools will typically identify memory leaks, buffer overflows, and other less severe issues that result in bad programming practices.
Prevention Techniques:
Owasp foundation has given the below guidelines to prevent this vulnerability.
- Maintain consistent coding patterns that everyone in the organization agrees upon;
- Write code that is easy to read and well-documented;
- When using buffers, always validate that the the lengths of any incoming buffer data will not exceed the length of the target buffer;
- Via automation, identify buffer overflows and memory leaks through the use of third-party static analysis tools; and
- Prioritize solving buffer overflows and memory leaks over other ‘code quality’ issues.
M8: Code Tampering:
Description: Typically, an attacker will exploit code modification via malicious forms of the apps hosted in third-party app stores. The attacker may also trick the user into installing the app via phishing attacks.
Generally, an attacker will exploit this vulnerability by making direct binary changes to the application package’s core binary, making direct binary changes to the resources within the application’s package, or Redirect or replace system APIs to intercept and execute foreign code that is malicious.
An attacker 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. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.
Prevention Techniques:
- The mobile app must be able to detect react at runtime that code has been added or changed from what it knows about its integrity at compile time.
- App should identify android root detection and iOS Jailbreak detection so that application can stop responding.
- The remediation strategies for this type of risk is outlined in more technical detail within the OWASP Reverse Engineering and Code Modification Prevention Project
Reference: https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project
M9: Reverse Engineering:
Description:
An attacker will download the app and try to analyze the app’s design and code in their local environment using some tools.
The attacker will try to perform an analysis of the final core binary to determine its original string table, source code, libraries, algorithms, and resources embedded within the app. Attackers will use relatively affordable and well-understood tools like IDA Pro, Hopper, otool, strings, and other binary inspection tools from within the attacker’s environment.
Once the code is decompiled by an attacker, if it is fairly easy to understand the app’s control flow path, string table, and any pseudocode/source code generated by these tools then code is vulnerable to reverse engineering attack.
Reverse Engineering attacks will Reveal information about back-end servers, Reveal cryptographic constants and ciphers, Steal intellectual property, Perform attacks against back-end systems or Gain the intelligence needed to perform subsequent code modification.
In Reverse Engineering, for source code analysis, consider an Android application. The APK file can be easily extracted using 7zip/Winrar/WinZip/Gunzip. Once extracted, the attacker has manifest files, assets, resources, and most importantly classes.dex file.
Then using Dex to Jar converter, an attacker can easily convert it to a jar file. In the next step, Java Decompiler (like JDgui) will provide you the code.
Prevention Techniques:
The best method to avoid reverse engineering is to obfuscate the app code. There are many free and commercial obfuscators are available in the market.
M10: Extraneous Functionality:
Description:
Attackers will download the application to their local environment and analyze the application log files, configuration files, and perhaps the binary itself to discover any hidden switches or test code that was left behind by the developers. Then they will try to identify irrelevant or extra functionality in the app and try to exploit these functionalities.
This extraneous functionality will be useful for an attacker as it generally exposes information related to back-end test, demo, staging, or UAT environments which should not be included in a production build. Additionally, administrative API endpoints or unofficial endpoints should not be included in final production builds
For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling two-factor authentication during testing.
Prevention Techniques:
The best prevention method for this vulnerability is to perform a secure code review by an expert. Focus on areas such as the app’s configuration settings, test code which is included in the final build, API endpoints, and all log statements, etc.
Found this article interesting? Follow DefenseLead on Twitter, Facebook and LinkedIn to read more exclusive content.