Adblock Plus and (a little) more
Third-party JavaScript - yes, it is a security risk · 2008-12-02 15:23 by Wladimir Palant
Third-party JavaScript includes are as popular as ever. Almost every web page includes third-party scripts, be it for advertising, for visitor statistics or just for the fun widgets. The awareness of security risks connected to it — it is just not there. All the better to see The Register bring up this issue again, this time because of Google Analytics being used on Barack Obama’s website (and particularly in the admin interface).
What’s the big deal? I mean, this script only collects visit statistics, so who cares? Problem is however that this script gets the same kind of access to the web page as the web page’s own scripts. And that means that it can theoretically steal your authorization cookies, or send your password to a third party when you log in or just plainly alter web page content to display a fake news message. And nobody will notice because even if somebody looks at that script — it is obfuscated, noticing an important behavior change is everything but trivial.
Now it is unlikely of course that Google will do anything like that. But, as The Register correctly notes, this is not an assumption you should bet security of government pages on. And even if Google plays nice, even if no rogue Google employee tries to collect an additional paycheck, even if no hacker manages to hack Google’s servers — there is still the possibility that the Google Analytics download is rerouted to a different server, e.g. by giving you a fake DNS response in a public WLAN. Now that is something where SSL can help, and Mozilla has done a great job to make sure that an SSL warning cannot be simply ignored. But even if the script download is SSL-protected (which isn’t the case for Obama’s site), there are other browsers with a large market share that didn’t make that move and will allow malicious JavaScript to execute if you do as little as click “OK” in a warning message.
In short, Google isn’t doing the Web a favor by pushing its various services like Google Ads, Google Analytics or Google Gadgets as script includes. Of course, Google isn’t alone here, but Google happens to be the most common source of third-party script includes from what I can see, and as such it has a bigger responsibility. Now that Adblock Plus 1.0 is released, I can recommend adding this filter to the Adblock Plus filter list:
*$script,third-party
This might break a few websites but that should be pretty uncommon and in my opinion the security gain by far outweighs the issues.
Update (2009-01-13): Adblock Plus 1.0.1 now makes it is easier to fix the false positives in this filter, you can add a domain option to disable the filter on some domains that won’t work otherwise. For example:
*$script,third-party,domain=~flickr.com|~yahoo.com
Comment [35]
Commenting is closed for this article.
Pinaraf · 2008-12-02 15:49 · #
There is worse than that : Google AJAX APIs…
You download your “AJAX” libraries (JQuery, Prototype, Scriptaculous…) from google servers…
They say it’s simpler for you, it increases security because Google handles the security updates and so on.
So you *$script,third-party will break more websites than you can think about if this service starts spreading.
Arthur · 2008-12-02 16:35 · #
Browsing with NoScript (with the default whitelist deleted) taught me that many websites don’t work with third party code. It’s really disheartening. And yes, it is a security issue. Ads have already spread malware and man-in-the-middle attacks are, with nowadays script-kiddy tools, trivial.
Mossop · 2008-12-02 16:39 · #
Yahoo do a similar thing for their YUI. Rather than hosting it on your server you link to theirs that are geo-load balanced etc.
Baz · 2008-12-02 17:07 · #
Its worse on facebook…just incredibly bad. To use the site properly, you need to enable JS not just for facebook.com and fbcdn.net, but also each and every domain that third party apps and advertisers ask for. Some (like ‘Scramble’) want to enable third party scripts from a bare IP address – along with 8 other domains.
As Agent Smith would put it: “I can taste your stink and every time I do, I fear that I’ve somehow been infected by it.”
Thomas Stache · 2008-12-02 18:12 · #
FWIW, Flickr is one of these sites, it includes many of its scripts from yimg.com/javascript, leaving a pretty unpleasant experience with this script filter.
Giorgio Maone · 2008-12-02 19:29 · #
Just use NoScript with the Temporarily enable top-level sites by default option checked.
Not as safe as NoScript’s default configuration, but still safer (anti-XSS filters, ClearClick…) and more convenient (i.e. easier to allow the additional required scripts) than this *$script,third-party filter.
Adblock Plus Fan · 2008-12-02 21:38 · #
Agreeing with Giorgio here. It is very convenient to do this 3rd party trick in Noscript. And when you need to fix a website, the gui in Noscript make everything more simple and you can allow things temporarily so it won’t go into the permanent whitelist if you just want to test stuff.
Although if ABP gets the ability to make rules/exception rules active only to specific domains sometime in the future, then ABP will have a clear advantage in this field.
@Pinaraf, Thomas Stache
In ABP you just need Exception rules to make those sites work. This is no different than in Noscript. It’s just that it’s less easy to do this in ABP’s blockable items list, because sometimes the appearance of certain 3rd party scripts depends on other scripts/3rd party script to have run…it’s just messy.
So far I have 17 different 3rd party servers whitelisted in Noscript. Some of them:
neweggimages.com
paypalobjects.com
gmodules.com
googleapis.com
yahooapis.com
yimg.com
ytimg.com
I do find it quite silly that sites like newegg, paypal, youtube and yahoo needs a 3rd party server to make their site functional…
Reply from Wladimir Palant:
Allowing things temporarily makes little sense here. You want to add permanent exceptions for sites you visit regularly – as to the rest of them, you don’t want exceptions there whether temporary or not.
pirlouy · 2008-12-02 23:03 · #
Indeed, Noscript is more convenient thanks to the option “temporally allow blabla.com” in contextual menu.
But *$script,third-party is very cool if you don’t use Noscript.
Dennis · 2008-12-03 00:07 · #
Adblock Plus Fan >
It’s not those site who uses third party scripts.
They ARE the third party.
Adblock Plus Fan · 2008-12-03 00:22 · #
@Dennis
I suppose you could look at it that way when +90% of the real content is loaded from elsewhere. But ABP and Noscript looks at this differently, to them youtube.com is 1st party even though majority of content is from ytimg.com.
It’s silly and shouldn’t have to be this way, is what I mean.
voracity · 2008-12-03 13:07 · #
Could we tone down the scare-mongering?
* Buying something online —- yes, it is a security risk
* Posting non-sensitive information about yourself —- yes, it is a security risk
* Driving a car —- yes, it is a security risk
* Having a wallet —- yes, it is a security risk
* Using a search engine —- yes, it is a security risk
Security always comes at a cost. The only relevant question is whether the expected benefits outweigh the expected costs.
I don’t mind what your opinion on this is, but you haven’t examined the benefits and, especially, costs in enough detail to advocate as strongly as you are doing.
I’ve seen too many people arguing just one side of security issues this year…
Reply from Wladimir Palant:
Why don’t you start by mentioning some benefits? From what I can see, third-party scripts sometimes make webmaster’s job easier. Sometimes. And that’s it.
* Advertising: Just put that ad iframe into your page yourself rather than let a script do it. Benefits of third-party scripts here: might be easier to use for webmasters, not all advertisers give you iframe as a choice (something for Google to fix).
* Usage statistics: Either use image-based stat services which won’t give you some of the details or analyze your logs yourself (a lot more reliable anyway). Benefits of third-party scripts here: none from what I can see.
* Widgets: Whatever you need, just put it on your site. You can be sure then that they won’t change without you knowing. Benefits of third-party scripts here: slightly easier to use.
voracity · 2008-12-03 15:14 · #
I’m not arguing for or against. My point is that not every argument is settled by pointing out there is a security risk. The value to society (or to individuals if that’s your philosophical bent) can only be estimated by weighing expected benefits versus expected costs.
Maybe that favours stronger security, maybe it doesn’t. In the Obama admin example, the probability and cost of an attack are both extremely low. This is true of almost all cases. The exceptions are financial sites, but even then the risk is borne by the financial institution. (Also keep in mind that if an attacker is spoofing a DNS entry, subtle javascript trickery is the least of your problems. There’s the little matter of your internet access being nearly wholly compromised.)
You’ve already mentioned some possible benefits, and clearly the largest benefit is not technical. Whatever you can do with 3rd party scripts, you can also achieve by locating those scripts (plus backends) on your own server. Rather, the biggest benefit is practical. Google Analytics, for example, is quite a comprehensive service that is absurdly simple to hook into your own website. No worrying about PHP/Python/Perl/Ruby/MySQL/sqlite or file write access to your web server. No worrying about statistic logs cluttering up your system. No worrying about statistics collection producing load on your server. No worrying about upgrading the software package to get new features.
Again, maybe you’ll consider all this and decide the risk is greater than the benefit. That’s good, because you’ve come to that decision by trying to properly evaluate the trade-offs.
My concern is not just with this issue, but also with things like http access control (which has good and bad points), the design of Javascript Next and (in the wider world) OS-level security controls. And just to show I’m not simply anti-security, I strongly believe 3rd party cookies should be disabled by default (subject to access controls) even though that would potentially break quite a lot of sites.
LorenzoC · 2008-12-03 15:16 · #
I guess on today’s Web it is difficult to block all the “third party” scripts, for example Live Hotmail whose domain address is “http://mail.live.com” (it does not work with Shiretoko BTW) has got several of these lines:
http://gfx6.hotmail.com/mail/13.2.0242.1113/i0a.mozilla.js
Right now I am trying to do like you suggested and then adding some white listed addresses when I see something broken (like “@@http://www.google.com/reader/*”) but honestly I don’t know if it makes much sense.
LorenzoC · 2008-12-04 11:45 · #
Besides, this site itselft gets “feeedburner” and something from wordpress blocked by the “third party” rule. :)
Reply from Wladimir Palant:
What site are you talking about? I certainly don’t have WordPress installed, I don’t use FeedBurner and neither do I have any other third-party scripts loaded here.
LorenzoC · 2008-12-04 16:24 · #
Sorry my bad, it was another blog I was reading.
Anyway, the point is still valid, I am seeing almost ALL the blogs include third party scripts, included mine on Blogger.
Also all the news sites, especially when videos are involved.
Now, do you think it is worth it to block the scripts then to be forced to white-list all that stuff?
Reply from Wladimir Palant:
You are missing the point. Of course they are using third-party scripts. And that’s exactly the problem, they are no longer in control of their own site. But I want to see the blog that cannot be viewed because some third-party script is blocked. I just tried a blog on Blogger – three scripts are blocked but that has zero effect on site usability (can be viewed, comments still working). WordPress blog – only third-party script is a Twitter widget that I never noticed, and that one was clearly blogger’s own choice. A blog actually hosted on WordPress.com – nothing unusual, only regular ads and stat counters blocked.
LorenzoC · 2008-12-04 17:03 · #
On Blogger if you block all the third party scripts the form for adding comment does not appear. On CNN you can’t see videos. Same for Youtube. etc.
Maybe it depends on what you consider an acceptable collateral damage. :)
Reply from Wladimir Palant:
Blogger – works for me.
Youtube/CNN – yes, but adding an exception rule is easy and you typically will only need to do it for a few sites you use frequently. Acceptable? Sure, at least for me it is. Of course I would prefer that the sites don’t do such stupid things which is why I wrote that post.
lorenzoc · 2008-12-04 18:42 · #
Blogger has got the old comments in a separate page or the new comments in the same post page, like this one. I’ve got the second enabled and it requires something being blocked.
I agree with you about the issue but unfortunately the “third party” stuff has become a very common practice. So far I had to add this white list:
@@http://*.hotmail.com/mail/$script
@@http://content.dl-rms.com/$script
@@http://flv.kataweb.it/player/$script
@@http://i.cdn.turner.com/cnn/.e*/$script
@@http://s.ytimg.com/yt/js/$script
@@http://www.blogger.com/jsbin/$script
@@http://www.blogger.com/widgets/$script
@@http://www.google.com/reader/$script
Aerik · 2008-12-05 01:58 · #
Just wanted you to know that you don’t have to use the asterix to block all third-party scripts. Just “$script,third-party” will do.
Reply from Wladimir Palant:
Thanks, I know :)
I still prefer having it – easier to understand the rule then.
Ervin · 2008-12-06 09:10 · #
I feel that whitelists are not a good solution. Let’s take Youtube. I don’t want to say in AB+ that ytimg.com should load scripts despite other rules, I want to say ytimg.com is not a third-party site to youtube.com.
I’m affraid such a mechanism would be hard to implement?
Reply from Wladimir Palant:
There have been some requests for site-restricted filter rules, so I might implement something like this…
mrbene · 2008-12-08 03:45 · #
I had a discussion on this topic fairly recently. Knowing that the contents of an iframe are pretty much inaccessible to the page on which the iframe is rendered, I had casually dismissed the possibility that script executing in an iframe would have access to the parent page. That assumption is, of course, incorrect.
So why do these large sites take a security risk like this? I’d say that there are three major groups of reasons – lack of technical knowledge, limited business risk, and compelling technical reasons to do so.
There’s not much to say on the “lack of technical knowledge”. Not everyone takes the time to educate themselves on all technical risks – if they did, we’d not have user-propagated malware, and the whole Internet Security industry would be significantly smaller.
On the “limited business risk” front. I would fairly definitively say that Google doesn’t care if your DNS gets hijacked while you’re at cafe with free wireless. Not much anyway – so long as there’s close to no legal risk for them. As a publicly traded corporation, their primary reason for existence is to generate shareholder value, and a few people getting taken advantage of in insecure environments has little impact on their bottom line – actually doing something about it would likely cost more and not generate any income.
On the “compelling technical reasons to do so” (and in this case “to do so” is “to use different domains for additional resources”) front, historically large sites have made decisions for the different domain for a couple of reasons: – Less cookie weight. If you’re dealing with session cookies, authentication cookies, and all that type of thing on your main domain, it makes sense to put your images (that don’t need authentication) on a second domain to reduce bandwidth costs per transaction. – Use of content distribution networks (CDNs). Once your images and static scripts are on a different domain, you can go ahead and use a CDN (like Akamai) to deliver these for you. The raw HTML still needs to be generated by your servers (on your domains) that have access to user prefs and details.
Coming from that background, it’s not surprising at all that large sites are embracing third party APIs for widgets and third party JavaScript for ads. Small-scale privacy and security is in the hands of the consumer. Large scale is in the hands of the business – which is why something like the Kaminsky DNS disclosure had such impact (it was fairly large scale).
Ares2 · 2008-12-15 00:38 · #
“There have been some requests for site-restricted filter rules, so I might implement something like this…”
Is there a chance that this would work for hiding rules too or would it be a $option?
Reply from Wladimir Palant:
Not really sure how you interpreted my statement here – but element hiding rules can already be restricted to a site. example.com#foo will only apply on example.com.
Ares2 · 2008-12-15 14:12 · #
You are right of course. I already imagined the reverse case: A rule for all sites but one (or more), something like .google-analytics.$~domain:foo.com , but this way it won’t work for hiding rules obviously.
Reply from Wladimir Palant:
See http://adblockplus.org/forum/viewtopic.php?t=3269 – yes, I also want to allow rules for “all domains but …”. Unfortunately, this won’t be possible for element hiding rules. @-moz-document only lets me specify a list of domains, no exceptions allowed.
Ares2 · 2008-12-15 14:28 · #
Yeah, I just read it after I answered here. :)
Do you know if a future version of CSS will change this?
Reply from Wladimir Palant:
I am not aware of any plans. Problem is first of all that W3C didn’t show much interest into accepting @-moz-document in CSS (at least that’s my impression). Without having the basic suggestion accepted Mozilla has little incentive improving on this proposal.
Clip · 2008-12-18 12:43 · #
Problem is however that this script gets the same kind of access to the web page as the web page’s own scripts.
This is a myth. Cross-site scripts can not access document objects, originated from a domain which differs from their own. Any decent browser will give you the error permission denied for such an attempt. Cross-site scripts could be a security risk only if a browser has a bug. But if it does have it, when the browser could expose you to a danger in innumerable other ways, and even without scripts at all. This could be images, stylesheets, or whatever you think of as a secure content.
Reply from Wladimir Palant:
How about you try it? Scripts loaded into a frame from a different domain don’t get cross-domain access. However, if you include a script directly into your web page, it gets full access to this web page – no matter where the script comes from.
Clip · 2008-12-19 13:56 · #
Oh, of course, you are right, if you insert a javascript into your page: the origin is the same. If you don’t trust the script provider, you should not load a script by reference, i.e. via src attribute, and use it as an inline code after security check.
vestel · 2009-01-06 22:56 · #
I started being afraid of :)
Aerik · 2009-01-13 03:07 · #
Giorgio is still linking to this thread to criticize this feature.
I don’t know why he just can’t get it through his head. Allowing everything a domain can do, or allowing a domain to do a single script, are two different things. This is another case where the ideal situation is to have both noscript and adblock plus, set up so that when you temporarily allow a domain, you’re only allowing those specific files that you want, thereby having control of what data you want to receive or send, and how much of your paid-for internet you’re going to use.
Giorgio Maone · 2009-01-13 15:58 · #
@Aerik:
In the post you’re referring to I was actually praising this Adblock Plus feature as a protection against JSON hijacking, and my “cricism” was just calling it “rather inconvenient” for this purpose, especially if compared with NoScript 1.8.8.95’s specific countermeasure which doesn’t require any script blocking to be effective (i.e. it would work even in “Globally Allow” mode, just like Anti-XSS filters and ClearClick.
That said, after some much needed sleep, I must apologize for having even cited Adblock Plus in that post, giving its users a false sense of security: rectified and clarified.
Reply from Wladimir Palant:
Heh… You really want me to have redirects as my top priority, right?
Reply from Wladimir Palant:
Oh, and modifying the domain option on a filter automatically from the UI is in the works – I just didn’t consider it important enough to hold Adblock Plus 1.0.1 for it.
Giorgio Maone · 2009-01-13 16:18 · #
@Wladimir:
You don’t need to ;)
Adblock Plus is a wonderful annoyance blocker as it is: I actually recommend it to all my users, and even tweaked NoScript to cooperate better with it
freddy · 2009-01-16 17:23 · #
Not exactly a reply that’s specific to this topic, but here’s a huge thanks to the makers of both Adblock Plus and No Script for making browsing the web tolerable
Travma · 2009-01-20 16:42 · #
Maybe we need a p2p like service which filters ads, popoups, virus, spammers and scripts. The images had to download from the original site to avoid peer overflow if it possible, only the htlm page had to feed through the peers. Maybe it is slow in the start but as new peers connect to it the total bandwith may exeed that from the original site only. I can aford 2 second delay from a page, I cannot aford a machine not working as intented. Remeber, computers had to help humans, but many years passing and we help them to work because the design is defect from the beging.
Bill Craig · 2009-03-19 11:37 · #
How do I block google analytics?
Reply from Wladimir Palant:
How about using the forum? You don’t need to register, just create a new topic.
BB · 2010-03-14 08:28 · #
what is this?
~ AdBlock/AdThwart/AdBuster/NoScript/Privoxy ~ ??
and how can i cure my pc?
nonWoot · 2010-06-27 03:09 · #
This is cool because can keep just the one extension. NoScript is bloated overkill that really noticeably slows down FF.
Anonym · 2010-08-14 23:22 · #
What about AdBlockPlus adding the features of NoScript? NoScript has really some great features(not only blocking of Javascript) that I don’t want to lose. The features could be optional so anyone who doesn’t want to use those additional features could completely disable them. Since NoScript is GPL this could simply be done by copying the NoScript code and implementing the features into the AdBlockPlus Interface so you can control them. This shouldn’t be that difficult I think. (Sorry if I’m wrong with this.)
Reply from Wladimir Palant:
GPL is not compatible with the Adblock Plus license (which is MPL). Either way, I wouldn’t want to copy anything from NoScript – I can add similar features if they make sense in the context of Adblock Plus. But there aren’t exactly many that do.