The following chapter outlines network communication requirements of the MASVS into technical test cases. Test cases listed in this chapter are focused on server side and therefore are not relying on a specific implementation on iOS or Android.
One of the core functionalities of mobile apps is sending and/or receiving data from endpoints, over untrusted networks like the internet. It is possible for an attacker to sniff or even modify trough Man-in-the-middle (Mitm) attacks unencrypted information if he controls any part of the network infrastructure (e.g. an WiFi access point). This puts data in transit on risk and provides additional attack surface. For this reason, developers should make a general rule, that all communication should be encrypted by using HTTPS.
Identify all external endpoints (backend APIs, third-party web services), the app communicates with and ensure that all those communication channels are encrypted.
-- ToDo How can communication be established on Android?
The recommended approach is to intercept all network traffic coming to or from the tested application and check if it is encrypted. Network traffic can be intercepted using one of the following approaches:
- Capture all HTTP and Websocket traffic using an interception proxy, like OWASP ZAP or Burp Suite Professional and observe whether all requests are using HTTPS instead of HTTP.
Interception proxies like Burp or OWASP ZAP will only show HTTP traffic. There are however Burp plugins such as Burp-non-HTTP-Extension and Mitm-relay that can be used to decode and visualize for example XMPP traffic and also other protocols.
Please note, that some applications may not work with proxies like Burp or ZAP (because of Certificate Pinning). In such a scenario, please check "Testing Custom Certificate Stores and SSL Pinning" first. Also tools like Vproxy can be used to redirect all HTTP(S) traffic to your machine to sniff it and investigate for unencrypted requests.
- Capture all network traffic, using Tcpdump. This can be considered in case protocols are used that are not recognized by Burp or OWASP ZAP (e.g. XMPP). You can begin live capturing via the command:
adb shell "tcpdump -s 0 -w - | nc -l -p 1234"
adb forward tcp:1234 tcp:1234You can display the captured traffic in a human-readable way by using Wireshark. It should be investigated what protocols are used and if they are unencrypted. It is important to capture all traffic (TCP and UDP), so you should run all possible functions of the tested application after starting intercepting it.
Ensure that sensitive information is being sent via secure channels, using HttpsURLConnection, or SSLSocket for socket-level communication using TLS.
Please be aware that SSLSocket does not verify the hostname. The hostname verification should be done by using getDefaultHostnameVerifier() with expected hostname. A code example can be found in the Android developer documentation.
- M3 - Insecure Communication - https://www.owasp.org/index.php/Mobile_Top_10_2016-M3-Insecure_Communication
- V5.1: "Sensitive data is encrypted on the network using TLS. The secure channel is used consistently throughout the app."
- CWE-319 - Cleartext Transmission of Sensitive Information
- Tcpdump - http://www.androidtcpdump.com/
- Wireshark - https://www.wireshark.org/
- OWASP ZAP - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
- Burp Suite - https://portswigger.net/burp/
- Vproxy - https://github.com/B4rD4k/Vproxy
Many mobile applications consume remote services over the HTTP protocol. HTTPS is HTTP over SSL/TLS. Other encrypted protocols are less common. Thus, it is important to ensure that the TLS configuration on server side is done properly. SSL is the older name of the TLS protocol and should no longer be used, since SSLv3 is considered vulnerable. TLS v1.2 and v1.3 are the modern and more secure versions, but many services still include configurations for TLS v1.0 and v1.1, to ensure compatibility with older clients.
In the situation where both the client and the server are controlled by the same organization and are used for the purpose of only communicating with each other, higher levels of security can be achieved by more strict configurations.
If a mobile application connects to a specific server for a specific part of its functionality, the networking stack for that client can be tuned to ensure highest levels of security possible given the server configuration. Additionally, the mobile application may have to use a weaker configuration due to the lack of support in the underlying operating system.
For example, the popular Android networking library okhttp uses the following list as the preferred set of cipher suites, but these are only available on Android 7.0 and later:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
To support earlier versions of Android, it adds a few ciphers that are not considered as secure as for example TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Similarly, the iOS ATS (App Transport Security) configuration requires one of the following ciphers:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
In order to do a static analysis the configuration file need to be provided of the web server or reverse proxy where the HTTPS connection terminates. It is unusual to get this kind of information for a mobile penetration test and it also shouldn't be requested by you as the dynamic analysis is very fast and easy to execute.
In case you have the configuration file, check it against the Qualys SSL/TLS Deployment Best Practices.
After identifying all servers your application is communicating with (e.g. by using an interception proxy) you should verify if they allow the usage of weak ciphers, protocols or keys. It can be done, using different tools:
- testssl.sh:
The GitHub repo of testssl.sh offers a compiled openssl version for download that supports all cipher suites and protocols including SSLv2.
$ ./testssl.sh --openssl bin/openssl.Linux.x86_64 yoursite.com
The tool will also help identifying potential misconfiguration or vulnerabilities by highlighting them in red. If you want to store the report preserving color and format use aha:
$ ./testssl.sh --openssl bin/openssl.Linux.x86_64 yoursite.com | aha > output.html
This will give you a HTML document that will match the CLI output.
- O-Saft (OWASP SSL Advanced Forensic Tool):
There are multiple options available for O-Saft, but the most general one is the following, verifying certificate, ciphers and SSL/TLS connection:
perl o-saft.pl +check www.example.com:443
O-Saft can also be run in GUI mode with the following command:
o-saft.tcl
Any vulnerability or misconfiguration should be solved either by patching or reconfiguring the server. To properly configure transport layer protection for network communication, please follow the OWASP Transport Layer Protection cheat sheet and the Qualys SSL/TLS Deployment Best Practices.
- M3 - Insecure Communication - https://www.owasp.org/index.php/Mobile_Top_10_2016-M3-Insecure_Communication
- V5.2: "The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards."
- CWE-327 - Use of a Broken or Risky Cryptographic Algorithm - https://cwe.mitre.org/data/definitions/327.html
- testssl.sh- https://testssl.sh
- O-Saft - https://www.owasp.org/index.php/O-Saft
For sensitive applications, like banking apps, OWASP MASVS introduces "Defense in Depth" verification levels. Critical operations (e.g. user enrollment, or account recovery) of such sensitive applications are one of the most attractive targets from attacker's perspective. This creates a need of implementing advanced security controls for such operations, like adding additional channels (e.g. SMS and e-mail) to confirm user's action. Additional channels may reduce a risk of many attacking scenarios (mainly phishing), but only when they are out of any security faults.
Review the code and identify those parts which refers to critical operations. Verify if it uses additional channels to perform such operation. Examples of additional verification channels are the following:
- Token (e.g. RSA token, yubikey)
- Push notification (e.g. Google Prompt)
- SMS
- Data from another website you had to visit or scan
- Data from a physical letter or physical entry point (e.g.: data you receive only after signing a document at the office of a bank)
Identify all critical operations implemented in the tested application (e.g. user enrollment, or account recovery, money transfer etc.). Ensure that each critical operation, requires at least one additional channel (e.g. SMS, e-mail, token etc.). Verify if the usage of these channels can be bypassed by directly calling the function.
Ensure that critical operations require at least one additional channel to confirm user's action. Each channel must not be bypassed to execute a critical operation. If you are going to implement an additional factor to verify the user's identity, you may consider using Infobip 2FA library or one-time passcodes (OTP) via Google Authenticator.
- M3 - Insecure Communication - https://www.owasp.org/index.php/Mobile_Top_10_2016-M3-Insecure_Communication
- V5.5 "The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery."
- CWE-308 - Use of Single-factor Authentication