OWASP - User contributions [en]

Android Testing Cheat Sheet

2016-03-23T11:26:36Z

SaravanaKumar: /* M5 - Poor Authorization and Authentication */

__NOTOC__
<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;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
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.

== Testing Methodology ==

At the device level, there are 2 ways in which the application shall be tested.
# 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)

===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

== 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 ==

== 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]]

Android Testing Cheat Sheet

2016-03-23T10:24:41Z

SaravanaKumar: /* M8 - Security Decisions via untrusted inputs */

__NOTOC__
<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;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
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.

== Testing Methodology ==

At the device level, there are 2 ways in which the application shall be tested.
# 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 ==

== 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]]

Android Testing Cheat Sheet

2016-03-23T10:14:05Z

SaravanaKumar: /* M9 - Improper Session Handling */

__NOTOC__
<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;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
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.

== Testing Methodology ==

At the device level, there are 2 ways in which the application shall be tested.
# 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
--[[User:SaravanaKumar|SaravanaKumar]] ([[User talk:SaravanaKumar|talk]]) 05:14, 23 March 2016 (CDT)

== 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]]

Android Testing Cheat Sheet

2016-03-23T10:13:26Z

SaravanaKumar: /* M9 - Improper Session Handling */

__NOTOC__
<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;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
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.

== Testing Methodology ==

At the device level, there are 2 ways in which the application shall be tested.
# 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]]

User:SaravanaKumar

2016-03-23T06:24:02Z

SaravanaKumar:

Saravana is information security guy who is working as security engineer.
Throughout career he has worked with major corporations on secure architecture and software security. He’s also performed multiple of technical security assessments for financial, enterprise, E-commerce and few customers worldwide.

Saravana holds a Master of Science degree in Software Systems.He have completed globalized information security certifications like Offensive Security Certified Professional (OSCP) , Certified Ethical Hacker(CEH v8) and IT management certification ITIL Foundation.