How open source could save us from ad-served hacking
Wed 27 Jan 2016
Since the inclusion of ads from major ad-serving networks such as DoubleClick and AdTech represents one of the most promising points of vulnerability for any website which needs to commercialise its output, it has always perplexed me that there seems to be no prospect of a solution for what is, as far as I can tell, the No.1 attack vector for SQL injections.
I’m not speaking abstractly. Some years ago while working for an entertainment website I got up one morning and ran the usual checks on the site status, only to note that all results from Google for that site carried the dreaded legend ‘This site may harm your computer’.
Yes, it was an SQL injection attack which had been facilitated by the very close proximity and permissions which the website I was working for had, perforce, to share with the advertising output of one of the major online advertisement distributors.
The problem took weeks to resolve, and the scary warnings from Google took nearly a month to disappear from search results.
Local issues
There’s a good case to argue that practically no off-the-shelf or custom-built CMS provides adequate protection against hackers altering the parameters of SQL queries – which, in effect, can be as simple as typing code into a bespoke search box that the website has provided. In such a case, parameter-cleaning is often overlooked by hard-pressed developers, particularly at the critical or problematic stages of a project.
But that’s another argument for another day. What interested me then and continues to interest me is how we reached a stage where almost every commercial website is forced to allow such a vulnerable ecosystem as an ad-serving network into its secure space.
This site is no different. We carry a reasonable amount of advertising, and like similar sites we need to in order to make all this news-centric fun possible. To boot, nearly all of it could very easily be provided direct from our own servers, since the campaigns have specifically been crafted for The Stack. If we were to do that, our ads could not be blocked by any default adblocking technology, since the ads would come from the same domain and IP as the news and features that our readers come here for. And that’s a position that many far larger publishers would find desirable.
The unmovable status quo in online advertising
Why, then, do we serve these unique campaigns via the same industrial mechanisms as are used by so many publishers – publishers who may be serving campaigns intended for re-use across a range of websites and publishing companies? Why do we have to expose ourselves to the same risk of SQL injection that they are obliged to by force of aggregate economics?
There are a number of reasons, which individually can’t easily justify the risk entailed in grafting someone else’s vulnerable infrastructure onto your own. One is trust; an advertiser wants to know with some surety how many impressions of their material was served up. A site running a proprietary system and serving ads from its own machine could rig the figures any which way.
The lack of user-access granularity in Google Analytics makes that method of reporting problematic, at least at the moment; creating custom reports and restricted views is a sophisticated development pursuit, and one which would become burdensome on limited teams across a range of campaigns, if one were determined to serve one’s own advertising and rely on Google for accurate figures.
Depending on the ads involved, bandwidth can be another consideration; although ad-serving companies charge quite profitably for dispensing campaigns and providing accurate diffusion counts, the bandwidth costs of certain more elaborate campaigns isn’t a minor matter for all.
Sophisticated – and deadly
Next is the issue of code complexity in ads; at the moment SQL injections likely to harm a site have to be facilitated by cross-site scripting techniques which modern CMSes are evolving against. Even with that barrier to cross, I know for a fact that success is quite possible depending on the state of the site’s parameter-cleaning. Including complex JavaScript in advertising material which has no need to traverse the ‘different-domain’ obstacle could lead to far more aggressive and high-volume attacks. The solution to this is the same one that applies to parameter-cleaning itself – more effort, more money; and more factors which drive publishers back to the fairly-broken default of ad syndication as it currently stands.
Yesterday I wrote of how Adblock Plus isn’t necessarily the best, and certainly isn’t the most ethical of all possible open-source adblocking solutions; but rather that it predominates because it grew a massive user-base in a time of diversity and transition. And so it is with its opposite number – the ad-serving industry whose domains form the basis of adblockers’ blacklists and whitelists.
It’s a rotten, but established solution. It’s just ‘what people do’.
To boot, the ad-serving industry as it stands has billions in turnover to spend defaming or undermining any alternative system, should one arise.
A distinct lack of hippies
Usually a widely-felt need in the field of computing is met by the aggregate power of open-source programmers, but attempts to address the issue this way have floundered for a number of reasons. Yes, there are a couple of unloved OS ad-servers – Revive (formerly known as OpenX Source) and the even less magnificent NginAd. Their obscurity hardly recommends them in a business context.
The disparate nature of the three most popular content management systems – WordPress, Drupal and Joomla – means that no development has even been attempted for a local (i.e. server-based) ad serving system which accommodates so much as these three platforms, even if one could possibly overcome those advertiser trust issues via strange methodologies such as encrypted torrent-based statistics, or blockchain-based figures. Being the largest CMS currently in use, WordPress has a variety of free or commercial ad-server plugins, most plagued either by obscurity and limited development resources, by lack of complexity, or by excessive complexity.
The primary reason open source has not rallied to the cause of developing robust and secure local ad-serving solutions is that it’s an unpopular one. No respectable gaggle of code hippies are likely to assemble and burn away hours after work towards this goal. And even if they did, they’d likely end up being bought out by the large concerns currently dominating the market with a vulnerable, flawed and illogical solution.
Ironically the locally-based solutions which work best are rightly deemed to be pernicious and privacy-invading, such as Lenovo’s Superfish controversy, or Microsoft’s interest in serving ads from localhost. Though addressing the ever-critical issue of personalisation quite nicely, these methods brought ‘local ads’ rather too close to home.
Nonetheless, from the point of view of security, there is genuine need to provide a local solution for websites which would like to serve ads locally and still provide reliable statistics to the advertisers who are paying for the campaigns. However, such a solution would require not only an ethical leap of imagination on the part of open source contributors, but also restraint and forbearance on the part of participating advertisers. So as it stands, ad-serving networks seem set to represent a single and tempting point of vulnerability for SQL-based attackers.
