Security Checklist II

This is the second part of the Mobile App testing checklist series. The first part is presented here. Continuing the series, we present a checklist of test cases for some more categories.

Network Communication Requirements

Apps serve as the front end and frequently make network calls to backend systems. This interaction involves exchanging critical information like personal details, bank information. Communication with external systems, particularly over the WWW, requires that the data sent should be over a secure channel to prevent it from being compromised.

For Android and iOS

Verify All network traffic goes via SSL

Verify SSL Pinning is enabled.

i.e. Using MITM tools like Charles, verify that the https traffic cannot be decrypted Platform Interaction Requirements

Platform Interaction Requirements

Modern smartphones offer a bevy of features. Camera, location, Bluetooth, gyroscope, and many more. Apps that use any such feature have to ask for the user’s consent to use the same. It is necessary to verify if the user is prompted to wilfully permit the app to use any feature outside of itself.

For Android

• Verify for dangerous permissions, for all the below permissions an explicit prompt should be displayed to the user
• READ_CALENDAR
• WRITE_CALENDAR
• READ_CALL_LOG
• WRITE_CALL_LOG
• PROCESS_OUTGOING_CALLS
• CAMERA
• READ_CONTACTS
• WRITE_CONTACTS
• GET_ACCOUNTS
• ACCESS_FINE_LOCATION
• ACCESS_COARSE_LOCATION
• RECORD_AUDIO
• READ_PHONE_STATE
• READ_PHONE_NUMBERS
• CALL_PHONE
• ANSWER_PHONE_CALLS
• ADD_VOICEMAIL
• USE_SIP
• BODY_SENSORS
• SEND_SMS
• RECEIVE_SMS
• READ_SMS
• RECEIVE_WAP_PUSH
• RECEIVE_MMS
• READ_EXTERNAL_STORAGE
• WRITE_EXTERNAL_STORAGE
• Verify unnecessary permission are not added in Android.manifest file
• Verify app authentication is required when using Deep Links in the app
• If webviews are displayed inside the app, ensure the url is https, and cannot be decrypted via Charles
• Disable local file access in Code. Check with the developer and see if these restrictions are in place.
• webView.getSettings().setAllowFileAccess(false);
• webView.getSettings().setAllowFileAccessFromFileURLs(false);
• webView.getSettings().setAllowUniversalAccessFromFileURLs(false);
• webView.getSettings().setAllowContentAccess(false);
• Verify that App can be force updated.

For iOS

• Verify app ask user permissions for the following
• Bluetooth peripherals
• Calendar data
• Camera
• Contacts
• Health sharing
• Health updating
• HomeKit
• Location
• Microphone
• Motion Music and the media library
• Photos
• Reminders
• Siri
• Speech recognition
• the TV provider
• Verify app authentication is required when using Deep Links in the app
• Verify webviews only load https content. Check the code for WKWebView and verify the following flag “hasOnlySecureContent” is set to true
• Verify Webviews cannot be decrypted via Charles
• Verify Both allowFileAccessFromFileURLs and allowUniversalAccessFromFileURLs are set to “0”, on webviews are set. Check with developers
• Verify that App can be force updated.

Code Quality and Build setting requirements

Apps have a minimum of two configurations; a debug version where the app is not yet optimized for release or customer use.

For example, logs would be enabled in the debug version to track bugs while developing. In the debug version, the app can get away with being slower and “fatter”. Apps also have a production version, meant for end-users. Here the app is “thinned” down for the target device on which the app is running. This version is optimized. So when it comes to the production version of the app, it is essential to test the build settings and other aspects used only for the debug version such that it does not leak into the production version.

For Android

• Verify APK is Signed correctly.
• Test using the following command,
• apksigner verify –verbose Desktop/example.apk,

Following output should be displayed

for example,

Verified using v1 scheme (JAR signing): true

Verified using v2 scheme (APK Signature Scheme v2): true

Verified using v3 scheme (APK Signature Scheme v3): true

Number of signers: 1

• Verify the store build is generated as a “Release” build and not “Debug” build.
• Using apktool decompile apk and check AndroidManifest.xml, android:debuggable should false
• Verify APK is Obfuscated (i.e, Proguard is enabled) and no sensitive data is visible.Decompile the apk using apktool. Convert classes.dex to .jar using d2j-dextojar. View the jar file via JDGUI
• Verify all debug logs are disabled. Run adb logcat and check if the apk is displaying any sensitive information

For iOS

• Check the ipa is Release Mode and not in Debug Mode. Use Xcode and Check if the app can be debugged.
• Check all debug logs are disabled and no sensitive information is logged in Xcode
• Verify “Strip Debug Symbols During Copy”, “Strip Linked Product”, “Strip Swift Symbols” are set to Yes in Xcode build settings
• Check for vulnerabilities in 3rd party Pods. Run OWASPs tool
• dependency-check –enableExperimental –out . –scan Podfile.lock
• Resiliency

For Android

• Verify apk does not launch on rooted devices.
• Checksum of apks should be created and validated against the server every time it’s launched.

For iOS

• Verify app does not launch on Jailbroken phones
• Obfuscate code with iXGuard and verify via MachoView tool

Advanced testing strategy for apps - Security Checklist 1

Agile methodologies and DevOps are widely adopted by many software service providers and consulting companies. The primary driver for this adoption being, faster delivery of products, independent teams, and generally better all-around synergy between the engineering and operations team.

In this DevOps and Agile world, the traditional modes of quality assurance, like manual testing, are not as effective when it comes to quality assurance. Granted, risk analysis, test planning, and test management are still important, but to ensure the same level of quality in an Agile world as before, or even better, organizations are using new skills such as test automation, data analytics, and AI technologies amongst others.

In this two-part blog(IInd part coming soon), we provide an example of such an advanced testing strategy via a checklist for mobile app testing on the two most popular platforms, iOS and Android. We cover a wide spectrum of categories ranging from tests related to how and where to store data, testing the entire authentication flow, code quality, platform interaction scenarios, and many more. You can download the entire checklist here, or for a detailed explanation, read on.

1) Data storage and privacy

Mobile devices are a constant companion in the digital era. They are used for various purposes such as entertainment, work, personal, professional, etc. Users interact a lot with mobile devices and invariably enter or store details about themselves. Contacts, bank account, health information, habits and preferences, travel logs, etc. Hence it’s no surprise that the number one priority while testing is data storage and privacy, i.e., to ensure that the app does not “leak” any confidential information.

For Android

1. No Sensitive information is stored in AndroidManifest.xml file
2. No Sensitive information is stored in Gradle.properties file
3. No Sensitive information is stored in any strings.xml folders in apk package
4. [Shared Preferences Check] Install apk on Android phone (or emulator) and navigate to /data/data/<package-name>/shared-prefs/keys.xml. Verify no sensitive data is being stored there.
5. [SQLite Databases Check] Install apk on Android phone (or emulator) and navigate to /data/data/<package-name>/databases/. Verify no sensitive information is stored in sqlite dbs
6. [Encrypted Database] Install apk on android phone (or emulator) and navigate to /data/data/<package-name>/databases and verify databases which have sensitive data are encrypted.
7. Verify that debug logs are disabled on production build. Connect device to your machine , run the following command adb logcat | grep “$(adb shell ps | grep <package-name> | awk ‘{print $2}’)” and verify the logs when app is running
8. Verify input fields that ask for sensitive data for e.g. “Password” are masked
9. Verify input fields that ask for sensitive data for e.g. “Password” does not display auto suggestions by default.
10. Verify input fields that ask for sensitive data for e.g. “Password” , Cut, Copy, Paste options should not work on these fields
11. By Default Backups should be disabled. In Androidmanifest.xml, verify android:allowBackup is set as false.
12. If Backup is a requirement, then check that no sensitive data is backed up.

Then run a backup from adb, adb backup -apk -nosystem <package-name>

ADB should respond now with “Now unlock your device and confirm the backup operation” and you should be asked on the Android phone for a password. Approve the backup from your device by selecting the Back up my data option. After the backup process is finished, the file .ab will be in your working directory.

Run the following command to convert the

.ab file to tar. dd if=mybackup.ab bs=24 skip=1|openssl zlib -d > mybackup.tar

Analyse the backup and check if there is any sensitive data stored.

For iOS

Verify no sensitive data Is stored in App Bundles DB. Run a simulator build, and navigate to

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/var/mobile/Containers/Data/Application/$APP_ID/. read .db files

and verify no sensitive data is saved here.

Verify Keychain

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/data/Library/Keychains/keychain-2-debug.db.

Data stored here should be encrypted

Logs should not have any sensitive data.

Verify input fields that ask for sensitive data for

e.g. “Password” are masked

Verify input fields that ask for sensitive data for

e.g. “Password” does not display auto suggestions by default.

Verify input fields that ask for sensitive data for

e.g. “Password” , Cut, Copy, Paste options should not work on these fields

2) Cryptography Requirements

While it’s important to test if data is stored securely, it’s equally important to verify if data is stored securely, i.e., is it encrypted. This can be defined as “How is data stored” compared to testing “Where is data stored.” Confidential information like passwords, secret questions, and answers, keys should never be stored in a human-readable format. Both Android and iOS use the AES 256 Keys algorithm to encrypt confidential information, and app developers must leverage this.

For Android

1. Verify sensitive data is encrypted when stored in the device. Encryption keys used should be saved in Android. Keystore

For iOS

1. Verify sensitive data is encrypted when stored in the device. Encryption keys used should be saved in Secure Keychain

3) Authentication and Session Management

Apps usually have a sign in, signup, and authentication mechanism. Authentication identifies a user. Depending on authentication, certain resources are authorized. A user logs in, consumes services, and eventually logs out. This is known as a session. The critical thing in this flow is to ensure that the user is correctly authenticated most safely, and only those resources are allocated to him for which he is authorized.

For Android

1. Passwords should have a strong Password Policy. Comprising of Minimum password length should be 8 characters. Password should contain the combination of following characters as mentioned below

a. Lower Case (a-z)

b. Numeric (0–9)

c. Upper Case (A-Z)

d. Non-Alphanumeric (e.g.!, @, etc.)

2. If needed 2FA Authentication should be present

3. When a password is entered multiple times, then app lockout should be implemented

4. Session IDs are always exchanged over secure connections

(e.g. HTTPS).

5. Verify The server verifies the session whenever a user tries to access privileged application elements,

(a session ID must be valid and must correspond to the proper authorization level).

6. Verify The session is terminated on the server side and session information deleted within the mobile app after it times out or the user logs out.

For iOS

1. Verify no sensitive data Is stored in App Bundles DB. Run a simulator build, and navigate to

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/var/mobile/Containers/Data/Application/$APP_ID/. read .db files and verify no sensitive data is saved here.

2. Verify Keychain

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/data/Library/Keychains/keychain-2-debug.db.

Data stored here should be encrypted

3. No sensitive data should be printed in Logs.

4. Verify input fields that ask for sensitive data for

e.g. “Password” are masked

5. Verify input fields that ask for sensitive data for

e.g. “Password” does not display auto suggestions by default.

6. Verify input fields that ask for sensitive data for

e.g. “Password” , Cut, Copy, Paste options should not work on these fields

Conclusion

This concludes the first part of this series, where we presented a checklist for testing mobile apps in the data storage & privacy category, cryptography requirements categories, and Authentication and session management category. In the next part, we will examine the test cases for the Network communications category, Platform Interaction, Code Quality and Build setting, and Resiliency category.