Lions and Tigers and Third-Party Javascript

There are many reasons that you may wish to put a third-party javascript reference on your website. Serving ads, making use of tracking and analytics tools such as Google Analytics, and many other features may want to use a remotely referenced third-party javascript. The big issue here is trust. By putting a remotely referenced javascript on your pages you are essentially handing some control of your visitors’ browsers’ over to this third-party. Maliciously crafted javascript can be used to install software, steal form submission data, rewrite elements of pages, send users to fake phishing sites instead of the real site, crash browsers, popup ads or inappropriate content, and much more. The range of possible attacks using javascript is a long discussion in and of itself, and I won’t go into it here. (Google around or ask me if you want more information on this area of things.)

Read about it after the fold….

There are several areas of concern here. For the sake of example’s let’s assume that you have some metrics and analytics services provided by LemurSoft. In order for them to help you optimize your website for revenue, they have a little javascript they ask you to put on all of your pages so they can track the data they need. The javascript is hosted on lemursoft.com, and you can just reference it remotely.
The potential issues are as follows:

1. You’re giving some of your visitors’ activity data to LemurSoft. Maybe it’s buried on page 15 of your privacy policy that you may share data with third-party companies, but put yourself in the shoes of your visitor. By coming to your site, they are unknowingly being tracked and monitored by LemurSoft. They don’t know what may or may not be being tracked.
2. LemurSoft may also be correlating the data gathered from your customers on your site, with data gather from LemurSoft’s other clients. Now they can correlate the behavior of a visitor to your site to the other sites that person visits and what they do there, building a profile of this person, their online behavior and activity, which they can then use or sell, typically to target ads and/or spam, etc… To some degree this is an invasion of your visitor’s privacy, and is something to be seriously considered.
3. LemurSoft may capture more data than needed, or may add new data points or functionality to their script at anytime without you knowing. You have no control or oversight into what LemurSoft is doing with your customer’s browsers, which you have given them control over. Sound a little extreme? There are many examples of ad networks placing ads which install spy-ware or ad-ware into people’s computers or using flash exploits to get access to data they shouldn’t have or place persistent javascript into the user’s browser to drive more popup ads or take them to sites they didn’t intend to visit. As the owner of the site the users are trying to visit you bear a large amount of responsibility to your users, their privacy, and their right to not have spyware installed on their computers without their knowledge.
4. LemurSoft could get hacked, and their harmless javascript replaced with one designed to harvest credit card numbers, crash browsers, or redirect users to phishing sites. By including LemurSoft’s javascript you have doubled your exposure to hackers. Even if your site is very secure, you have no idea how secure LemurSoft’s systems are, or how many disgruntled employees they have running around, etc…
5. A DNS or cache poisoning can allow malicious hackers to replace LemurSoft’s harmless javascript with their malicious one, without even having to hack LemurSoft’s servers. Using SSL on pages and requiring that the referenced javascript also be using SSL can help with these types of attacks to some degree.
6. The more clients like you that LemurSoft has, the more of a target they can become to hackers, as a hack there gives them access to hundreds or thousands of other websites. Even if you can’t imagine anyone wanting to hack your site, by using LemurSoft’s scripts you become vulnerable as if you were a high profile hacking target.

The moral of this story is not that you should never use third-party javascript, it is simply to be aware of the risks, mitigate them where you can, keep your users privacy in mind, insist on a strict contracts with your javascript partner including full disclosure of what data is being captured, how it is used, is it shared or referenced against the data gathered on other sites, when is the javascript updated and why, any security incidents which may have impacted your visitors, and ideally some contractual responsibility in case of a hacker attack. If you lose five million users’ credit card numbers due to their javascript, who is liable? Make sure you trust your javascript partner both as a business partner, and as an end user.