Arbitrary URL Redirection Attack often is popularly known as an Open Redirection attack, which is a common web vulnerability that allows an attacker to redirect the victim user to an attacker-controlled domain. This attack can leveraged to steal sensitive information such as tokens, perform social engineering, and other attacks.

The Arbitrary URL Redirection Attack mostly happens at the endpoint where the application accepts user-supplied URL and redirects it upon the execution of the vulnerable function. Some of the common parameters are ?return=,?returnURI=,?forwardedTo=, ?redirect=, ?redirectURI=, ?url=,?forward= and other such parameter that seems to load or redirect user to another endpoint.

Hi Fellow Hackers and Bug Bounty Hunters, In this article, I will be sharing about one of my recent findings where I was able to perform an Arbitrary URL Redirection Attack by evading the filters.

Modern frameworks by default implement security checks to validate and avoid Open Redirect Attacks. Often various filters such as validating if a third party URL or IP is used, validating if HTTPS:// protocol is used and if found, the application block the redirection from happening.

Recently, I encountered a similar situation while testing a private application say target.com. While checking for the various vulnerabilities from my application security checklist, I was looking for URL Redirection next.

The general approach I follow to test this attack is the following:

1. Log in to the application and navigate to any authenticated page say My Profile.
2. The URL generally looks like this: https://www.target.com/my-profile/
3. Now, log out from the application, and often some application throws a redirection parameter which redirects to the /my-profile page.
4. The URL looks like the following: https://www.target.com/login?forward=/my-profile
5. Now, in this case, the forward parameter is a potential attack vector to test for the Arbitrary URL Redirection attack.

1. Use the parameter enumeration tool such as ParamSpider & Arjun
2. Test the suspicious parameter against the Arbitrary URL Redirection attack.

1. Run gau & waybackurls on the target application and save them to a file.
2. Run Open Redirection GF Patterns on the saved file from step-1 and store the output to another file.
3. These URLs are suspected and potential endpoints for the Arbitrary URL Redirection attack.

In this case, for the application I was testing, I used Approach — 1 and I found the following potential endpoint for Open Redirection:

https://www.target.com/login?forward=/account/address

However, the forward parameter was validating if a URL is supplied and was blocking the redirection from happening. After further investigation I came to know that:

• The application is filtering HTTPS protocol.
• The application is filtering the Host & IP Address.

However, the application was allowing the use of the HTTP protocol. After thinking for a while, I used the following payload as a bypass:

http://2899905732 : 2899905732 is the Integer IP representation of google.com’s IP: 142.250.64.100

The final payload looked like the following:

https://www.target.com/login?forward=http://2899905732

I navigated to the above URL and logged in with valid credentials. Upon the login, the application redirected to google.com resulting in a successful Arbitrary URL Redirection Attack.

• Try all possible approaches to look at every single vulnerability.
• If something is not working or is blocked, try to look for possible alternatives.
• Try all possible ways to evade the filters to get success.
• Learn along the way and apply your knowledge everywhere.