Blog

Oct 22, 2018

Major Ad Exchanges Raise the Bar for Programmatic Best Practices ....and That’s Great News for the Industry

This week, six major ad exchanges released an open letter titled “Principles for a Better Programmatic Marketplace,” to publishers and advertisers announcing that they have asked the Trustworthy Accountability Group (TAG) to help them codify principles for the programmatic marketplace by the end of 2018 with regard to better “transparency, efficiency and fair-market practices.” The letter was signed by the CEOs of OpenX, PubMatic, Rubicon Project, Sovrn, SpotX and Telaria.

You can read some of the news coverage here and here.

Mike Zaneis, President of TAG said, “These principles raise the bar for how exchanges operate and will ultimately make programmatic a better space for advertisers and publishers….and assure brands, agencies, and publishers that their partners are committed to a fair, efficient, and transparent programmatic supply chain.”

Near to Ad Lightning’s heart —quality assurance was one of the three main principles the group has flagged (in addition to auction rules and fee transparency). The group’s goal to improve ad quality and regain advertiser trust requires that:

  • 100% of ads in an ad exchange will be scanned for malware and other quality concerns
  • 100% of ad requests will be scanned for invalid traffic
  • 100% of domains and apps will be scanned for brand safety, ad count, refresh rates and audience quality.

Ad Lightning applauds this initiative and is delighted that influential players in the industry are banding together to raise the standards for ad quality.  This is a concept that Ad Lightning has built its entire business around. 

Ad Lightning’s patent-pending technology helps publishers and exchanges take control of their programmatic advertising via proactive bad ad protection, live site scanning, and ad network insights. When it comes to helping exchanges meet this first requirement, we offer a variety of options that meet this stringent bar for 100% coverage:

  1. With AdL's tag scanning solution, exchanges & SSPs can submit all creative tags via our API for initial scans as well as ongoing scans to look for suspicious behavior.
  2. Our ad blocking solution for SSPs takes this requirement to the logical next step and can proactively block bad ads in real-time, providing increased protection and automated bad-ID feedback loops.  

Ad Lightning is always here to address your ad quality concerns!  Give us a call today.

Read More

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, 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