Open Redirect

Executive Summary

An open redirect vulnerability occurs when an application accepts a user-controlled destination and issues a redirect without strict validation. While often treated as low severity in isolation, open redirects become high-impact when chained with phishing, OAuth abuse, token leakage, or session theft workflows.

In Salesforce ecosystems, the risk is commonly introduced in Visualforce controllers, custom login handlers, post-authentication return flows, and generic "continue" parameters.

Salesforce Attack Surface

Prioritize review of all endpoints that accept destination, return, next, continue, or callback style parameters.

• Visualforce pages using ApexPages.currentPage().getParameters() for navigation decisions
• Lightning-to-VF bridges that pass URL fragments or destination parameters
• Custom SSO and OAuth callback handlers
• Post-login and post-logout redirect handlers
• Email links that preserve user journey using return URL parameters

Typical vulnerable pattern:

// Insecure pattern: user-controlled redirect target
String nextUrl = ApexPages.currentPage().getParameters().get('next');
return new PageReference(nextUrl);

Business Impact

• Credential phishing at scale: trusted domain links route users to attacker-controlled login pages
• Token and authorization abuse: redirect manipulation can interfere with OAuth and consent journeys
• Brand trust erosion: users associate malicious outcomes with your legitimate domain
• Incident response overhead: abuse campaigns trigger support, security, and legal workflows
• Chainable exploitation: open redirect can amplify impact of other vulnerabilities

PoC Use Cases (Open Redirect VF)

Use the PoC suite to validate multiple exploit classes, not just one external URL test.

• External domain redirect: absolute URL to attacker infrastructure
• Protocol abuse attempts: javascript:, data:, and malformed schemes
• Encoded bypasses: URL-encoded and double-encoded payloads
• Prefix/suffix confusion: trusted-looking hostnames and subdomain tricks
• Mixed-case and Unicode edge cases: parser inconsistencies and normalization gaps

Representative vulnerable flow:

<apex:page controller="RedirectController">
    <script>
        window.location = '{!redirectUrl}';
    </script>
</apex:page>

// Example payload
// /apex/Redirect?redirectUrl=https://attacker.example/phish

Testing Methodology

Apply a repeatable methodology to avoid false confidence:

• Discover: enumerate all redirect-capable endpoints and parameters
• Fuzz: test absolute URLs, scheme variations, encoded payloads, and parser edge cases
• Observe: confirm final destination from server response and browser behavior
• Assess exploitability: validate real phishing or workflow abuse potential
• Document evidence: include request, response, redirection chain, and impact narrative

Secure Engineering Patterns

Recommended approach: route by server-managed identifiers, not by raw URLs from user input.

// Preferred: map key to trusted internal route
private static final Map<String, String> ALLOWED_ROUTES = new Map<String, String>{
    'dashboard' => '/lightning/page/home',
    'cases'     => '/lightning/o/Case/list'
};

public PageReference secureRedirect() {
    String target = ApexPages.currentPage().getParameters().get('target');
    String safePath = ALLOWED_ROUTES.get(target);

    if (String.isBlank(safePath)) {
        safePath = '/home/home.jsp';
    }

    PageReference pr = new PageReference(safePath);
    pr.setRedirect(true);
    return pr;
}

• Allow only internal routes or strict host allowlists
• Normalize and validate before redirect decisions
• Deny unknown destinations with safe fallback
• Log blocked redirect attempts for abuse detection

Verification Checklist

• All redirect endpoints mapped and tested
• External domains blocked unless explicitly approved
• Encoded and mixed-format payloads rejected
• Only policy-approved targets allowed
• Fallback route implemented and tested
• Security logging in place for rejected redirects
• No regression in auth/login/logout journeys

Lab Exercises

Work through the sequence below to complete this lab in a production-relevant format:

• Exercise 1: Enumerate redirect sinks in Visualforce and related flows
• Exercise 2: Execute PoC-Openredirection-VF payload families
• Exercise 3: Assess real exploitability and user-impact scenarios
• Exercise 4: Implement policy-based redirect controls
• Exercise 5: Perform regression and abuse-case validation