Redirect URIs and Open Redirect Attacks

Redirect URIs and Open Redirect Attacks

1. Redirect URIs

A Redirect URI is the exact URL in your application where an authorization server (e.g., OAuth 2.0 / OpenID Connect provider) sends the user after authentication or consent. It is a critical part of OAuth flows because it is where authorization codes or tokens are delivered.

Why It Matters

• Ensures the authorization response is sent to the correct application endpoint.
• Prevents attackers from intercepting tokens by redirecting them to malicious sites.
• OAuth/OIDC providers require pre‑registration of allowed redirect URIs.

Example in OAuth

1. User clicks “Login with Google” on https://myapp.com.
2. Google authenticates the user.
3. Google redirects the user to the registered redirect URI:

   https://myapp.com/auth/callback?code=AUTH_CODE

4. The app exchanges the AUTH_CODE for an access token.

Security Best Practices

• Allow only exact, pre‑registered redirect URIs (no wildcards).
• Use HTTPS to prevent token leakage.
• Do not allow user‑controlled parameters to alter the redirect target.

Safe Redirect Flow Diagram

[User] --> [Trusted App] --> [Auth Server]
[Auth Server] --> Redirect to Pre-Registered URI --> [Trusted App]
  

---

2. Open Redirect Attacks

An Open Redirect occurs when an application takes a user‑supplied URL and redirects to it without proper validation. Attackers can exploit this to send users to malicious sites while making the link appear to come from a trusted domain.

How It Works

1. Legitimate site has a redirect endpoint:

   https://trusted.com/redirect?url=https://trusted.com/home

2. Attacker changes the parameter:

   https://trusted.com/redirect?url=https://evil.com/login

3. Victim clicks the link, sees the trusted domain, and is redirected to the attacker’s site.
4. Attacker can phish credentials, deliver malware, or steal tokens.

Example in Login Flows

Many apps use a returnUrl or next parameter to send users back after login:

https://trusted.com/login?returnUrl=/dashboard

If not validated, an attacker could set:

https://trusted.com/login?returnUrl=https://evil.com/fake-login

Risks

• Phishing: Users trust the initial domain in the link.
• Token Theft: In OAuth, can steal authorization codes or tokens.
• Privilege Escalation: May bypass access controls if redirects lead to privileged pages.

Prevention Strategies

• Whitelist redirects to known, trusted URLs.
• Use relative paths (/path) instead of full URLs for internal redirects.
• Validate hostnames to ensure they match your domain.
• In ASP.NET Core, use Url.IsLocalUrl() before redirecting.
• Avoid user‑controlled redirects where possible.

Open Redirect Exploit Flow Diagram

[User] --> Clicks trusted.com/redirect?url=evil.com
[Trusted App] --> Redirects without validation --> [Evil Site]
[Evil Site] --> Phishes credentials / steals tokens
  

---

3. Key Differences

Aspect	Redirect URI	Open Redirect Attack
Purpose	Legitimate OAuth/OIDC callback endpoint	Exploit to send users to malicious sites
Control	Pre‑registered, exact match	User‑controlled parameter
Risk	Token leakage if misconfigured	Phishing, token theft, malware delivery
Prevention	Strict registration & HTTPS	Whitelisting, validation, relative paths