Testing for unvalidated redirects and forwards

What are unvalidated redirects and forwards?

The Open Web Application Security Project (OWASP) top ten Web application vulnerabilities list includes an attack termed “Unvalidated Redirects and Forwards.

As websites due to various functionality is required to redirect to new URLs. These redirects and forwards are a benefit to the user because they take user to an improved functionality without requiring user input.

But at the same time they can serve as an attack vector for malicious users. When a redirects and forwards are programmatically built based on user input, if user input is not handled correctly then it can turn into a malicious attack

For example

http://www.mysite.com/redirect.php?r=http://m.mysite.com/myapp

In this example, the request is redirected via redirect.php?r=functionality. If the validation checks are there then it is ok and attacker could not modify the URL.

Look at code below for redirect.php, it is clear that programmer has insecurely applied it, now whatever input will be supplied by a user for the value of ‘r’, and then user can redirect the URL to that site.

	// redirect.php $destination = $_GET['r']; header ('Location: ' . $destination);

How can this be used for malicious purposes?

Hackers can easily a redirect a user to a malicious site. By sending a user of the Web application link like this:

http://www.mysite.com/redirect.php?r=http://evil.com

Testing for un-validated redirects

As a web application tester, you have a number of responsibilities. Out of them testing for unvalidated redirects and forwards in your application is one of them. There are following ways to carry out test for finding such issues:

website spidering or crawling
Manual code scanning
Manual testing

Any intermediate proxy tools (Burp) etc. which comes with this kind of spidering tool do a great job for detecting unvalidated redirects.

So where we have to keep our focus?

Any request which results in a “3xx” HTTP response code is generally a redirection. Once the automated spider is complete, it’s a simple task to filter out all requests which resulted in a 3xx HTTP response—now you will be in better position to know where to focus your manual testing efforts.

The manual discovery process is obviously more intensive. Manually reviewing source code generally requires a working knowledge of the language– not one that is advisable for every tester. The work in this case become cumbersome because Ajax-enabled sites often execute requests behind the scenes

Discovering vulnerabilities

Now you have understand where your application performs redirection, it’s a simple task to detect redirection vulnerabilities. Test redirection with GET and POST parameters in captured request above. If the redirect attempts are successful, then you hit a vulnerability.

Let us move on to exercise to demonstrate the unvalidated redirect by decoding hashing.

Excercise link:http://pentesteracademylab.appspot.com/lab/webapp/or/4

solution:-