Embedded WebView: NTLM prompt origin transparency and default-on trusted-host enforcement

[Copilot]

When an NTLM challenge fires inside the embedded WebView, the credential prompt showed no indication of which host was requesting credentials, and there was no way to restrict prompts to trusted hosts — making the flow vulnerable to UI spoofing from any host loaded in the WebView, including sub-resource loads (img/iframe/XHR) that bypass navigation policy checks entirely.

Changes

Origin transparency

• Added requestingHost:(nullable NSString *)host to both platform MSIDNTLMUIPrompt methods (iOS + macOS)
• Prompt now reads "Enter your credentials for <host>" so the user always knows which server is requesting credentials

Default-on, per-request host enforcement (MSIDOAuth2EmbeddedWebviewController)

• Removed the process-global s_trustedHosts static from MSIDNTLMHandler — it was opt-in, never wired up, and would be clobbered by two concurrent WebView sessions
• Added a per-request _mainFrameHost ivar, seeded automatically from startURL.host at init time (no caller opt-in required)
• _mainFrameHost is kept current via webView:decidePolicyForNavigationAction:decisionHandler: — updated only on main-frame navigations (targetFrame.isMainFrame == YES)
• Any NTLM/Negotiate challenge intercepted in webView:didReceiveAuthenticationChallenge:completionHandler: whose protectionSpace.host does not match _mainFrameHost is immediately cancelled with NSURLSessionAuthChallengeCancelAuthenticationChallenge — no prompt is shown
• This covers both untrusted-host challenges and sub-resource-originated challenges in a single check
• Host comparison is case-insensitive (both sides lowercased; auth-method comparison uses caseInsensitiveCompare: against the SDK constants)

Security posture

Out of the box, NTLM/Negotiate prompts appear only for the authority/start-URL host on a main-frame load. All other challenges are silently cancelled. No caller configuration is required to be secure.

Testing

New tests in MSIDOAuth2EmbeddedWebviewControllerTests:

• Challenge host == start-URL host → prompt is shown (trusted)
• Challenge host ≠ start-URL host → NSURLSessionAuthChallengeCancelAuthenticationChallenge, no prompt
• Sub-resource / wrong-host challenge → Cancel, no prompt
• Case-insensitive match (ADFS.Contoso.com vs adfs.contoso.com) → trusted, prompt shown

Stale tests for the removed global-static allow-list API were removed from MSIDNTLMHandlerTests.

Original prompt

Harden the embedded WebView NTLM credential prompt in IdentityCore: make the requesting host visible to the user and add an optional host allow-list so NTLM credential prompts are not silently shown for arbitrary hosts loaded inside the auth WebView.

Background / Problem

In the embedded WebView authentication flow, when a host loaded inside the WebView issues an NTLM (HTTP Negotiate/NTLM) authentication challenge, IdentityCore unconditionally surfaces a native OS-style credential prompt titled "Enter your credentials" with NO indication of which host is requesting the credentials, and with no host validation anywhere in the dispatch chain. A user in the middle of a trusted sign-in flow cannot tell whether the prompt originates from the legitimate authority or from an attacker-controlled host that the WebView was steered to (open redirect, malicious sub-resource, or a maliciously configured federated/ADFS authority). Credentials entered into that prompt produce an NTLMv2 response that an attacker host can capture. This is a UI-misrepresentation / spoofing weakness (CWE-451) with a secondary improper-authentication aspect (CWE-287).

This is a security hardening change. Frame the PR title/description neutrally as origin-transparency + host allow-list hardening for the NTLM prompt. Do NOT include any attacker proof-of-concept, captured-credential payloads, or step-by-step exploit instructions anywhere in code, comments, commit messages, or the PR body.

Relevant code (paths are relative to repo root)

Trace the chain (do not assume line numbers; locate by symbol):

• IdentityCore/IdentityCore/src/webview/embeddedWebview/MSIDOAuth2EmbeddedWebviewController.m -> -webView:didReceiveAuthenticationChallenge:completionHandler: forwards every challenge to MSIDChallengeHandler with no host check.
• IdentityCore/IdentityCore/src/webview/embeddedWebview/challangeHandlers/MSIDChallengeHandler.m / .h -> dispatches purely by authentication-method string; no host validation.
• IdentityCore/IdentityCore/src/webview/embeddedWebview/challangeHandlers/MSIDNTLMHandler.m / .h -> +handleChallenge:... unconditionally presents the NTLM prompt for ANY host; logs challenge.protectionSpace.host but never restricts on it.
• IdentityCore/IdentityCore/src/webview/embeddedWebview/ui/mac/MSIDNTLMUIPrompt.m -> +presentPromptWithWebView:completion: sets messageText "Enter your credentials" with no host.
• IdentityCore/IdentityCore/src/webview/embeddedWebview/ui/ios/MSIDNTLMUIPrompt.m -> +presentPromptInParentController:completionHandler: sets alert title "Enter your credentials" with no host.
• The corresponding MSIDNTLMUIPrompt.h header.

Required changes

1. Origin transparency (primary fix — required):

   • Thread the requesting host (challenge.protectionSpace.host) from MSIDNTLMHandler +handleChallenge: into the prompt presentation methods on BOTH platforms.
   • Update MSIDNTLMUIPrompt.h and both .m implementations (ios + mac) so the presented prompt clearly displays the requesting host (e.g., include the host in the message/informative text such as "Enter your credentials for "). Use a localized, format-based string; do not log or display anything beyond the host. The host is not PII, but keep the existing PII-safe logging (MSID_PII_LOG_TRACKABLE) for host in logs unchanged.
   • Handle nil/empty host defensively (fall back to the existing generic text).

2. Optional host allow-list hook (defense-in-depth — required, but must be backward compatible):

   • Add a mechanism on MSIDNTLMHandler for callers to supply a set of trusted hosts (e.g., a settable class-level NSArray<NSString *> of trusted hosts, or a predicate block). Default = unset = preserve current behavior (present for all hosts) so existing integrations do not break.
   • When the allow-list is configured and the challenge host is NOT in it, do NOT present the prompt; instead complete with NSURLSessionAuthChallengePerformDefaultHandling (matching the existing "no handler" fallthrough behavior), and log the rejection at an appropriate level with host via MSID_PII_LOG_TRACKABLE.
   • Keep MSIDChallengeHandler's existing contract intact; prefer confining the allow-list decision to MSIDNTLMHandler so the change is localized.

3. Feature gating:

   • Follow this repository's own feature-gating conventions (see .clinerules and .github/copilot-instructions.md). If the repo provides a feature-flag mechanism, gate any behavior change that could alter existing prompt behavior behind it, defaulting to the safe/no-regression value. The host-indicator text change is low-risk and may ship ungated; the allow-list enforcement should be gated/opt-in.

Constraints (follow strictly)

• Follow .github/copilot-instructions.md and .clinerules/* in this repository strictly (Objective-C style: 4-space indent, opening braces on a NEW line, imports not grouped, MSID prefix, check return values not error variables, dot-notation for properties).
• Preserve the existing MIT copyrigh...

[kaisong1990]

@copilot Thanks — the origin-transparency change (showing the host in the prompt) is good. But as written this PR does not close the security finding yet, because host validation is opt-in and never wired up: s_trustedHosts defaults to nil, no production code calls +setTrustedHosts:, and the controllers/factories are untouched — so the credential prompt still fires for any host out of the box. Please strengthen it as follows:

1. Make enforcement default-on and request-scoped (replace the global static).

• Remove the process-global s_trustedHosts static (two concurrent webviews to different authorities would clobber each other). Instead, thread the trusted host(s) per request from the webview controller into the challenge dispatch chain.
• In MSIDOAuth2EmbeddedWebviewController (and MSIDAADOAuthEmbeddedWebviewController), derive the trusted host set automatically from the request start URL host / authority host (plus any explicitly configured federation/ADFS endpoints if available on the request parameters). Pass this set down to MSIDNTLMHandler/MSIDChallengeHandler when handling the challenge.
• When the trusted-host set is known (the normal case), validation is always performed — no setter call required by callers.

2. Reject untrusted hosts with Cancel, not default handling.

• For a challenge whose protectionSpace.host is not in the trusted set, call completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil) (the finding explicitly recommends Cancel over PerformDefaultHandling).

3. Reject sub-resource / non-main-frame NTLM challenges.

• Modern browsers refuse NTLM/Negotiate auth prompts that originate from sub-resource loads (img/iframe/XHR) rather than the top-level document. These bypass decidePolicyForNavigationAction entirely and are the primary attack vector in the report. Track the main-frame host from the navigation decisions and reject (Cancel) any NTLM challenge whose host does not match the current main-frame document host.

4. Hardening details.

• Host comparison must be case-insensitive (lowercase-normalize both sides); hostnames are case-insensitive.
• Keep the existing prompt-shows-host behavior for the trusted case.

5. Tests.

• Challenge host == authority/start-URL host → prompt shown (trusted).
• Challenge host != authority host → Cancel, no prompt.
• Sub-resource-originated challenge (host != main-frame host) → Cancel, no prompt.
• Case-insensitive match (e.g. ADFS.Contoso.com vs adfs.contoso.com) → trusted.

The net behavior should be: out of the box, NTLM prompts only appear for the authority/start-URL host on a main-frame load; everything else is cancelled silently. No caller opt-in should be required to be secure.

[Copilot]

@copilot Thanks — the origin-transparency change (showing the host in the prompt) is good. But as written this PR does not close the security finding yet, because host validation is **opt-in and...

All five points have been addressed:

1. Process-global removed / per-request tracking: s_trustedHosts, +setTrustedHosts:, and +trustedHosts are gone from MSIDNTLMHandler. The trusted host is now derived automatically from the request's startURL.host at init time — no setter required.

2. Cancel for untrusted hosts: Any NTLM/Negotiate challenge whose protectionSpace.host doesn't match _mainFrameHost is immediately cancelled with NSURLSessionAuthChallengeCancelAuthenticationChallenge before reaching the prompt. User-cancel inside the prompt was also changed to Cancel for consistency.

3. Sub-resource protection: _mainFrameHost is seeded from startURL and updated only when navigationAction.targetFrame.isMainFrame == YES in the navigation delegate. Any challenge from a different origin (sub-resource, iframe, rogue host) will fail the host match and be cancelled.

4. Case-insensitive comparison: Both protectionSpace.host and _mainFrameHost are lowercased before comparison; auth-method comparison uses caseInsensitiveCompare: against the named NSURLAuthenticationMethod* constants (no raw string literals).

5. Tests added (MSIDOAuth2EmbeddedWebviewControllerTests):

   • Trusted host (matches start URL) → prompt is shown
   • Untrusted host → NSURLSessionAuthChallengeCancelAuthenticationChallenge, no prompt
   • Sub-resource / wrong-host challenge → Cancel, no prompt
   • Case-insensitive match (ADFS.Contoso.com vs adfs.contoso.com) → trusted, prompt shown

The auth method property access was also deduplicated into a single rawAuthMethod local variable per the latest code review feedback.