Web sites are constantly changing. Pages get published but later they are superseded by new ones that contain updated information. However many people will have the old page bookmarked, or it will be returned in search results. In situations like these web site owners will often insert a redirect or forwarder into the old page so that anyone visiting is automatically taken to the new page. Another common use for redirects is to take a user to a page after they have been authenticated via a log on form. In the case of the log on redirect the page to go to will be in the URL of the page or in the authentication form itself. Both of these locations are accessible to the user, or attackers, and therefore a vulnerability. Web sites that respond to redirect and forward URLs are prime targets for attackers. If a valid user of a site can be tricked into clicking on a URL that looks legitimate, but that has a redirect to an attackers site, then various other attack types are made possible. Allowing unverified redirects and forwards opens the door to many other security vulnerabilities that have been discussed in previous articles in the OWASP Series.
Some security authorities see unvalidated redirects and forwards as a very low risk. Google, for example, takes the position that a few well designed redirects that are secure and monitored provide benefits that outweigh the risks. It’ll be interesting to see if this vulnerability is in the new OWASP Top 10 list (due within the next 18 months).
How to protect against Unvalidated Redirects and Forwards
The simplest way to protect against this type of attack is to not use redirects or forwarders on your site at all. Don’t have any code that responds to redirection requests. Do a global search on your web application code base to see if there are any functions that are allowing redirects that you don’t know about. Of course in a complex website this may not be a feasible approach. If you do have to use redirects and forwarders there are a few things you can do to protect against unverified URLs being used.
Don’t allow users to send unverified URLs as redirects. A good way to do this is to maintain a whitelist of redirects that are allowed, and then compare all redirect requests to the whitelist and reject them if there is no match. Alternatively, use codes for internal site redirects rather than page fragments. For example redirect?code=akhujfgoaiudfgh7rytp2890rhgu rather than redirect?URL=admin.php, then use a server lookup to map the code to the page. Make these codes random and one time use so that you are not opening up possible Insecure Direct Object Reference vulnerabilities! Common page names should always be mapped to a valid secure page; for example websitename/home should map to websitename/home.php.
It’s also worth considering that all redirects or forward requests that will link to an external site prompt the users to inform them that this is happening. They can then be given the option to visit the external site or not. If they choose not to then they should be taken back to the page they were browsing.