In late 2017, Google released a warning for DoubleClick platform users about a design flaw that leaves their websites vulnerable to cross-site scripting (XSS) attacks from third-party vendors.
This wasn’t the first time Google Ads has had problem, but those are usually coming at us from the admin side. This is a design flaw that degrades UX by hijacking the script mid-session.
Cross-site scripting issues aren’t new. They aren’t even the biggest digital marketing story of the year; this type of vulnerability has been around since the 1990s. Recently, however, hackers have found newer and sneakier ways to exploit it – and not in a small way.
The issue happens with “iframe busters” – HTML files on a domain server that determine how a Display ad is engaged by a visitor, effectively allowing ads to appear larger than their encapsulating iframe.
Now, cyber attackers have found a way to add arbitrary code to the busters, leaving websites and visitors open to infiltration. This undermines visitor trust at a time when consumer confidence in cybersecurity is already low and data integrity issues are front-page news.
In this article, we’ll take a look at XSS attacks and outline ways in which advertisers can steer clear of the attacks themselves and for their partners – publishers and vendors.
Cross-site scripting has a built-in flaw that leaves dynamic web content open to manipulation by inserting malicious code into the embedded script. It usually affects Javascript code that’s used to power ads, but it can be injected into any type of active code like ActiveX, Flash, or VBScript.
Exploiting this weakness in the coding wreaks havoc by redirecting – or misdirecting – website visitors, accessing cookies, or installing malware. It can hijack a user’s entire session and send them to another website. The bigger and more interactive a website is, the more insertion points there are for hackers to probe for weaknesses.
This is part of the reason that systematic flaws and XSS attacks are so difficult to detect and prevent. Coding is inserted on the client side, relying on user-generated actions for initiation.
Meaningful penetration testing relies on anticipating every possible interaction between user and application in order to be effective, and it must be able to detect every possible access point.
Monetization is one of the chief ways ecommerce sites, bloggers, vloggers, and others generate revenue online. As annoying as ads can be, they’re the life’s blood of online business owners. In 2018, nearly 25% of enterprise companies spent 50% or more of their marketing budget on retargeting ads.
Display ads also allow website owners to provide value to their visitors while keeping a free internet truly free for users. Today’s ecommerce environment is all about providing a quality user experience (UX). Google algorithms will even reward you for it with higher placement on the SERPs.
It’s ironic that this flaw is affecting their user base through a monetization interface that Google encourages website owners to use. It doesn’t affect static content but any app or website using dynamic web content that requires a user response to initiate an action is technically vulnerable to an XSS attack.
That means games, websites that use clickable ads, and ecommerce websites that have a high amount of user-generated content, like eBay, can by hijacked. This vulnerability affects platforms, advertisers, website owners, and their traffic.
Looking at advertising in particular, the entire supply chain of this industry finds itself in peril from XSS purveyors at each step along the way. Here’s a quick list of participants affected and how:
1. Publishers find their sites are hacked.
2. Google has their network compromised with bad actors (bad advertisers).
3. Vendors get lower quality traffic because the ads are more aggressive.
4. Advertisers are the good guys who play by the rules are unduly affected.
Such attacks also undermine consumer trust and confidence if they aren’t immediately addressed and rectified.
Attackers probe Javascript or Flash coding by finding a weak point to insert alternative instructions.
Any time that application is used, the malicious code activates and whatever result the hacker intended is performed. The most common points of insertion are web forms, search fields, forums, and cookies.
Further, XSS attacks “work” even if a visitor encrypts his or her traffic using a virtual private network, or VPN. VPNs are effective for maintaining anonymity, but XSS attacks can penetrate whenever your visitors click on an infected third-party ad, perform a search, or otherwise encounter the script. Entire sessions can be hijacked, and the code can even enable access to a user’s account.
That’s bad for business.
This latest attack strikes through flaws in iFrame Buster kits used to expand ads on DoubleClick for Publishers, DoubleClick Ad Exchange, and other platforms that allow website owners to display ads outside of iframe.
The HTML code in iFrame Buster allows creatives like GIF, JPEG, JavaScript, HTML, and Flash to show beyond the confines of the frame that contains it. An example is banners that expand when a user moves their cursor over the ad.
Website owners, servers, or browsers reading the script have no idea there’s malicious code present that doesn’t belong, and neither do the hosting platforms or users. The problem is mainly due to ad developers incorrectly coding their content with in-house frame-busting apps.
Proof of concept (PoC) was released through a Full Disclosure mailing list entry by an IDM employee who uses the name Zmx. It provides sample codes and other examples of how the attacks are initiated. There’s also a list posted of affected vendors and advertisers that includes Undertone, Interpolls, and IgnitionOne (netmng.com). Tech researcher Randy Westergreen has also provided samples and an explanation of the latest XSS issue.
The only ways to prevent such attacks are through diligent testing and/or removing any dynamic, interactive content from your website. Since many ecommerce websites rely on input from visitors to generate revenue, the latter option is the least appealing. That leaves diligent probing and testing as your first and last defense.
The latest attack accesses users’ cookies when they interact with websites that carry banner ads, but it can also attach itself to emails, URLs, and other interactive, clickable content. The current problem is thought to originate with Web 2.0 and Ajax technologies that allow more covert infiltration.
Google has taken action over their recent third-party XSS issue. A spokesperson for the tech giant released this statement in response to the initial discovery: “We have disabled these vendors, removed these files, and added instructions in our help center to help publishers manage any additional steps to help ensure their users are secure.”
So what can ad creators, site administrators, and developers do to protect websites and visitors from an XSS attack in the future?
In the short run, this stops the bleeding but also eliminates a lot of website functionality. The long term fix would include replacing buggy code with best practices that filters user input and removes malicious scripting before it can be installed. Patch any present flaws and vulnerabilities found and, going forward, always test code before deployment.
This allows administrators to check for malicious code and determine the impact removing it will have on website or application functionality. This analysis should be performed on live code and use a test run of at least one hour in order to root out the unauthorized scripts so they can be removed. This can be done by inserting tracking code from Google Analytics into the HTML script for each page or by using Google Tag Manager to target specific scripts.
As well as vendors who work with advertisers (or networks) who have exploited the vulnerability. According to Westergren, most of the XSS vulnerabilities he found were due to poor whitelist implementation. In other words, publishers failed to restrict certain domains which should be granted access to executing scripts.
He went on to outline a number of high-traffic websites using an iFrame Buster with weak restrictions, thus allowing attackers to compromise the domain, including Jivox and Adtech. DoubleClick advertisers should follow Google updates regarding XSS and other advertising exploits, pay attention to affected domains, and selectively remove them from your ad campaigns. Fortunately, the ability to control which publishers your ads appear on is built into DoubleClick.
According to Google’s knowledge base, excluding domains will prevent your ads from appearing on any page on or within that domain. So to avoid advertising on domains compromised by XSS, regularly audit and update your “blacklist” in DoubleClick and you’ll be in the clear.
Until platforms are able to completely anticipate and block XSS attacks, hackers will continue to exploit the vulnerabilities inherent in the script used to direct dynamic content.
It’s time for an industry-wide solution to a problem that has been plaguing website owners for nearly as long as ecommerce has existed. But for now, make sure you’re following these strategies to protect your own DoubleClick ads against these attacks.
About the author
Dan Fries is a freelance writer and full stack Rust developer. He looks for convergence in technology trends, with specific interests in cyber security and cloud infrastructure as a service (IaaS) applications. Dan enjoys snowboarding and is based in Hong Kong with his pet beagle, Teddy.
Comments
Please read our Comment Policy before commenting.