A parameter. A URL. A redirect.
But sometimes, the simplest vulnerabilities open the biggest doors. Especially when they sit inside a real authentication flow.
This is the story of how I discovered an Open Redirection vulnerability in the DTDC OPS Dashboard — hiding quietly in an OIDC authentication endpoint — and how it could have turned a trusted company URL into a weapon for phishing, malware distribution, or brand impersonation.
🕵️♂️ The Curious Parameter Inside an Auth Endpoint
I was testing the OPS Dashboard application when I found an endpoint that immediately caught my attention:
/oidcAuthAnything involving authentication — especially OIDC — instantly goes into my "look-closer" bucket.
Then I saw the parameter:
auth_url=Hmm.
Redirect parameters are harmless… until they're not.
So I tested it:
https://redacted.dtdc.in/oidcAuth?auth_url=https://evil.com/The server's response?
A clean 302 redirect to the malicious site.
No validation. No warning. No allowlist. Just a redirect — signed by DTDC's own domain.
This wasn't just a code quirk. It was a phishing dream.
⚡ Why Open Redirects Matter More Than People Think
A lot of developers underestimate open redirects.
"It's just a redirect. It doesn't leak data."
But here's why they're dangerous — especially inside authentication flows:
🔹 1. Perfect Phishing Setup
Attackers can craft URLs that start with a legitimate domain:
https://redacted.dtdc.in/oidcAuth?auth_url=https://fake-dtdc-login.comUsers click it. They land on a fake login page. They trust it because the URL began with the real DTDC domain.
Credential theft becomes effortless.
🔹 2. Malware Distribution
Redirect users to:
- drive-by download pages
- exploit kits
- malicious APKs
- fake updates
It only takes one careless click.
🔹 3. SEO Spam & Reputation Abuse
Attackers often use high-trust domains as redirectors to boost shady websites.
Your domain becomes a spam tool.
🔹 4. Social Engineering Chains
Support agents, employees, or users may be tricked into opening the redirect, believing it's part of the authentication flow.
Open Redirects are often the first step in larger attack chains.
🧪 The Proof of Concept
A simple visit to:
https://ops-dashboard.dtdc.in/oidcAuth?auth_url=https://evil.me/returned:
HTTP/1.1 302 Found
Location: https://evil.me/&The application blindly appended the attacker's URL and redirected.
Later, I shared an additional working payload with the team:
https://redacted.dtdc.in/oidcAuth?auth_url=https://sms.upastithi.in/This also redirected successfully — confirming the vulnerability.
No sanitization. No filtering. No allowlist.
Just trust — where trust should never exist.
🎯 Reporting the Issue
I documented:
- the vulnerable endpoint
- working payloads
- real-world attack scenarios
- HTTP request/response
- potential chain risks
The vulnerability was acknowledged and moved to internal review.
It's always satisfying when a team takes a report seriously — especially for bugs that seem simple but carry real-world impact.
🛠️ How It Should Be Fixed (My Recommendations)
🔒 1. Implement a Strict Allowlist
Redirect only to domains explicitly approved:
redacted.in Reject everything else.
🚫 2. Avoid Full URLs in Redirects
Use safe relative paths:
/dashboard
/home
/profileRemove external URLs entirely.
🔑 3. Token-Based Redirects
Issue one-time hashes for approved redirect targets:
/oidcAuth?redirect_token=RANDOM_HASHServer validates token → redirects safely.
⚠️ 4. Add an External Redirect Warning Page
If a redirect leaves the DTDC domain, show:
"You are now leaving DTDC's website."
🛡️ 5. Strengthen Security Headers
Add:
Referrer-Policy: strict-origin-when-cross-originto prevent leakage during redirects.
These are simple measures — but they eliminate a whole class of phishing risks.
💡 Final Thoughts: Simple Bugs, Serious Risks
This vulnerability reminded me — again — that not all impactful bugs require advanced exploitation.
Sometimes the danger lies in trust.
When a trusted domain redirects users anywhere an attacker wants, the domain itself becomes the attack.
In the world of bug hunting, this is a powerful lesson:
Small parameters can create big problems. Small oversights can expose large systems. And small bugs can save people from big phishing campaigns.
On to the next hunt. 🐞🔍