After presenting an entire chapter on the dangers inherent to running untrusted JavaScript, it would seem bizarre that Web sites would so strongly embrace that very thing. Large Web sites want to tackle the problem of attracting and keeping users. Security, though important, will not be an impediment to innovation when money is on the line.
Web sites compete with each other to offer more dynamic content and offer APIs to develop third-party “weblets” or small browser-based applications that fit within the main site. Third-party applications are a smart way to attract more users and developers to a Web site, turning the site itself into a platform for collecting information and, in the end, making money in one of the few reliable manners – selling and advertising.
The basic approach to a sandbox is to execute the untrusted code within a namespace that might be allowed to access JavaScript functions of a certain site, but otherwise execute in a closed environment. It's very much like the model iPhone uses for its applications or the venerable Java implemented years ago.
Wary developers and weary Web security auditors can find general information about JavaScript and browser security at the Caplet group: http://tech.groups.yahoo.com/group/caplet/.
ADsafe (www.adsafe.org/) is designed to protect a site that may be hosting malicious third-party code such as advertising banners or JavaScript widgets. However, its capabilities do not match other, more mature projects.
Google's approach to in-app sandboxing relies on Caja. Caja uses a capability model to enforce security for untrusted JavaScript. The name plays on the Spanish word for box to create the acronym: capabilities attenuate JavaScript authority. Its major changes to the JavaScript execution environment include immutable objects, reduction of the global environment to a specific code module, and restricted access to sensitive objects and functions.
Caja builds a sandbox around the set of HTML, CSS, and JavaScript that defines some type of functionality – a widget that might display the current weather, stock prices, checking account balances, and so on. The process of creating a sandbox around untrusted code is called cajoling. Content goes into the Java-based Caja tool and comes out as JavaScript file that represents the original content as a single module function. This translation removes unexpected, unknown, and unsafe content.
Caja is hosted at http://code.google.com/p/google-caja/.
Facebook opened up its site for third-party developers to host their JavaScript/CSS/HTML-based applications directly on the Facebook. These applications would not only be served from a Facebook domain but also be able to interact with users' profiles and friends. Unrestrained JavaScript would wreak havoc across the site. So, Facebook JavaScript (FBJS) was created to encapsulate these potentially dangerous third-party applications in a virtual function scope. It also creates a JavaScript-like environment with reduced functionality so that the hosted applications do not attack the site or each other.
FBJS is hosted at http://wiki.developers.facebook.com/index.php/FBJS.
alt1 Note
An entire chapter on the dangers of XSS and no mention of the browser's same origin policy? This policy defines certain restrictions on the interaction between the DOM and JavaScript. Same origin policy mitigates some ways that XSS vulnerabilities can be exploited, but it has no bearing on the fundamental problem of XSS. In fact, most of the time, the compromised site is serving the payload – placing the attack squarely within the permitted zone of the same origin policy.
XSS is an ideal exploit venue for attackers across the spectrum of sophistication and programming knowledge. Attack code is easy to write, requiring no more than a text editor and a cursory understanding of JavaScript, unlike buffer overflows. XSS also offers the path of least resistance for a payload that can affect Windows, OSX, Linux, Internet Explorer, Safari, and Opera alike. The Web browser is a universal platform for displaying HTML and interacting with complex Web sites. When that HTML is subtly manipulated by a few malicious characters, the browser becomes a universal platform for exposure.
XSS affects security-aware users whose computers have the latest firewalls, antivirus software, and security patches installed almost as easily as the casual user, taking a brief moment in a cafe to check e-mail. Successful attacks target data already in the victim's browser or use HTML and JavaScript to force the browser to perform an untoward action. HTML and JavaScript are working behind the scenes inside the browser every time you visit a Web page. From a search engine to Web-based e-mail to reading the news – how often do you inspect every line of text being loaded into the browser?
Some measure of protection can be gained by maintaining an up-to-date browser. The major Web browser vendors continue to add in-browser defenses against the most common forms of XSS and other Web-based exploits. The primary line of defense lays within the Web sites themselves, which must filter, encode, and display content properly to protect visitors from being targeted with XSS.
1. Abbott RP, Chin JS, Donnelley JE, Konigs-Ford WL, Tokubo S, Webb DA, NBSIR 76-1041, National Bureau of Standards, ICST, Washington, D.C Security analysis and enhancements of computer operating systems 1976, 19-
2. Zawinski J, (an early Netscape Navigator developer repurposing a Unix sed quote) http://regex.info/blog/2006-09-15/247#comment-3085 2006