|
|
(88 intermediate revisions by 5 users not shown) |
Line 1: |
Line 1: |
− | __NOTOC__ | + | __NOTOC__ |
| <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> | | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> |
| | | |
| {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- | | {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- |
− | | valign="top" style="border-right: 1px dotted gray;padding-right:25px;" | | + | | valign="top" style="border-right: 1px dotted gray;padding-right:25px;" | |
| Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' |
− | = Introduction =
| |
− | <b>DRAFT MODE - This Cheat Sheet is a Work in Progress</b>
| |
| | | |
− | This cheat sheet provides a checklist of tasks to be performed to do a penetration test of an Android application. It follows the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project OWASP Mobile Top 10 Risks] list.
| + | After an exchange with the leaders of the [https://github.com/OWASP/owasp-mstg OWASP Mobile Security Testing Guide (MSTG)] project, it was decided to replace the content of this cheat sheet by a reference to the dedicated content on the MSTG project. |
| | | |
− | == Testing Methodology ==
| + | The explanation is simple: |
| + | # It's an OWASP project too. |
| + | # The MSTG project is active. |
| + | # It focus on Android and iOS areas. |
| + | # It provides good and up-to-date advices about how to handle mobile threats for the both platforms. |
| + | # MSTG content came from various specialists in the mobile domain. |
| | | |
− | At the device level, there are 2 ways in which the application shall be tested.
| + | Consult this [https://github.com/OWASP/owasp-mstg#android-testing-guide section] for information about ANDROID platform. |
− | # With Android device running in a factory default or normal mode
| |
− | # With Android device running in a rooted mode
| |
− | | |
− | At the application level, there are 2 ways in which it shall be tested
| |
− | # Application running on the device (to take benefits of touch related features)
| |
− | # Application running on the emulator (to ease the task of testing using wider screen of desktop or laptop)
| |
− | | |
− | == Application Mapping ==
| |
− | | |
− | Map the application for possible security vectors
| |
− | # What is the application genre ? (Game, business, productivity etc)
| |
− | # Does the application connect to backend web services?
| |
− | # Is the application purely native or incorporates readymade frameworks?
| |
− | # Does the application store data on the device?
| |
− | # What all features of the device are used by the application? (camera, gyroscope, contacts etc)
| |
− |
| |
− | = 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
| |
− | | |
− | * /data/data/app_folder
| |
− | * /sdcard/
| |
− | * /sdcard1/
| |
− | | |
− | == M3 - Insufficient Transport Layer ==
| |
− | | |
− | Multiple layer of checks to be performed here
| |
− | | |
− | 1. On Server side
| |
− | * Identify all ssl endpoints.
| |
− | * Perform SSL Cipher Scan using (sslscan)[https://github.com/rbsec/sslscan] or similar software.
| |
− | * 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
| |
− | * Ensure application is working correctly by navigating around.
| |
− | * 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.
| |
− | * Place Proxy RootCA in trusted root CA list in device. (Burp)[https://support.portswigger.net/customer/portal/articles/1841101-configuring-an-android-device-to-work-with-burp] (OWASP-ZAP)[https://security.secure.force.com/security/tools/webapp/zapandroidsetup]
| |
− | * Try using application again. If application still doesn't connect, application might be doing cert pinning.
| |
− | * Install (Xposed Framework)[http://repo.xposed.info/module/de.robv.android.xposed.installer] and (Just Trust Me)[https://github.com/Fuzion24/JustTrustMe], enable JustTrustMe and then reboot device.
| |
− | * 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.
| |
− | | |
− | * adb logcat output
| |
− | * cache and webcache folder locations
| |
− | | |
− | == 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.
| |
− | | |
− | * enumerate all exported activities
| |
− | * start each activity and identify if the activity was suppose to be publicly accessible or not.
| |
− | * Any activity displaying confidential information should be behind authentication. (confidential information includes PII (Personally identifiable data), financial data etc)
| |
− | | |
− | == M6 - Broken Cryptography ==
| |
− | | |
− | There are multiple things to look at
| |
− | | |
− | * Usage of known weak crypto algo's like Rot13, MD4, MD5, RC2, RC4, SHA1
| |
− | * Do it Yourself / let me design my own algo for encryption
| |
− | * Secret key hard coded in the application code itself.
| |
− | | |
− | == 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 or file I/O.
| |
− | | |
− | This gives rise to 2 major issues.
| |
− | | |
− | # SQL / XML injection, and if the reading intent is publicly exposed another application could read this.
| |
− | # 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.
| |
− | | |
− | If the application is a HTML5 hybrid application then Cross Site Scripting (XSS) should also be considered.
| |
− | XSS will expose the entire application to the attacker as HTML5 applications will have the ability to call native functionality and hence control over the entire application.
| |
− | | |
− | == M8 - Security Decisions via untrusted inputs ==
| |
− | == M9 - Improper Session Handling ==
| |
− | Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application.
| |
− | There are multiple things to look at
| |
− | * Check and validate Sessions on the Backend
| |
− | * Check for session Timeout Protection
| |
− | * Check for improper Cookies configuration
| |
− | * Insecure Token Creation
| |
− | | |
− | == M10 - Lack of Binary Protection ==
| |
− | | |
− | = Authors and Primary Editors =
| |
− | | |
− | Jim Manico
| |
− | | |
− | Jonathan Carter
| |
− | | |
− | Prashant Phatak
| |
− | | |
− | Milan Singh Thakur
| |
− | | |
− | Anant Shrivastava
| |
− | | |
− | == Other Cheatsheets ==
| |
− | | |
− | {{Cheatsheet_Navigation_Body}}
| |
− | | |
− | |}
| |
− | | |
− | [[Category:Cheatsheets]]
| |