Testing and Bypassing Technique for Open Redirection Vulnerability
Open redirection vulnerability
Hey Guys welcome to the blog so today we are going to discuss about open redirection vulnerability which has a low impact on bug bounty but you can also make this a high impact when you combine this with SSRF vulnerability and we can also see the testing technique for open redirection vulnerability
What is Open redirection?
The website uses the URL parameter to redirect the user to a specific location without any user action it is good functionality to use but it can also lead to open redirection when the validator does not sanitize properly
For example, let’s assume there is a login page right here in this scenario where a login page redirects users to a profile page or an application page after a successful login. If the redirection process does not adequately validate or sanitize the provided URL, it can be exploited by an attacker. By modifying the link or URL parameter, the attacker can redirect users to a malicious website or a phishing page instead of the intended destination
https://viticm.com?redir=https://attacker.comNow you will get a better understanding of open redirection right so next let’s move to test for open redirection
Testing for Open redirection
1. Search for the redirection parameter in your target
https://viticm.com?redirection=https://attacker.com
https://viticm.com?redir=https://attacker.com
https://viticm.com?redir=/dashboardNote: In the target application, the parameter controlling the redirection may not have a straightforward name like “redirection=”. Instead, it could vary, such as using different parameter names like “u=”, “r=”, or others. Keep this in mind while testing for Open Redirection vulnerabilities and make sure to identify the specific parameter responsible for controlling the redirect behavior in the application you are testing.
Absolute parameter: URL: https://viticm.com?redirection=https://attacker.com In this case, the redirection the parameter is an absolute URL pointing to https://attacker.com. If the application blindly uses this parameter value for redirection without proper validation, it could result in an Open Redirection vulnerability. An attacker could manipulate the URL to redirect users to a malicious website.
Relative parameter: URL: https://viticm.com?redir=/dashboard Here, the redir parameter appears to be a relative path, such as /dashboard. If the application incorporates this parameter directly into the redirection without appropriate validation, it could potentially allow an attacker to manipulate the redirect location. However, unlike absolute parameters, the risk here is limited to within the same domain. So, an attacker couldn't redirect users to an external website but could still manipulate the redirection within the same domain.
And take note to redirection status code 3xx using burp
2. Search for parameters using google dork and Oralyzer
Using google dork you can able to find the redirection parameter
site:example.com
#%3D --> = (Url encode)
inurl:%3Dhttp site:example.com
#%2f --> / (Url encode)
inurl:%3D%2F site:example.com
Common redirection queries
inurl:redir site:example.com
inurl:redirect site:example.com
inurl:redirecturi site:example.com
inurl:redirect_uri site:example.com
inurl:redirecturl site:example.com
inurl:redirect_uri site:example.com
inurl:return site:example.com
inurl:returnurl site:example.com
inurl:relaystate site:example.com
inurl:forward site:example.com
inurl:forwardurl site:example.com
inurl:forward_url site:example.com
inurl:url site:example.com
inurl:uri site:example.com
inurl:dest site:example.com
inurl:destination site:example.com
inurl:next site:example.comGithub Link for that tool: https://github.com/r0075h3ll/Oralyzer
3. Referer-Based open redirection
Setup the own domain and embed this html form and replace the link with target and reload that page
<html>
<a href="https://example.com/login">Click on this link!</a>
</html>click the link and login and next logout if the application blindly trusts the referer header means it redirects back to the attacker’s URL
It is referer-based open redirection
Bypassing technique for Open redirection
URL validation is extremely difficult when we protect from the open redirection vulnerability
Use the browser auto-correct Bypass
Modern browsers automatically correct the URL when you enter it mistakenly in the browser
https:hacker.com
https;hacker.com
https:\/\/hacker.com
https:/\/\hacker.comThis payload can help you bypass the blocklist
Because most the validator block the absolute URL in the blocklist so you can able to bypass with above payload
Double Encoding and triple Encoding
First, try double or triple encoding the special because the validator usually does not double decode that encoding but the browser does the double decoding means you could exploit that vulnerability
https://example.com%2f@hacker.com
And here is the URL with a double-URL-encoded slash:
https://example.com%252f@hacker.com
Finally, here is the URL with a triple-URL-encoded slash:
https://example.com%25252f@hacker.com
https://hack.com%252f@hacker.comCombine this technique with SSRF vulnerability
https://evilox.medium.com/exposing-ssrf-vvulnerability-309ec90b976f
