Over the past few years, the programmatic ecosystem has been flooded with a type of malware that takes over a user's browser and directs them to those infuriating "You've won!" pop-ups.

Ad Lightning released research early this summer detailing how the number of distinct final redirect URLs jumped roughly 30 percentage points from the end of 2017 to March of 2018 and how the number of redirect paths (all the URLs between the link and the landing page) has increased by 59% from the first half of 2017 to the first half of 2018.

These ads almost always result in a flurry of user complaints, frustrated editors, and countless ad ops headaches. Each new rash of malware enters the ecosystem, wreaks havoc and then disappears.

In the AdOps community, this specific type of malware is often referred to as a "redirect" due to the redirection of a user's browser from the current page to another unwanted page.

On the surface, we know they are annoying, but what's technically happening behind the scenes? And more importantly, what can be done to stop them?

Redirects & Forced Redirects

A redirect is a script or an HTML element —or a combination of the two — that causes the main browser window to navigate to a different URL. Many websites are engineered to rely on the ability to "direct" a user somewhere on their site.

It's common practice and only becomes an issue when bad actors exploit this functionality. The result is a forced redirect. A forced redirect is caused without any user action, or an action that wasn’t intended to cause a navigation (like a scroll).

Top window access is a huge liability for Publishers

The tactics that malicious actors use range in sophistication in how they are deployed and executed. No matter which method is selected, in all cases, the ad needs to have access to the top (main) window. Without that, the redirect would not be able to escape the iframe window.

Before we get into the various types of redirects, let's review top window access:

• What exactly is the top window? All content on a web page is served into something called a “window.” There is the main window, also known as the top window, as well as frame windows, which belong to iframe objects. Each window has an origin -- a domain -- that the content is served from. A window from one domain origin CANNOT access a window from a different origin (domain). When two windows are from different frames, this is called “cross-domain”. For example: if your website is www.publisher.com and you have an iframe that is from www.example.com, your website cannot access the iframe, and the iframe cannot access your website directly, and can only communicate via messaging.

• What & why are ads communicating with the page? When ads are served as part of a different domain, they may want to resize themselves or record the URL they’re served to for tracking purposes. The correct way to do this is by implementing message handlers that give the ads what they want. Historically, however, the path of least resistance has been to give ads access to the top window instead of implementing the the additional code.

• Why does this lead to issues? When the ads have the same domain as the website, and therefore access to the top window, the ads get free reign to do as they please on the site. They can redirect, modify the site, set cookies, and perform all sorts of other malicious behavior—including redirects.

5 commons ways bad actors can force a redirect

There are 5 common ways that fraudsters exploit top window to forcefully redirect a page:

1) Location change: Generally a sophomoric approach, this is mostly seen in ads that just take users to a store. There are also legitimate ads that try to use this functionality after clicks, but this implementation is strongly discouraged. Bad actors will often invoke this function by first gaining access to the top window, and then executing it from that context using an “eval” statement or modifying an element’s event handler. This is different because to the browser, it appears that the top window is performing the action, so it allows it to occur.

2) Meta refresh: This type of redirect relies on the <meta> tag being inserted into the head of the top window. The ad will contain something like: <meta http-equiv="refresh" content="0;URL='http://www.example.com'" />

This tag needs to be written or inserted to the top window in order for a forced-redirect to occur, otherwise it would be contained within the iframe window. This functionality was originally implemented so developers could create a web-page that acts as a server-side redirect, but via HTML. Unfortunately, malicious players are using this functionality to forcibly redirect users to their domains.

3) Window open: A “Window Open” needs one of two things to be true: either the ad frame is not sandboxed or the ad has top window access. This redirect function causes the browser to open a window, but target the “top.”. This causes the browser to open a window, but target the “top.”. The target can be changed to “_blank”, which opens a new tab, and is usually something that popup blocking handles. The big difference between those two is whether or not it references “window.top”

4) Form submit: These redirects require a form to be inserted into the top window and then have the “submit” handler invoked. There are a number of ways to do this, which all accomplish the same thing.

In one example:

<form action="http://www.example.com" method="GET">

<input type="submit" value="Submit request" />

</form>

When the submit function gets invoked, this will navigate to the action page. This exploits the behavior of the <form> element, which will navigate to the action when that field is set.

5) Anchor click: This redirect utilizes the on the anchor (<a>) element and its “click” method. Anchor elements are just links and used pretty much anywhere. In order for the ad to exploit these elements, the malicious code inserts an anchor element on the top window and then invokes its click method. This is just invoking a click on a link, but instead of being from a physical mouse click, it’s from a script.

For Example:

anchorElement.href = “http://www.example.com”;

window.top.document.body.appendChild(anchorElement);

anchorElement.click();

Again, the ad must have access to the top window in order to navigate it to the destination. Similarly to the window.open case, a target can be set on an anchor element to be “_blank” which would open a new tab, regardless of whether or not the ad has access to the top page. Most of these are blocked by popup blockers, though, so the “_blank” target isn’t used as often..

Preventing top window access

As you can see, the majority of publishers’ redirect woes arise from malicious ads having access to the top window. How can publishers to help prevent top window access?

1. Separation of direct inventory from programmatic inventory
2. Utilizing sandboxes and SafeFrames appropriately
3. Deploy ad blocking solutions across all impressions

Separation is important because publishers want to provide a rich experience for their users. In order for ads to resize, animate and take over the page, they need access to the top window. Typically, these ads are sold directly or through PMPs and are quality, safe advertisers.

Programmatic inventory should not have this kind of access, and should be delivered in a strict sandbox or in SafeFrames. A strict sandbox is one that removes the “allow-same-origin” flag. The ad can then still “see” what domain it is part of, but cannot access properties of, or modify, the top window. SafeFrames, on the other hand, make the ad “cross-domain,” thereby removing access to the top window through the browsers’ security policies.

Unfortunately, Google AdManager doesn't support strict sandboxing so SafeFrames are sometimes the only way to go. SafeFrames help by making every single ad frame “cross-domain”. They do this by setting the source attribute to “tpc.googlesyndication.com” and writing the ad markup to an attribute of the frame. Example:

<iframe src=’http://tpc.googlesyndication.com/safeframe’ name=’AD MARKUP’ />

The page that’s loaded reads the ad markup, writes it into the frame, and changes the name, like nothing ever happened.

Why blocking solutions & why Ad Lightning?

Ad Lightning provides publishers with a way to overcome the challenges from all five different types of redirects including built-in capabilities that can add sandboxing in the case that a Publisher can't implement SafeFrames or a strict sandbox on their own. Or, even when they can, having an extra layer of protection against new evolving threats that deploy workaround tactics, many other types of malware, video stuffing and competitive separation is still crucial to a comprehensive blocking strategy.

Overall, Ad Lightning gives publishers the tools they need to not just monitor and audit their programmatic ads, but to identify the source & block the bad ones — including redirects — setting a new standard for protection that our industry desperately needs. We are here to help bring the transparency and capabilities needed to hinder malicious actors' attempts to hijack publisher sites —. give us a call today to learn more!