'Security Through Obscurity' Shouldn't Be Part of Web 2.0

Web2 .0 is coming. It's already here in some places. It's new, it's shiny, it's exciting.

Yes, all this is true. What is also true is that in implementing Web 2.0, and making and deploying extensible, mixmaster-friendly services to leverage for Web 2.0 and beyond, we must not lose sight of basic design and deployment principles. Some of these principles are more native to IT and systems administration and ISP/ASP deployment than to traditional or even web nouveau engineering and rapid prototyping. Here's a good example from the real world, which just came to my attention in the last day or so.

Suppose one is running a popular photo site, designed to host photos and control access to them via the site itself or via an API. If enough detail about how photos were constructed was present in the javascript available via 'View Source', one might learn how to assemble an URL that would be valid for direct access to a picture.

This might not be such a problem, as presumably to see the page in the first place, one must be logged in, or the page must be public, or both. But suppose that the photo (and thus the page) were designated as private. Then it might be the responsibility of the site to make sure that all views of the photo were brokered via the site or its API. One should not be able to construct a photo URL and then access the photo regardless of one's in-site permissions, or one's logged-in status.

The photo above links to its page in my user area on a popular photo site. The photo is designated as 'friends only'. Please note that by linking this photo to its appropriate page on the site, that I am complying with the site's Terms of Service, which I reviewed carefully before making this post. Most people clicking on the photo will either receive a 'sign in to this site' page or a permission-denied page. I am new to the site and haven't located most of my friends there yet.

I think that this photo site is doing a wonderful job enabling use of web 1.5 / web 2.0 functionality. They are making photo sharing accessible to a wide range of folks who found it previously difficult. Their use of some new markup technology is causing it to rapidly mainstream, and be fun to use as well. In all of these things, they are to be greatly commended. However, by separating the workflow of 'display an image' from the workflow of 'authenticate a page', they have made a very common design blunder. I would urge them to review their workflow carefully to weed out any similar slips in dataflow to workflow mapping. Judging by the site that's been put together, they are very savvy folks and can figure it out on their own easily now that it's been pointed out to them.

There are a number of ways that they can alter their workflow without requiring a great deal of information overhead, or significantly altering the site performance. What might be the easiest, depending upon their topology, is simply to create a second DMZ server zone for the servers hosting photos, and only allow the application servers to pull content from them. The page-level javascript would actually open a session to the photo-serving DMZ on behalf of the client, and do an encrypted authorization transaction. There may be some browsers in which this would fall afoul of 'sandbox' rules, and be considered downloading from an 'outside' source, even though the FQDN portion of the hostname would be the same. The site probably knows a great deal about their user community's browser preferences by now, though, and would be in a good position to make that call.

Alternatively, a transaction-key protocol could be implemented which would provide a simple method for a logged-in user's session to register itself (possibly playing off existing code) and have the photo server do a verification lookup that there is a non-expired valid key associated with the session requesting the image.

I don't consider this a 'fatal flaw', otherwise I would have contacted the site directly and discreetly rather than blogging about it. I do consider it a very telling example of why these next-generation services could benefit from a bit of healthy old-fashioned IT paranoia in the design and deployment phases of service engineering. Security through obscurity isn't really security. Relying on it to solve other design problems can build a whole set of dangerous assumptions into a product as it matures and grows.