What Is an Open Redirect Attack?
Web applications frequently redirect users to a login page when they access resources that require authentication. This redirection process usually includes a returnUrl
QueryString parameter. Once the user is authenticated, they are redirected to the originally requested URL.
Because the destination URL is specified in the query string of the request, an attacker could tamper with it. A tampered query string could then allow the site to redirect the user to any external, malicious website, which is an open redirect attack.
Here’s a common example:
An attacker wants access to a user's credentials or sensitive information. The attacker convinces the user to click a link to the user’s login page with a returnUrl
QueryString value added to the URL, such as:
http://www.mybank.com/Account/Login?returnUrl=/Home/About.
The user clicks a malicious link to:
http://www.mybank.com/Account/LogOn?returnUrl=http://www.mybank1.com/Account/Login.
The user logs in successfully and is then redirected by the correct site to:
http://www.mybank1.com/Account/Login?returnUrl=https://www.mybank.com/
This malicious site looks exactly like a real one, but the return URL goes back to the original site.
When the user sees the login page again, they believe they have made an error, such as mistyping the password. They re-enter their login credentials, which the malicious site records before redirecting them back to the real site. The user has no idea any redirect has happened.
Does this sound familiar? It should. It’s precisely what happened in the example mentioned at the beginning of the XSS chapter. Open redirects are often used in conjunction with XSS or XSRF/CSRF attacks. In the example, an XSS attack occurred in which an attacker injected JavaScript code into a posted blog comment. The code modified the login button on the page, adding a returnURL parameter to the button. It then took the user to a duplicate login page running on the attacker’s server, where the victim unwittingly provided the attacker with their login credentials for the site.
These types of attacks can be challenging for users to spot, but they are easy for developers to prevent.
Prevent Open Redirect Attacks
As a general rule, treat all user-provided data as untrustworthy. Doing so not only can prevent open redirect attacks, but all attacks discussed in this course, as they all involve the introduction of malicious code or data via user input. If your application redirects users based on the URL content, ensure such redirects are only done locally within your app or to a known URL, never to a URL provided in the query string.
LocalRedirect
Use the LocalRedirect helper method from the base controller class:
public IActionResult SomeAction(string redirectUrl)
{
return LocalRedirect(redirectUrl);
}
LocalRedirect
will throw an exception if a non-local URL is specified. Otherwise, it behaves just like the Redirect
method.
IsLocalUrl
Use the IsLocalUrl
method to test URLs before redirecting:
private IActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction(nameof(HomeController.Index), "Home");
}
}
The IsLocalUrl
method protects users from being inadvertently redirected to a malicious site. You can log the details of the provided URL when a non-local URL is supplied in a situation where you expected a local URL. Logging redirect URLs can help in diagnosing redirection attacks.
Let’s Recap!
At this point, you have learned that:
Open redirect attacks happen when an attacker tampers with a query string, causing the user to be redirected to an external, malicious site.
Open redirect attacks often occur in conjunction with, or as a result of, an XSS or XSRF attack.
You can prevent such attacks by ensuring that redirects in your applications are only done locally within your app or to a known URL, never to a URL provided in a query string.
Now that we’ve discussed the various ways in which malicious code can be injected into a site and how to prevent it, let’s talk about an even more dangerous type of attack: SQL injection.