Skip to content

MASWE-0052: Insecure Certificate Validation

Content in BETA

This content is in beta and still under active development, so it is subject to change any time (e.g. structure, IDs, content, URLs, etc.).

Send Feedback

Draft Weakness

This weakness hasn't been created yet and it's in draft. But you can check its status or start working on it yourself. If the issue has not yet been assigned, you can request to be assigned to it and submit a PR with the new content for that weakness by following our guidelines.

Check our GitHub Issues for MASWE-0052

Initial Description or Hints

e.g. not checking the certificate chain, not checking the hostname, not checking the validity period, not checking the revocation status, etc. The certificate validation should be secure by default. This includes the platform-provided mechanisms such as NSC/ATS as well as third-party libraries and frameworks.

Relevant Topics

  • via NSC/ATS
  • via manual server trust evaluation (e.g. iOS SecTrust / Android TrustManager. okhttpTrustManager).
  • Using a TrustManager that does no certificate validation (e.g. X509TrustManager with getAcceptedIssuers returning always null, checkServerTrusted not performing any validation, etc.).
  • doesn't accept self-signed/untrusted CAs
  • Custom Trust Anchors, app trusting any user supplied CAs
  • check OS version's default trust anchors on Android
  • insecure TLS settings
  • third-party libraries e.g. okhttp uses MODERN_TLS or RESTRICTED_TLS configs, no fallbacks via COMPATIBLE_TLS, no weak TLS version or ciphersuites
  • using SSLSocket or Cordova apps
  • MITM via an arbitrary certificate signed by a trusted CA works
  • WebView clients (e.g. WebViewClient.onReceivedSslError, not TLS errors ignored, mixed content, insecure handlers)

References

MASTG v1 Coverage

Tests

MASTG-TEST-0234: SSLSockets not Properly Verifying Hostnames