Saturday, October 15, 2011

Local URIs are more equal than others (Part 1)

On Wednesday, Cedric Sodhi asked the WebKit development mailing list why WebKit restricts access to local URIs.  This post describes one of the reasons why local URIs are more equal than other URIs.  In a future post, we'll revisit this issue when we discuss how local URIs (e.g., file:///Users/abarth/tax2010.pdf) don't really fit cleanly into the web security model.

Although the web platform largely isolates different origins from each other, there are a number of "leaks" whereby one origin can extract information from another origin.  For example, browsers let one origin embed images from another origin, leaking information such as the height and width of the images across origins.  These leaks are often at the core of security vulnerabilities in the platform.

These same leak exists, of course, between local origins (e.g., those with file URIs) and non-local origins (e.g., those with http or https URIs).  What kind of information could a web site extract from your local system using this leak?

On my laptop, I have Skype installed, which means that, on my laptop, the URI below resolves to a PNG image with a particular height and width:
If I visit a web site, if the browser doesn't address this leak, the web site could determine whether I have Skype installed by attempting to load that URI as an image.  On my laptop, the image element would have a certain well-known height and width, but on a laptop without Skype installed, the browser would fire the error event.

Returning to Cedric's question, why do browser vendors restrict access to local URIs but not to non-local URIs if both have the same information leak?  I would prefer to close this leak in both cases, but many web sites embed cross-origin images, e.g. from content delivery networks.  If we were adding the <img> tag today, we would probably require servers opt in to cross-origin embedding using the Cross-Origin Resource Sharing protocol.

Fortunately, very few web sites include images (or other resources) from local URIs (especially after we removed the full path from <input type="file">, but that's a story for another time).  That means browsers can block all loads of local resources by non-local origins without making users sad, preventing web sites from snooping on your local file system.


  1. " If we were adding the 'img' tag today, we would probably require servers opt in to cross-origin embedding using [the CORS protocol]." Is there an easy way to use CORS for such tasks without inventing a JS DSL? Such a perspective suggests CORS isn't integrated into basic APIs, making productive programming unsecure-by-default even with the fix. I hadn't followed the API support for CORS, so I'm surprised!

  2. Leo, I'm not sure I understand your question. The browser needs to help the web site make a CORS request when loading images. For example, there's no way for a web site to attach the Origin header to a request without help from the browser because we want the Origin header to accurately reflect the origin of the requester.

    As to the broader thrust of your question, the default behavior for loading images very likely to remain unchanged (i.e., insecure) because changing the default would likely break every web site.

  3. This comment has been removed by the author.

  4. Hi,
    I read your Great Article. There have great news for every visitor. I like your blog and analysis about it. Thanks for your Posting.
    Enjoy Entertainer Please see the link- radio streaming hosting.

  5. Hello,I am very impress after read your great article.
    greengeeks Coupons