OWASP Vulnerability 10 - Unvalidated Redirects and Forwards

This article was originally published on the Clearent Developer blog.

In a previous post, I provided a high-level overview of the OWASP (Open Web Application Security Project) Top 10 web security vulnerabilities.  Ensuring that these security vulnerabilities don’t exist in a web application is a critical part of being PCI compliant.  This is the first of ten posts going into more detail on each of the vulnerabilities.

Number 10 on the list is Unvalidated Redirects and Forwards.  Quite often, modern web applications use HTTP redirects and forwards to control the flow of their application.  A vulnerable system can be used to redirect users to malicious sites or to download malicious code.  A system may be vulnerable if it uses query string parameters passed in the URL to redirect their application.  Here is an example of a URL that is vulnerable:

https://www.example.com/pagewithredirect.asp?link=someothersite.com

A simple, brute-force approach to preventing this vulnerability is to use a white list for redirects and forwards.  This approach codifies an “approved” list of valid URLs that can be used in an HTTP redirect or forward.  The application would verify any URL against this list.  If an application must use query string parameters to pass URLs for redirection, it is recommended to use a white list for the permitted values in that parameter.  The application should ensure that the value passed in is in the white list before actually issuing the redirect.

A similar approach to a white list is to map the allowed URLs that can be accepted as a parameter.  For instance, the browser may see

https://www.example.com/pagewithredirect.asp?link=desired_site

When the page pagewithredirect.asp parses the link parameter, it would then look up “desired_site” from a mapping and use the URL associated with the “desired_site” key.

Most modern web applications are built on top of an application framework such as MVC in a .NET application or Spring in a Java application.  These frameworks utilize a routing system that dictates how HTTP redirects are issued.  These frameworks do not use user-entered data to change the browser navigation.  They use application-defined paths that are traversed by the routing system.  In this way, applications built on top of these frameworks prevent malicious users from causing an application to route a user to a malicious site.

As we have seen, preventing Unvalidated Redirects and Forwards is fairly straightforward.  In future posts, we will do a deeper dive on the other security vulnerabilities.