An unvalidated redirect or a forward is when your website for whatever reason redirects a user to a different webpage. There is a risk is that a hacker somehow takes control of where the redirection takes the user. If the redirect is unvalidated (i.e. you don’t check where it is going) then there is a danger they could, for instance, be moved to spoof site that looks very like the original site. The user may be presented with a login page on the spoof site, they may enter their user name and password and the account is then stolen.
How does a hacker gain control? The obvious approach targeted by hackers was the redirection logic after the user logs in. The pattern works like this, a user tries to access a secured page on your site, however is not yet logged in, therefore they get bounced to the login page. On completion of login the user is moved back to the original secured page they tried to access.
Code like below is pretty common and as described above it allows a user to login and then redirects them to the page they originally accessed that was secured.
public ActionResult LogOn(LoginModel model, string returnUrl)
///log user in
///if all ok redirect to original page
return RedirectToAction(“Index”, “Home”);
The weakness is that if the returnUrl is not validated then a user can be emailed a link in an email such as
The result is that the user logs in and then finds themselves moved to the spoof site which maybe styled to look the same as the original site. Perhaps they are asked to renter their login details and then passed back to the original site. The user has leaked their username and password without realising it. Later versions of asp.net automatically prevent this sort of problem. This is called an open redirection attack.
In earlier versions of asp.net the returnurl needs to be manually whitelisted or alternatively remove all risk and always return the user to their home page as oppose to the return url.
For later versions of asp.net this hole is plugged and the risk is an attack from different angles. Code like below is high risk in that it reads a url from a query string and then redirects to it
String destinationUrl = QueryString[“destinationUrl”];
again the destinationUrl needs whitelisted or the code removed and rethought. It would be better if the destinationUrl was represented by an id or code and then translated to the actual url. If the url is moving the user off your site then a page explaining that the user is about to leave site can be useful.
Another area of risk is anywhere a user can enter a url that links back to a different site. Or can they enter a comment that accepts html – such as “for further information click here”. Or simply adding a comment “I had a problem I found the solution here – http://www.dangeroussite.com”. This is another feature that can easily be perverted.
You need to think carefully about what information users can post that other users will see. Should they be able to post comment others can see? Although a customer may ask for this feature have they considered the risk? If a user can add comments should the comments allow html? Should the comments be approved before they are displayed? This decision like so many is a balance between features, risk and cost.