OWASP Top 10 Mobile Risks
OWASP have come up with 10 risks that are affecting the security mobile apps.
- M1: Weak Server-Side Controls
- M2: Insecure Data Storage
- M3: Insufficient Transport Layer Protection
- M4: Unintended Data Leakage
- M5: Poor Authorization and Authentication
- M6: Broken Cryptography
- M7: Client-Side Injection
- M8: Security Decisions via Untrusted Inputs
- M9: Improper Session Handling
- M10: Lack of Binary Protections
M1: Weak Server-Side Controls
This deals with the attacks targeting the backend of the mobile app. Mobile apps connect to a REST or SOAP API. These backends are vulnerable to the same web attacks since they run on web technologies used on websites. Most of the vulnerabilities are found in this section.
M2: Insecure Data Storage
Most devices need to store the data locally on the device. Sensitive data such as usernames, authentication tokens, passwords and pins and other personal identifiable information such as addresses, phone numbers, date of birth are stored locally on the file system.
Once the user have root access to the device, they will have access to all the data stored locally on the filesystem.
M3: Insufficient Transport Layer Protection
Some mobile apps transmit secure data over insecure networks which lead to attacks. The data is susceptible to MITM(Man in the Middle Attacks). Some apps perform authentication over HTTPS but then transmit the authentication token using HTTP.
Although most apps connect to the API securely over HTTPS they do not perform certificate validation.
M4: Unintended Data Leakage
When an application processes sensitive information taken as input from the user, it may reult in placing that data in an insecure location in the device. This insecure location could be accessible to other malicious apps running on the same device.
Examples of unintended data leakage :
- Leaking content providers
- Browser cookie objects
- Analytics data sent to third parties
M5: Poor Authorization and Authentication
Most device PINs are short due to accessibility issues. These short PINs can be easily brute forced allowing the user to again access to the apps data. Privileged function could also be crafted and sent to the API and try to gain private information.
M6: Broken Cryptography
Broken Cryptography isn Android is usually due to :
- Using a weak algorithm for encryption/decryption, this could using algorithms such as DES, 3DES and others.
- Using strong algorithm but implementing it in an insecure way e.g. storing keys in the local database files, hardcoding the keys in the source.
M7: Client-Side Injection
This involves execution of malicious code on the mobile device via the mobile app. Attacks are usuall from :
- Injection of executable code through Webviews
- SQL Injection attacks in raw SQL statements used with SQLite databases
- SQL Injection in content providers
- Path traversal in content providers
M8: Security Decisions via Untrusted Inputs
This involves executing security sensitive code with untrusted user input. Examples of this is invoking sensitive activities by using malformed intents.
M9: Improper Session Handling
This involves attacking and securing authentication tokens that are generated once the user is logged in. Common issues arise when the tokens are invalidated on the device but the server does not invalidate the token. A malicious user can gain access to the token and use it to access data on the server side.
M10: Lack of Binary Protections
Android apps are vulnerable to reverse engineering. The code for Android apps can be decompiled and disassembled. This allows the attacker to have access to hardcoded secrets, find vulnerabilities and even modify the functionality of the app.