Dangers of remote Javascript
As we move to a widget web, where the goodies on your site may not necessarily come from your site, it's worth sparing a thought for security. We at O'Reilly just got bit on perl.com, which redirected to a porn site courtesy a piece of remotely-included Javascript. One of our advertisers was using an ads system that required our pages to load Javascript from their site. It only took three things to turn perl.com into porn.com: (1) the advertiser's domain lapsed, (2) the porn company bought it, (3) they replaced the Javascript that we were loading with a small chunk that redirected to the porn site (note that nothing on or about perl.com changed). Our first concern was that we'd been hacked and "run this remote Javascript" inserted from our servers without our knowledge, but that hadn't happened—our change records and RT logs show we've had that Javascript and advertiser since May 2006.
After seeing Rasmus's excellent talk on web security at OSDC, I realize that in many ways we were lucky—once an attacker can run Javascript on your browser, very bad things can happen. So here are the questions we're asking ourselves, questions that all of you who run sites that take a lot of advertising or load a lot of widgets would do well to consider: do you know all the Javascript your pages load? When do those domains expire? What other risks have you identified around remote Javascript, and what are you doing to mitigate those risks? Decentralized content means decentralized security—it's up to us to ensure our systems are stronger than their weakest components.
tags: web 2.0
| comments: 26
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/6222
Comments: 26
The good news: the industry is aware of the problems presented by cross-site JavaScript includes. We have to operate within the constraints of the language, the runtime (browsers), and associated objects such as a parent web page. Other embed formats such as Flash allow definition of permissions at embed -- meaning Perl.com could limit some of the features available inside the ActionScript run-time.
You might enjoy having a look at Google's Caja project and its research papers. Site authors can sandbox a widget's code, exposing a subset of features to third-party scripts.
Consider sandboxing the third-party JavaScript inside an iframe (object in an xHTML context) to limit its scope and privileges.
Are you referring to the image banner that would sometimes appear at the bottom - advertising the video network? Currently, it does not appear to be a porn site
How much traffic did you lose before discovering the hack? The quality readership of perl.com will immediately inform you of any deviations.
If you are referring to a different advertiser - are you taking action against the Hacker via the Service provider and Registrar - hopefully you will at least make an effort
Now, in I.E. 7 running under VISTA - it is difficult for malicious JavaScript to become embedded in the browser. :-)
"And thats why I surf with Firefox + NoScript installed."
And that's why I hate advertising.
This does raise an interesting problem that is hard to solve. Partnerships that involve running remote javascript are an important part of a lot of web sites. Its a powerful technology, allowing richer ads, content syndication, and outsourcing of page components, so business logic in javascript isn’t going to go away. It does increase your attack surface because a compromise of any of your partners can effect your site, as it did here.
You can’t really do any sort of validation in javascript, because the logic to do so would be out in the open and easily faked. I think a hybrid approach might be the best solution. Have you server do a “secret handshake” with the partner every so often, and if it fails then don’t display the script tag for their service. The handshake could go as far a cryptographic signing system that requires active support on the partner’s server, or it could be a passive system that checks for the existence of certain hidden urls and that the whois information hasn’t changed.
Any other ideas?
@Niall "The good news: the industry is aware of the problems"
Everyone is aware, but very few people in the industry are even doing anything about it. I am sure this article will make its way around the web. 90% of the people will have the same reaction. The article will be voted down and or buried, people will comment; "The problem has always been then there." This is true. This is also the problem, everyone knows a problem exists but does nothing about it because it is hard or not interesting. Even worse than that people compound the situation by exploiting the security hole and proliferating the problem. What if your bank felt the same way all the JavaScript kids felt. See you later bank account.
iframes, cross-domain scripts and cross-domain XHR break the trust relationship of websites and their users. As a browser of a perl.com, there is a trust relationship established between me and perl.com no one else. Unless I view source or look at firebug, I wouldn't even know that the site includes executable code from a 3rd Party.
More works needs to be done on the server-side to ensure that sites still have the flexibility to include widgets, but it is done in a manner that can be controlled.
Some sort of public/private key interaction is needed to prevent this, but you will always have people who blindly click OK/Continue when presented with a certificate mismatch dialog.
@Bob
Facebook has to deal with malicius code inserted through third parties. Maybe it would be enough to go way like FB - parse JavaScritp and CSS and prepend all identifiers with some third party ID. That way it is impossible to mess with elements from main page.
More info on FB developers wiki (probably FB account needed)
Of course that does not help against third party domain expiration ;)
This exactly why I surprised that Facebook was able to convince so many sites to include their Beacon Javascript. If we are entering an era where large companies/sites can convince other large companies/sites to include their Javascript then this problem is only going to get worse.
Maybe some sort of signed domain key system combined with NoScipt is the way forward?
@NetManiac
This is true, the Facebook approach is similar to what I was talking about but more generalized for application developers.
By making the 3rd party code come through the application host, they can assemble the final page before it is sent to the browser. Facebook performs checks on the 3rd party code and makes sure only certain html attributes are used and they don't contain any executable code. JavaScript that is loaded also goes through the server and is modified to prevent malicious code.
Facebook's approach is the best way to include 3rd party widgets. The only problem with their platform is that's available only to them.
I never liked the idea of ads containing remote javascript. If I go to oreilly.com, I only want to run and render data from oreilly.com.
There should be a way for websites to set privileges for remote js, so when they give entrust a 150x150 area to an external agent, they can still guard against being blindsided like this.
Caja Caja Caja.
Instead of random bits of regexp code (which someone will always find a way around) do it properly and use Caja.
(Interestingly, most of the current development effort in Shindig - the open source open social implementation - revolves around integrating Caja to solve problems like this)
Great post! To be honest, I've never really thought of that before. Hmm... I think it's about time to do so :)!
I second Caja... Without it, everybody is stuck re-inventing the wheel.
Another alternative is some kind of syndication of the remote JavaScript to your servers, and perl.com gets the option of accepting the change or not.
I am sure glad that I've got NoScript and I don't turn on any JS for Google Analytics or any advertising.
I to run Firefox + NoScript + Adblock and for the most part I have a pleasant browsing experience. If I run into a web site that requires JavaScript I can turn off NoScript for that site temporarily or permanently.
You think you got it bad? Pity the average web user who has to decide how far to trust a site. Should he allow a redirection? Should he allow java script? Does he even know what web-site he is being redirected to? Should he trust a site secure just because it can pay to get a certificate?
Take api-secure.recaptcha.net for an example. Why should a home user trust them https?
Another vote for FF + AdBlock + NoScript on the client side. Blocking ad servers is always worth doing, and would have prevented the unwanted redirect; but blocking js by domain is the best buy. It's good to know that Facebook cleans third party scripts, so I can safely add facebook.com to my NoScript whitelist.
Now we just need to educate developers to make their sites work properly with javascript turned off.
The reality is that sourcing remote JavaScript into your application is allowing foreign code that you do not control to do whatever it wants. That may include co-opting the user interface, or it could be silently stealing cookies, tracking their behavior, stealing their personally identiable information or even making purchases on their behalf (all depending on what sort of information and interactions are available on the victim's site).
If this sounds like XSS (cross-site scripting), well, that's because it is just a variation on that attack. There is no concept of sandboxing or otherwise limited the privileges of remotely sourced JavaScript.
So if you want to host ads and the like that need JavaScript, the only sane way to do so is via an iframe or similar mechanism that loads remote HTML, that then in turn can contain or source whatever JavaScript it needs.
There is a process problem buried in this, also, and I wonder how many sites have it.
In most companies, things go on the web pages because a request comes in to put them there. Sponsorships, special landing pages, links, partner buttons, and, yes, javascript code like this.
But none of the request/ticket systems (that I've used so far) include a reminder system that lets you set an end date for web content. Marketing sends in a request, the content goes up, and there's probably an end date. But even the web person even knows about the end date, there's not a good solution for remembering to take the content down.
Open tickets clog up the view of what the team has to do, so leaving the ticket open until the campaign ends isn't a good solution. Reminders set up in personal calendars don't work because personnel changes happen, and because the othes on the team need visibility and notifications about things ending.
I want to know how can i can count pages of a website. If i can write some code in Javascript of vbscript to count pages. Recently i heard about an open source code paragent where we can download the code. Any opinions...?
Thanks in advance.
bmora
I am just the average user who has always hated the sneaky side of the internet. Mozilla and No Script.. Kudos.
Post A Comment:
STAY CONNECTED
RECENT COMMENTS
- Cynthia on Dangers of remote Javascript: I am just the average u...
- bmora96 on Dangers of remote Javascript: I want to know how can ...
- Nathan White on Dangers of remote Javascript: I hate frames but in th...
- terrie on Dangers of remote Javascript: There is a process prob...
- Lucas Adamski on Dangers of remote Javascript: The reality is that sou...
- Thejesh GN on Dangers of remote Javascript: Its http://lerdorf.com/...
- Chris Ovenden on Dangers of remote Javascript: Another vote for FF + A...
- Tom Nield on Dangers of remote Javascript: You think you got it ba...
- Adnan Siddiqi on Dangers of remote Javascript: My two cents: tinyurl....
- Improbus on Dangers of remote Javascript: I to run Firefox + NoSc...
RADAR TOPICS
jtimberman [01.19.08 09:50 PM]
And thats why I surf with Firefox + NoScript installed.