Web ads considered as a security exposure

February 16, 2015

One of the things that reading Twitter has exposed me to is a number of people who deploy browser adblockers as part of their security precautions. This isn't because they're the kind of person who's strongly opposed to ads, and it's not even because they don't want their users (and themselves) to be tagged and tracked around the web (although that is a potential concern in places). It's because they see web ads themselves as a security risk, or more specifically a point of infection.

The problem with web ads is web ad networks. It's a fact that every so often web ad networks have been compromised by attackers and used to serve up 'ads' that are actually exploits. This doesn't just affect secondary or sketchy websites; major mainstream websites use ad networks, which means that visiting sites normally considered quite trustworthy and secure (like major media organizations) can expose you to this.

(As an extra risk, almost all ad networks use HTTP instead of HTTPS so you're vulnerable to man in the middle attacks on exposed networks like your usual random coffee shop wifi.)

Based on my understanding of modern sophisticated ad networks and the process of targeting ads, they also offer great opportunities for highly targeted attacks. At least some networks offer realtime bidding on individual ad impressions and as part of this they pass significant amounts of information about the person behind the request to the bidders. Want to target your malware against people in a narrow geographical area with certain demographics? You can do that, either by winning bids or by hijacking the same information processes from within a compromised ad network. You might even be able to do very specific 'watering hole' style attacks against people who operate from a restricted IP address range, such as a company's outgoing firewall.

(The great thing about winning bids is that you may not even be playing with your own money. After all, it's probably not too difficult to compromise one of the companies that's bidding to put its ads in front of people.)

If you're thinking about the risks here, web ad blockers make a lot of sense. They don't even have to be deeply comprehensive; just blocking the big popular web ad networks that are used by major sites probably takes out a lot of the exposure for most people.

I don't think about ad blockers this way myself, partly because I already consider myself low risk (I'm a Linux user with JavaScript and Flash blocked by default), but this is certainly something I'm going to think about this for people at work. Maybe we should join the places that do this as a standard recommendation or configuration.

Comments on this page:

To me this concern is inextricable from the concern about tracking. I suppose the overall category is ultimately “exposure” – there are unbidden third parties involving themselves in my activity around the web, which increases my profile in various undesirable ways. Attack surface is one of them, tracking is another, but it’s really all of a sameness to me: they’re just knock-on effects of a lack of keeping a low profile. So I don’t like strangers involved in my affairs, simply as a matter of principle.

A distinctly secondary concern – a major concern all by itself, mind, just far behind the primary one – is the sheer number and intrusiveness of ads in terms of the reading experience. I don’t want swaying monkeys in my face when I’m trying to read stuff.

I actually don’t mind seeing ads that don’t mount a frontal attention attack. For a long time I purposefully ran with only Javascript and Flash disabled, but without an ad blocker, specifically so that e.g. Google text-only ads would show. I’m aware that the people who run the sites I visit need to make money somehow in order to run them.

But at this point, concern #1 eclipses all other considerations.

(Well, the intrusiveness of ads is really just concern #3, with resource consumption at #2. (Actually it’s not even resource consumption in principle; it’s responsiveness and battery life that I really care about, but that combination tends to mean resource consumption in general, ultimately.) However, whether to block ads or to not block them has various different trade-offs WRT resource consumption. The current state of affairs seems to be that some blockers help and others make things worse. (Also, this concern overlaps with the intrusiveness concern in that the most in-your-face ads tend to be the most resource-hungry ones as well.))

I started blocking web ads many, many years ago for 2 reasons:

 1. To increase the page load of the web site.
 2. To minimize traffic bandwidth.

Initially, both were maintained, until ABP started injecting 4MB of CSS into every page to block the ads. Then my web experience was slower, not faster, by blocking ads. However, a new point of interest come into light:

 3. It decrease web traffic profiling and identity sniffing.

Two out of three isn't bad, so despite the web pages loading slower, I was happy. Then, as you already blogged about recently, uBlock came onto the market as a more efficient ad blocker that increases page load time. Ditching ABP for uBlock, I have been able to confirm that my web pages load faster, and browsing is generally more responsive.

Now, as in IT professional, a new point of interest against web ads has surfaced. I now block web ads because:

 4. It minimizes the potential for badware getting installed on the machine.

I never thought web ads would bring us to that point, but they can very likely be a source of malware infecting client machines. Along with Privacy Badger, Disconnect, and click-to-play Flash, I'm hoping that #4 is completely eliminated as a threat.

Regardless, as it currently sits, those are the four reasons I block ads, and will continue to do so.

Written on 16 February 2015.
« My current views on Firefox adblocker addons
Your example code should work and be error-free »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Feb 16 01:53:32 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.