This one has dropped from number three since the 2016 list.

Threat Agents	Application Specific Virtually all apps are involved in the transmission of data to and from remote servers, via the user’s carrier networks or a Wi-Fi connection to the internet. There are ways of intercepting this traffic, so it needs to be sufficiently secured. Threats can include: – Compromised Wi-Fi – a threat actor sharing your local network – On-device malware – A rogue carrier or network device, such as a Wi-Fi Pineapple
Attack Vectors	Exploitability: EASY Despite well documented standards, apps can sometimes have flaws in their implementations, including: – Using bad configuration settings or outdated protocols – Inconsistent application of encryption standards – Accepting bad SSL certificates and swallowing exceptions raised
Security Weakness	Prevalence: COMMON Detectability: AVERAGE Apps, for the most part at least, make concerted efforts to protect data in-transit. However, use of transport security protocols does not guarantee their correct implementation. Take steps to check the network traffic to and from the device.
Technical Impacts	Impact: SEVERE Possible consequences of a flaw in this area include PII leaks, user impersonation and complete account takeover. It can lead to the interception of MFA codes if the MFA implementation is not sufficiently robust.
Business Impacts	Impact: MODERATE At a minimum, this will likely result in a privacy violation. This could then lead to falling short of legal data handling requirements.
Causes	– Incorrect SSL implementation – Lack of certificate pinning – Neglect of the full range of communication channels – Bluetooth, NFC, etc.
Prevention	– Assume all communication channels are compromised and secure accordingly – Use strong, industry standard cipher suites with appropriate key lengths – Never allow bad certificates (e.g. self-signed, untrusted root, revoked) – Apply certificate pinning – Alert users if the app detects an invalid certificate – Avoid overriding SSL verification to allow untrusted certificates during development – Don’t send sensitive data via unsecured channels – Consider runtime application self-protection (RASP) security checks

There are some platform specific best practices to run through here as well.

iOS Specific Best Practices

The latest versions of iOS do a good job when it comes to SSL cipher strength. Issues arise when developers add ‘temporary’ code to bypass checks during the development cycle. It’s critical that either:

• This is not done; or
• This is done in a way which automatically excludes such code from production builds and production test builds

In addition to this:

• Ensure that certificates are fully valid and fail closed
• Ensure that every NSURL call will reject self-signed or invalid certificates. Check for setAllowsAnyHTTPSCertificate.
• Implement best practice certificate pinning:
  • Export the certificate
  • Include it in the app bundle
  • Anchor it to the trust object

Android Specific Best Practices

• After the development cycle, remove all code which allowed the app to accept all certificates, such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER, as these are equivalent to trusting all certificates. Better still:
  • Avoid using code like this; or
  • Only ever use code like this in a way which ensures it is automatically excluded from production and production test builds
• Do not use overrides of onReceivedSslError to allow invalid SSL certificates
• Ensure that the checkServerTrusted method is correctly implemented if SSLSocketFactory is extended

.Net Maui Specific Best Practices

Contact us if you need assistance doing this in .Net Maui.

Closing Thoughts

The impacts of getting this wrong can include leaving your app susceptible to man-in-the-middle (MITM) attacks (by not inspecting the certificate), compromised confidentiality (through weak encryption), sensitive information leakage and credential leakage (through the use of unsecured channels) and even multi-factor authentication bypass (by receiving a session identified via an unsecured channel).

Considering all this, it’s surprising that the OWAS classification of Business Impact is only Moderate.

If you want to chat to us more about any of this, or to discuss any mobile app requirements or questions you may have, then get in touch.