Apptrusty

Mobile Top 10 OWASP M10 Extraneous Functionality

Mobile Top 10 OWASP M10 Extraneous Functionality

Typically, an attacker seeks to understand extraneous functionality within a mobile app in order to discover hidden functionality in in backend systems. The attacker will typically exploit extraneous functionality directly from their own systems without any involvement by end-users. An attacker will download and examine the mobile app within their own local environment. They will examine log files, configuration files, and perhaps the binary itself to discover any hidden switches or test code that was left behind by the developers. They will exploit these switches and hidden functionality in the backend system to perform an attack.

There is a high likelihood that any given mobile app contains extraneous functionality that is not directly exposed to the user via the interface. Most of this additional code is benign in nature and will not give an attacker any additional insight into backend capabilities. However, some extraneous functionality can be very useful to an attacker. Functionality that exposes information related to back-end test, demo, staging, or UAT environments should not be included in a production build. Additionally, administrative API endpoints, or unofficial endpoints should not be included in final production builds. Detecting extraneous functionality can be tricky. Automated static and dynamic analysis tools can pick up low hanging fruit (log statements). However, some backdoors are difficult to detect in an automated means. As such, it is always best to prevent these things using a manual code review. The technical impact from extraneous functionality includes the following:

  • Exposure of how backend systems work; or
  • Unauthorized high-privileged actions executed.

Am I Vulnerable To ‘Extraneous Functionality’? Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.

The defining characteristic of this risk is leaving functionality enabled in the app that was not intended to be released.

Leave a Reply

Your email address will not be published.