Bug Breakdown: Open Redirects
1 min read

Bug Breakdown: Open Redirects

I'm going to start documenting my notes on different bug types in the form of blog posts. This is the first in a series of many. These blog posts will be updated over time as I learn more and expand my toolset and knowledge on specific bugs.

An http parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.

Example: https://yahoo.com?r=https://google.com

If the r parameter is not validated by yahoo.com, the web server will return a HTTP/302 response redirecting us to google.com

Impact

  • Allow malicious attackers to redirect users unknowingly to a malicious website.
  • Abuse of trust.
  • OAuth token theft.

Automated Detection

  • Scan for all 302 responses from the server
  • Within those responses, enumerate for and isolate parameters containing URLs/paths/pages
  • FUZZ the URL parameters and look for successful modification to 302 response with the data given. Fuzzing can not only be done using full external URL redirects but with other types of URIs.

Tooling

Example Bounty Reports

Resources