Saturday, October 22, 2011

X-Script-Origin, we hardly knew ye

On Thursday, Robert Kieffer filed an interesting bug in both the WebKit and Mozilla bug trackers:
WebKit and Mozilla browsers redact the information passed to window.onerror for exceptions that occur in scripts that originate from external domains. Unfortunately this means that for large institutions (like us here at Facebook) that use CDNs to host static script resources, we are unable to collect useful information about errors that occur in production.
Why do browsers redact this information in the first place?  The answer is actually a combination of two factors:
  1. Although browsers generally prevent one origin from reading information from another origin, the script element, like the image element, is a bit of a loophole: an origin is allowed to execute a script from any other origin.  (This exception has wide-ranging implications on both security and commerce on the web.)
  2. The script element ignores the MIME type of resources it loads.  That means if a web page tries to load an HTML document or an image with the script element, the browser will happily request the resource and attempt to execute it as a script.
At first blush, these two facts would seem to imply a serious security vulnerability.  Certainly executing a script leaks a great deal of information about the script and ignoring the MIME type means a malicious web site can cause the browser to execute any resource, regardless of the sensitivity of the resource (e.g., an attacker can execute the HTML that represents your email inbox as if it were JavaScript).

Fortunately, we're able to snatch security from the jaws of vulnerability because of a happy coincidence: resources that contain sensitive information happen to fail to parse as valid JavaScript (at least usually).  For example, your email inbox probably consists of HTML that quickly throws a SyntaxError exception when executed as JavaScript.  (The consequences of expanding JavaScript to include HTML-like syntax is an exercise for the reader.)

Returning to our original question, we now understand that (in an attack scenario) sensitive information actually flows though the JavaScript virtual machine, where it generates an exception.  That exception is then processed by window.onerror!  If browsers did not redact the information they give to window.onerror, they would potentially leak sensitive information to malicious web sites.

How, then, can we address Robert's use case?  Certainly we would like web sites like Facebook to be able to diagnose errors in their scripts.  Robert suggests an "X-Script-Origin" HTTP header attached to the script that would indicate which origins are authorized to see exceptions generated by the script.  Although that would work, that solution seems overly specific to the problem at hand.

A more general solution is for the server hosting the script to inform the browser which origins are authorized to learn sensitive information contained in the script.  (Typically servers would authorize every origin because scripts are usually the same for every user).  We already have a general mechanism for servers to make such assertions: Cross-Origin Resource Sharing.  We can address Robert's use case by adding a crossorigin attribute to the script element that functions similarly to the crossorigin attribute on the image element.  Once the embedding origin is authorized to read the contents of the script, there's no longer any need to redact the exceptions delivered to window.onerror.


  1. Wouldn't the CDN be opting-in to receiving DELETE and PUT requests (and don't know what else) from FB for those images? Enabling CORS seems like a big hammer solution.

    Also, "snatch security from the jaws of vulnerability " is hilarious!

  2. CORS is relatively fine-grained. I'd expect CDNs to just send the Access-Control-Allow-Origin: * header, which makes the resource publicly readable but doesn't opt in to any crazy stuff like DELETE or PUT methods.

  3. I¡¦m no longer sure where you are getting your info, but great topic. I needs to spend a while studying much more or understanding more. Thanks for wonderful info I was in search of this information for my mission.

  4. Hi,I am tina martin ,I am very impress your blog post. and thanks for share it.

    Hostgator Coupon .

  5. This is a great post ! it was very informative. I look forward in reading more of your work. Also, I made sure to bookmark your website so I can come back later. I enjoyed every moment of reading it.
    baju batik modern baju batik baju batik wanita batik pekalongan batik couple batik online batik modern gamis batik


  6. Thanks for Nice and Informative Post. This article is really contains lot more information about This Topic. -
    Packers and Movers in Hyderabad
    Packers and Movers in Pune
    Packers and Movers in Mumbai

  7. I read this article. I think You put a lot of effort to create this article. I appreciate your work.
    Black Magic Specialist

  8. I think this is an informative post and it is very useful and knowledgeable. therefore, I would like to thank you for the efforts you have made in writing this article.

  9. This is a very good post which I really enjoy reading. It is not every day that I have the possibility to see something like this.
    Startup investment in India

  10. You have a very inspiring way of exploring and sharing thoughts. Really Motivating.
    Buy high pr backlinks

  11. I like this a lot. Thank you for sharing. I'm always looking for upcycles like this. In the end, you don't know it was a shipping pallet to begin with!
    IPL 2016 Auction
    IPL 2016 Auction Live
    2016 IPL Auction