Lists are used to avoid input validation errors during application development. These lists are divided into two main groups:

• Blacklist: A group of strings that are blocked by the application, in order to avoid being entered by the user. For example, they can be used to avoid the most common testing strings, such as '1, 1==1--, or <script>alert(1)</script>.
• Whitelist: The application allows data that follows a certain structure. For example, consider an application that has a registration form, and it is waiting for the user to enter an email address. A developer blocks an invalid email address using a blacklist. This is done by creating regular expressions in the application to accept any email address. But this value needs to have the usual email address structure, which means, it needs to have an @ character, a user, domain, and so on.

Mixing blacklists and whitelists works very well for most input-validation scenarios, but in open redirects, it is not so easy. Let's see the recommendation by OWASP to have safe redirections.

• Java:

response.sendRedirect("http://www.mysite.com"); 

• PHP:

<?php 
/* Redirect browser */ 
header("Location: http://www.mysite.com/"); 
?> 

• .NET:

Response.Redirect("~/folder/Login.aspx") 

• RoR:

redirect_to login_path 

They all have one thing in common: there are no parameters entered in the redirects, so it is not possible to interact between applications. So, despite it being an easy vulnerability, the remediation is not easy. We list some recommendations to avoid open redirects, when you report this type of vulnerability in a bug bounty program, usually it is discarded, because it is not considered relevant. I recommend putting some extra effort into the report to show the importance and the impact of open redirects.

• Validate directly in the code by using the value that is entered for the redirection. Sometimes, it is not difficult, for example in the cases when a new URL is constructed using the value entered.
• Avoid the use of JavaScript to launch redirects. Not only could this be vulnerable to open redirects, it could also be vulnerable to cross-site scripting (XSS) attacks.
• Use a whitelist for safe destinations.
• Use a blacklist to block unsafe destinations.
• Configure the robot.txt file to avoid mapping from searchers.