A visitor to a website follows a link, only to be redirected to a completely different site. It could be unwanted advertising, a malware downloader, or a fake version of the legitimate site. This trick is one of the most common ways to subvert Web pages and hijack traffic.

It doesn't always affect every user. The redirection may single out people in one country or visitors who clicked on a search engine result. However it works, it's serious trouble for the owner of the site as well as the visitor. If malicious redirects infiltrate a website, it's important to get rid of them. It's equally important to find and fix the vulnerabilities that allowed them and improve website protection.

There are two kinds of scenarios where browsers get improperly redirected. In one type, it's obvious that the content isn't what the visitor was looking for. It's likely to be advertising for pornography and scam offers or a malware download site. The other case is that the redirected site seems to belong to the intended site. It's hard to say which is worse.

Visitors may be tricked and lose money or suffer malware attacks. They may recognize what's happened and close the page. In any event, they won't like it. They won't trust the site they were trying to visit, and many of them won't come back. The result is a loss of reputation and business opportunities. Search engines will downgrade the site's rank or exclude it entirely.

All we knew at this point was that traffic to the site was being redirected. Something less obvious than a website infection was going on. The site was running on a Windows server that belonged to a hosting company, running Active Server Pages on IIS. Could the source of the trouble be in the hosting infrastructure rather than our client's Web directory? If so, the problem was much bigger than just one site.

If an intruder can get unauthorized JavaScript into your pages, it can redirect to any other URL. It's the most versatile way to subvert a page since it allows detailed control.

A common way to accomplish it is with "malvertising." Advertisements inserted into a page at load time may look legitimate, but they can include JavaScript which redirects the page. Their reach has been huge. A single campaign, called Zirconium, is said to have reached 62% of all monetized websites.

JavaScript can be obfuscated, making it hard for human readers and anti-malware software to spot the redirect. It can place conditions on who gets redirected. If every visit to a page results in a redirect, it will be caught quickly. The JavaScript might redirect just visitors who clicked on a search engine result. They aren't regular users and are more easily fooled. It might affect only certain IP addresses. Administrators won't see a problem when they try it out themselves.

Another approach is to redirect the page at the HTTP level. There are two ways to do this, which are functionally the same: the meta refresh tag and the HTTP refresh header. The one with the meta tag looks like this:

<meta http-equiv=“refresh” content=“5;url=https://evil_web_site.net">

The equivalent HTTP header is like this:

Refresh: 5;url=https://evil_web_site.net

They both direct the browser to wait 5 seconds and then redirect to the specified URL. This has legitimate uses. It can take the user from a splash page to a content page, or it can force periodic refreshes of a page with constantly updated content. The problem comes when an intruder can inject the tag or header.

Altering the files on a site is one way to do this. Another is to set up a man-in-the-middle (MITM) attack which adds the unauthorized redirect header.

This approach doesn't have the subtlety of JavaScript redirection, but it doesn't depend on the continued inclusion of outside content, so it can be highly persistent.

Some sites have pages that are designed to redirect to another page. They're intended for internal redirection, perhaps based on the user's device type or language preferences. The naive way to do it is to pass the target address as a URL parameter. This lets an outsider stick on any address. The page may check the Referer header in an effort to stop outside use, but it can be spoofed.

Why would anyone do this rather than just send people directly to a malicious URL? It looks more legitimate. A phishing email message can include a link that seems to go to a trustworthy website but has a redirect parameter.

Plugins that provide redirection capacity can have security holes. The Simple 301 Redirects Addon Bulk Uploader plugin for WordPress had a vulnerability before version 1.2.5, and any users with old versions should upgrade.
Here is an injected malicious configuration redirecting every homepage visitor to a third party URL:

The best way to avoid this risk is not to have open redirect pages. If you want a page to redirect, let it accept a parameter that your server puts through an internal lookup. That will send users off only to approved pages.

Being careful about the sources of third-party content will reduce the chances of malicious redirects. Using HTTPS for all pages will prevent MITM attacks that redirect pages. Beyond that, the remedies are website security measures that will prevent and disable malware in general.

The administrative account should have a strong password that is well protected. Accounts for contributing and editing content should have only the privileges needed to do the job. Software should be regularly updated with security patches, and the network firewall should limit access to services.

For strong website protection, sign up for Quttera ThreatSign. It scans for malware and removes it, as well as providing a web application firewall and other tools for website security. With ThreatSign protecting your site, your visitors will see the pages they should see and have a safe experience for as long as they visit.