GET Based
GET-Based Open Redirect
Overview of the Vulnerability
Open redirects enable an attacker to manipulate a user by redirecting them to a malicious site. A GET-based open redirect was identified which can impact users' ability to trust legitimate web pages. An attacker can send a phishing email that contains a link with a legitimate business name in the URL and the user will be redirected from the legitimate web server to any external domain. Users are less likely to notice subsequent redirects to different domains when an authentic URL with a valid SSL certificate can be used within the phishing link.
This type of attack is also a precursor for more serious vulnerabilities such as Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), Cross-Site Request Forgery (CSRF), or successful phishing attempts where an attacker can harvest users' credentials or gain users' OAuth access by relaying them through an Open Redirection, to a server they control (and can see the inbound requests from).
Business Impact
GET-based open redirects can result in reputational damage for the business as customers' trust is negatively impacted by an attacker sending them to a phishing site to extract login credentials, or coercing them to send a financial transaction.
Steps to Reproduce
Using a browser, navigate to: {{URL}}
Copy and modify the URI so that the URL redirects to
url=<http://www.bugcrowd.com/Submit this in a new browser window and you should be redirected to the Bugcrowd website.
Proof of Concept (PoC)
The screenshot below demonstrates the GET-based open redirect executing:
{{screenshot}}
Guidance
Provide a 1-2 sentence description - see CVE Project's Key Details Phrasing Guide for tips.
Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed triage time and result in faster rewards.
For a GET-based open redirect vulnerability, please provide instructions on how to navigate the target to the vulnerable request and execute the redirect. Evidence can be screenshots or the raw method-path-protocol from a HTTP request and the subsequent 200 response.
Do not redirect to an unapproved third party website. Successfully redirecting to https://bugcrowd.com/ is a sufficient proof of concept.
Recommendations(s)
The application should avoid incorporating user-controlled data within redirect targets. This can be achieved by removing the redirect function and replacing it with direct links to the appropriate URL. Additionally, a server-side allow list of trusted URLs can be used as permitted redirect URLs that the website can link to.
It is recommended best practice that all redirects go through an intermediate disclaimer page that notifies the user that they are navigating away from the website.
For more information, see Open Web Application Security Project (OWASP): https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
Last updated