Last updated at Tue, 26 Dec 2023 19:44:23 GMT

Advertising largely supports free content on the Internet, and many significant sites rely on DoubleClick for Publishers (DFP), Google’s advertising platform for publishers to monetize their traffic. Unfortunately for the AdOps world, DFP has been hosting cross-site scripting (XSS)-vulnerable ads since 2015! Ouch.

You’re writing compelling content for your readers and using Google ads to pay the bills. Google has tools for you, and you’ve just found out that these tools could compromise your readers. That’s not very nice, and probably not part of the deal you signed up for. Publishers are waking up to a massive headache this morning as they try to track down: Have they been affected by the breach and are users executing these vulnerable files?

How does this affect my content?  

Several ads use files called “iframe busters” that enable particular types of rich media ads to “expand” or bust out of iframes. When you confine something to an iframe, it stays put. The content can do what it wants within its frame, but the frame is an ironclad box. However, the whole point of these ads is to let them break out of their jail cell, get big, and try to capture your attention.

What can you do to protect your readers?  

Well, the response from Google is to remove the vulnerable files, and that’s easier said than done. Individual site owners enabled these files at Google’s instruction because that’s how their advertising tools work. Unless you’re able to live without ad revenue, you’re probably going to have to live with these files for some time. The ad experience is typically profoundly embedded within the content of a site.  It’s not just a matter of removing some files. Usually, any changes to advertising require running a full set of user experience and regression tests to ensure the site functions as it should.

If you already know you’re serving up these vulnerable files and you wish to understand the impact that removing them would have on your site and users, one way to tell is to insert a piece of tracking or analytics code into the source HTML before removing the file from being served publicly. Get at least a 1-hour sample (btw, it’s no fun to have a vulnerability and knowingly leave it in prod) of the user data to understand which URLs are executing the script.

Update 12/22. A detailed description of the vulnerability along with reproduction examples can be found here. Basically, this is a textbook example of a “Reflected XSS” attack. An unknowing user could click on a link provided by the attacker and then their private information would be sent to the attacker’s server.

Short of removing all the revenue your content is generating, what else can you do to protect your applications? As part of its product, tCell includes browser protections. One of the reasons we built the browser agent is to protect against XSS attacks. You can use Content Security Policies (CSPs) to block unauthorized XSS requests, and enable selective protection that keeps the ad revenue flowing without exposing your users to attack. If you’d like to talk to us about keeping your readers safe, contact us!