Oct 15, 2018

5 Ways Bad Actors Can Forcefully Redirect a Page (And What You Can Do To Stop It!)

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!

Read More

Oct 09, 2018

Fraudsters Are Masquerading as Real DSPs

This morning, AdExchanger’s Allison Schiff published an article titled “Fraudsters Are Masquerading as Real DSPs,” concerning a spoofing incident that Ad Lightning brought to her attention.  

To sum it up, Ad Lightning discovered recently that a fake company calling itself Amobi Inc. —hoping to be confused with legitimate DSP Amobee — had managed to fool some exchange partners, blending in with real ad calls as a way to disseminate malware and those insidious forced redirects through a hijacked Claritin ad.  

In order to appear legitimate, the company had set up a fake website — not unusual — but went so far as to create fake LinkedIn profiles (which have since been removed).

Ad Lightning brought the information to OpenX and Pubmatic who subsequently blocked Amobi from their demand.  While it was live, the ad was blocked by Ad Lightning 500,000 times.

Take some time to read the article.  It features an interview with Ad Lightning’s CEO Scott Moore and is a great snapshot of what goes on behind the scenes every day as ADL and its partners work together to battle the ongoing challenges of ad fraud.  Just another day in the life of digital advertising!

Ad Lightning offers the most comprehensive ad intelligence platform, focused on bringing transparency and control to a chaotic programmatic world by helping publishers and exchanges manage their ad quality more effectively.  Give us a call today.

Read More

Sep 14, 2018

Anatomy of a Video Stuffing Ad

A recent Ad Lightning study indicated that nearly a third —28% of all Internet ads — are ‘bad ads,’ meaning they are oversized, malicious, offensive or non-compliant with IAB standards or publisher specific ad policies.  The full survey is available here.

With that said, when you lift up the hood, what, exactly, does a bad ad look like? The screenshot below is a great example of an ad gone wrong — completely unbeknownst to the advertiser — that would cause notable interruption to the user experience and become a major headache for a publisher.

So let’s break it down— below is the anatomy of this bad ad:

Ad Requests, Video Stuffing & Malware

There are a whopping 837 requests are embedded in this one ad.  The IAB standard for LEAN ads, or ads that offer a “lightweight user experience to maximize initial page load performance” among other guidelines, is 10 file requests per ad.  Even when factoring in more requests to enable a programmatic transaction, anything over 150 is highly suspicious. 

In this case, when looking more closely at these requests it appears that one of the calls is actually loading a video player. 

Within the video player, we can then see that a secondary pre-roll auction is taking place behind the static ad that was displayed on page load.  The auction is driving up the number of requests fired from the ad.  You can see that a lot of legitimate players are unknowningly getting caught up in the mix!

Ad Lightning has extracted a specific signature (unique ad identifier) that is responsible for this behavior.  That signature, b=e97530f114336b11bsw, was categorized as malware in a previous scan and is being flagged as known in this report.

File Size & Ad Payload

With all of the resources it's taking to load this particular creative, the ad payload has exceeded the recommended IAB spec for initial load and total load.  At 1.61MB, the user experience is likely to be impacted significantly.  The ad image itself isn't too far out of spec, however — with the addition of the player alone — the file size is doubled. 

Data Collection

With multiple video auctions taking place within the ad, it's no surprise that over 564 cookies were dropped from over 35 data collectors. In addition to driving latency, this can be problematic for two reasons:

  • Data leakage:  Unknown or unapproved entities can steal valuable audience data and use that to build audiences that are off property.
  • GDPR & other data regulations: It's critical that users in the EU consent to each entity collecting data. If unapproved collectors are identified, there are significant financial consequences for the publisher. 

This deep dive into one bad ad illustrates how easy it is for the user experience to go off the rails and why advertisers, publishers and users alike are fed up. It’s time to take a scalpel to the influx of bad ads that are the scourge of every digital publisher trying to provide quality journalism and other important content to their loyal readers.   Let Ad Lightning help you identify and block nefarious ads on your properties — give us a call today.

Read More
`` `` ``