Address Mobile Application Risks
Learning Objectives
After completing this unit, you’ll be able to:
- Describe how to address insecure authorization.
- List actions to improve code quality.
- Explain how to mitigate code tampering.
- Identify reverse engineering risks.
- Describe how to prevent extraneous functionality risks.
Address Mobile Risks
Let’s continue to follow Angeli as she works to secure her organization’s mobile apps, using the Open Web Application Security Project (OWASP) Mobile Top 10 as a guide.
M6: Insecure Authorization
This risk covers a case where a threat agent exploits authorization vulnerabilities through attacks that use available or custom-built tools. It’s important to recognize the difference between authentication and authorization. Authentication is the act of identifying an individual. Authorization is the act of confirming that the identified individual has the permissions necessary to perform the act. The two are closely related, as authorization checks should always immediately follow authentication of an incoming request from a mobile device.
Upon inspecting the organization’s applications (apps) carefully, Angeli discovers that authorization decisions are being executed locally on the client-side of the mobile app during the authentication request. This could lead to a situation where an adversary could tweak an incoming request and masquerade as a member of a group they don’t belong to, to gain access to administrative functionality.
Angeli works with the developers to update the app to authorize the roles and permissions of authenticated users using only information contained in back-end systems. She reminds them it’s important to avoid relying on any roles or permission information that comes from the mobile device itself.
M7: Poor Code Quality
This risk covers the case where a threat agent passes untrusted inputs to method calls (operators used to call self-contained blocks of code that perform a specific task) made within mobile code. Threat actors typically exploit these poor code quality issues via malware or phishing scams.
Working with the mobile app pen testing team, Angeli learns that the team has been able to exploit a buffer overflow vulnerability in one of the organization’s apps. The exploit allows them to write into areas known to hold executable code and replace it with malicious code. She works with the development team to reengineer the code by marking certain regions within the code as nonexecutable—a technique known as executable space protection. They also implement bounds checking to automatically check that data written to a buffer is within acceptable boundaries. Finally, Angeli works with the team to implement an automated process to identify future buffer overflows through the use of third-party static analysis tools.
M8: Code Tampering
This risk covers the case where the organization’s apps do not implement code signing. The lack of code signing allows an attacker to tamper with the app’s code. Typically, this attack occurs when an attacker tweaks a legitimate app’s code after downloading it from a popular app store. The attacker modifies the app to include malicious code then uploads it to a lesser known third-party app store, where an unsuspecting user downloads it.
Angeli discovers that an attacker has created a counterfeit version of one of her organization’s apps. The counterfeit version captures and transmits the user’s personally identifiable information (PII), along with their username/password, to a third-party site. This allows the attacker to use the information for fraudulent purposes.
Angeli contacts both app stores to inform them of the fraudulent use. She provides her app’s signature (distinctive, pattern-based detection methods which use expressions or marks for identifying app traffic), so the store can verify that her company is the legal owner of the app. They remove the unauthorized copies of the app from their stores, replacing it with the signed version. Angeli puts in place a plan to continually monitor the major app stores to check for any new unauthorized versions that have been published, and to submit new reclaiming requests on a regular basis.
M9: Reverse Engineering
This risk covers the case where an attacker downloads the targeted app from an app store and analyzes it within their own local environment using a suite of different tools to see how it works. The attacker uses reverse engineering to reveal sensitive and unencrypted information about back-end servers, cryptographic constants and ciphers, intellectual property, and more.
Working with the mobile app pen testing team to evaluate one of the organization’s apps, Angeli discovers that an attacker would be able to run strings against the unencrypted app and find a hard-coded connection string that contains authentication credentials to a back-end database. An attacker could use those credentials to gain access to the database and steal PII data about the app’s users. Angeli consults with the development team on a remediation, and they decide to remove the hard-coded connection string and replace the functionality with a server side access controlled API to provide the required data to the application.
M10: Extraneous Functionality
This risk covers the case where an attacker seeks to understand extraneous functionalities or unnecessary components within a mobile app to discover hidden functionality in back-end systems. The attacker can typically exploit extraneous functionality directly from their own systems without any involvement by end users.
Working with the organization's pen testing team, Angeli discovers that the mobile app developers included backdoor functionality in one of the organization’s apps that was not intended for release into production environments. An attacker could discover this functionality and use it to execute back-end administrative functions. To prevent this from happening in the future, Angeli works with her organization to implement manual, secure code reviews using subject matter experts most knowledgeable with this code.
The subject matter experts make sure to examine the app’s configuration settings to discover any hidden switches, remove test code from the final production release, and examine all application programming interface (API) endpoints accessed by the mobile app to verify that they’re well documented and publicly available. They also examine log statements to ensure nothing overly descriptive about the back end is being written to the logs. Thanks to the OWASP Mobile Top 10, Angeli’s organization is now much more secure.
Knowledge Check
Ready to review what you’ve learned? The following knowledge check isn’t scored; it’s just an easy way to quiz yourself. To get started, drag the description in the left column next to the matching term on the right. When you finish matching all the items, click Submit to check your work. If you’d like to start over, click Reset.
Great work!
Sum It Up
Now that you understand how to use the OWASP Mobile Top 10 to mitigate mobile application security (appsec) risks, let’s turn to testing mobile apps next.
