Overview

WKWebView handles server authentication challenges through WKNavigationDelegate.webView(_:didReceive:completionHandler:). When the app provides a navigation delegate that implements this method, the WebView's default certificate validation is replaced by the app's own logic, completely bypassing the default App Transport Security (ATS) checks.

An insecure implementation calls completionHandler(.useCredential, URLCredential(trust: serverTrust)) without first calling SecTrustEvaluateWithError) on the server's trust object. This bypasses certificate chain validation and hostname verification for every HTTPS page loaded in that WKWebView. An attacker can use any certificate (expired, self-signed, or for the wrong hostname) to intercept or tamper with WebView traffic via a [Machine-in-the-Middle (MITM)](../../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attack.

This test checks whether the app implements WKNavigationDelegate in a way that accepts server certificates without calling SecTrustEvaluateWithError.

More broadly, any reference to URLAuthenticationChallenge only appears when the app implements this authentication-challenge method, which means it has taken over part of the WebView's server trust evaluation. Checking for the absence of SecTrustEvaluateWithError is an efficient heuristic to prioritize the most likely bypasses, but it isn't a substitute for reviewing all custom challenge handling: an implementation that does call SecTrustEvaluateWithError may still evaluate trust incompletely or incorrectly. Treat every code path that handles a URLAuthenticationChallenge as a candidate for manual review.

Steps

  1. Use MASTG-TECH-0058 to extract the relevant binaries from the app package.
  2. Use MASTG-TECH-0066 to look for the relevant APIs in the app binaries.

Observation

The output should contain:

Evaluation

The test case fails if an implementation of webView(_:didReceive:completionHandler:) is found in a WKNavigationDelegate that has no corresponding cross-reference to SecTrustEvaluateWithError.

Further Validation Required:

Inspect each reported code location using MASTG-TECH-0076 to confirm the certificate validation bypass. Look for cases such as:

The absence of a SecTrustEvaluateWithError cross-reference is a heuristic, not a guarantee of a bypass, and its presence is not a guarantee of correct validation. Treat every implementation that accesses URLAuthenticationChallenge as a candidate for manual review, since it has taken control of the server trust evaluation regardless of whether SecTrustEvaluateWithError is called.

Verknüpfte Vorgänge