domains / families / security / hunt-open-redirect

hunt-open-redirect

combined

Hunt Open Redirect Hunt Open Redirect — all types including low-impact, chained to OAuth token theft → ATO, phishing chains. URL parameter manipulation, JavaScript redirect, meta refresh, header injection. Use when hunting redirect bugs or building ATO chains.

When to use

• You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
• You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
• Use when the target has any redirect parameter — ?url=, ?next=, ?redirect=, ?return=, ?redirect_uri=, or similar — on login/logout flows, OAuth authorization endpoints, language switchers, payment redirects, or any parameter that controls…

When not to use

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.

Skill page

Conflict

The two copies share the same core procedure (discover redirect parameters, basic curl test, bypass payloads, OAuth chain test) and the same bypass table. However, the uphiago copy adds a 'When to Use' section, a 'Common Root Causes' list, and 'Real Examples' that the sickn33 copy lacks. Conversely, the sickn33 copy adds a mandatory authorization confirmation gate, a 'Phase 3b' for DOM-based open redirects, a 'Phase 5' for SSRF escalation, and an 'Automation' section with specific tools (openredirex, nuclei) that the uphiago copy lacks. Crowning one would hide these distinct procedural steps and constraints.