How can I constrain or limit 3rd party Javascript (*.js) files that can DOS my site?

Question

Many website owners integrate Google analytics, various Facebook or Twitter social media javascript plug ins into their web pages. The problem is that this trust seems to be "all or nothing", meaning that there are no limits or structure as to what the 3rd party site is permitted to do.

In addition there doesn't appear to be any structured exception handling (SEH) available for Javascript anytime independent website author's scripts reside on the same web page.

Example

On 2/7/13 several sites that integrate with Facebook effectively DOSed half of the Internet, rendering several sites unusable. I think this problem could be avoided if 3rd party javascript could be constrained (as defined by the website owner and honored by the browser), and/or there was a variation of meta-Structured Exception Handling for Javascript.

Question

• Is there any research or proposal that attempts to constrain or control 3rd party javascript at any level?

• What working group (W3C, RFC group, vendor, etc) is the most appropriate for formally proposing and defining a standard for 3rd party javascript controls?

Answer 1

No. In practice, there is no good solution to this problem. If you include a third-party Javascript library into your web page (via <SCRIPT SRC=...>), you are trusting that Javascript. That includes trusting it not to DoS you. That's just how it works, and there's no solution, given the current browser security model.

If you don't trust the third-party Javascript, don't embed it into your web page. That's the only reasonable solution today.

(In principle you could use Caja, but it's a pretty complex mechanism: this is a bit like using a cannon to shoot a fly.)

Answer 2

First, this seems to have originated from a mistake by someone at facebook who has access to update their JS scripts to their CDN that was not noticed/fixed by someone at facebook for 15-20 minutes. I doubt it was a malicious attack (as it only redirected to an error page and only applied to people currently logged into facebook rather than everyone).

So solutions like Content Security Policy are not relevant as the various websites deliberately decided to include the facebook-connect javascript on their page and want it to run. Content Security Policy merely limits which domains are allowed to execute code to mitigate XSS.

Similarly, I doubt facebook is going to adopt Douglas Crockford's ADSafe (or run their code through google-caja), and even if they did or wrote their own code, they would probably still serve both from their CDN. So you would still have to fundamentally trust facebook for technical competence.

The best solution is to hesitate before allowing third parties to load code onto your page. Do you really need an active Facebook Like/Share button on every page? Could you just include a static link to like your organization on facebook, and expect people to share content by copying the URL into their facebook feed?

Maybe grab a static version of their javascript files that works properly; though this could be problematic if (a) they stop supporting old versions of their JS files or (b) they have a check (possibly through CSP) that the script was being served from their CDN (though I do not think CSP can do this at the moment) or (c) the static version you pulled had troublesome code that you didn't like.

My guess is that facebook will treat this lapse seriously and it likely won't happen from them again soon. They should do things like require their scripts to be served via https only, and undergo significant automated and manual quality testing before deploying -- e.g., no code goes live if it hasn't passed days of testing (bug fixes shouldn't be deployed live but revert back to the last working version).

Answer 3

Perhaps this can help you.

http://www.adsafe.org/ - ADsafe makes it safe to put guest code (such as third party scripted advertising or widgets) on a web page. ADsafe defines a subset of JavaScript that is powerful enough to allow guest code to perform valuable interactions, while at the same time preventing malicious or accidental damage or intrusion.

• https://github.com/douglascrockford/ADsafe

http://code.google.com/p/google-caja/ - Compiler for making third-party HTML, CSS and JavaScript safe for embedding

• Sounds very good, but 3rd party code has to be sent to a Caja server (Google also provides one) for "compiling".

Answer 4

I'm not sure if i understood your question correctly, but there is already a system that controls from which domains JavaScript will be accepted.

If you are the owner of a website, then you can add the Content-Security-Policy (CSP) to the header of your pages. In the CSP you can define the domains, from whose a page accepts JavaScript. If the users browser supports the CSP (Firefox since version 4), then JavaScript will not be loaded from other than the defined domains. So JavaScript libraries from google.com could not load other libraries from example.com.

There are a lot of other options in CSP, it depends on the browser if they are respected or not.