Android Testing Cheat Sheet
Last revision (mm/dd/yy): 03/18/2016
DRAFT MODE - This Cheat Sheet is a Work in Progress
This cheat sheet provides a checklist of tasks to be performed to do a penetration test of an Android application. It follows the OWASP Mobile Top 10 Risks list.
At the device level, there are 2 ways in which the application shall be tested.
At the application level, there are 2 ways in which it shall be tested
Map the application for possible security vectors
OWASP Step-by-step Approach
(For each of the standards below, there shall be multiple steps for the tester to follow])
M1 - Weaker Server side controls
M2 - Insecure Data storage
This Section should be ideally tested after using the application for some time. This way application has time to store some data on the disk.
Commonplaces to look at
M3 - Insufficient Transport Layer
Multiple layer of checks to be performed here
1. On Server side
* SSLv2, SSLv3 is disabled * TLS 1.2, 1.1 and 1.0 is supported (1.2 is essential to ensure highest possible secure connection) * RC4 and CBC Based Ciphers are disabled * DH Params are >2048 Bits * SSL Certificate is signed with atleast sha2 / sha256 * ECDHE Ciphers / Ciphers supporting Perfect forward secrecy are preferred * SSL Certificate is from Trusted RootCA * SSL Certificate is not expired
2. On Device Side
1. Ensure application is working correctly by navigating around. 2. Put a proxy in between the application and remote server. If application fails to load. Application might be doing cert validation. Refer logcat if any message is printed. 3. Place Proxy RootCA in trusted root CA list in device. (Burp) (OWASP-ZAP) 4. Try using application again. If application still doesn't connect, application might be doing cert pinning. 5. Install (Xposed Framework) and (Just Trust Me), enable JustTrustMe and then reboot device. 6. Try again if everything works we have a application which employee's cert pinning.
M4 - Unintended Data Leakage
Simmilar to M2 this section requires application to be used however while the application is in use we need to monitor following places.
M5 - Poor Authorization and Authentication
One of the simplest check's to be performed after application is used for some time and it has time to put the data inside system.
M6 - Broken Cryptography
There are multiple things to look at
M7 - Client Side Injection
Android applications need to store data locally in sqlite files or XML structures and hence need to performs either SQL/XML Queries to DB or file read calls. This gives rise to 2 major issues.
1. SQL / XML injection, and if the reading intent is publically exposed another application could read this. 2. Local file read which can allow other application to read files of the application in question and if they contain sensitive data then data leakage via this media.
Besides this if we are dealing with HTML5 / Hybrid application XSS or Cross Site Scripting can also be considered. This XSS will expose the entire application to attacker as HTML5 applications will have wrapper to call native functionality and hence XSS will have control over entire application.
M8 - Security Decisions via untrusted inputs
M9 - Improper Session Handling
M10 - Lack of Binary Protection
Authors and Primary Editors
Milan Singh Thakur