I talked with Doug Crockford, Marcel Laverdet and Scott Isaacs at http://ajaxexperience.techtarget.com/conference/html/security.html#DCrockfordPanel
My slides are at https://groups.google.com/group/google-caja-discuss/web/AjaxExperienceSlides.odp and my talk notes are below. The talk was well attended and people seemed to stay for the full 90 minutes. Each of us gave a 15 minute preso. The questions seemed generally positive. They covered topics like download size of the virtualizing script, readiness for deployment, alternate schemes like securing canvas instead of HTML, and about where policy is enforced (client/server side). The questioners seemed comfortable with the assertion that the same origin policy can't be fixed with band-aids. ============================= Doug explained some problems that the same-origin security policy doesn't address. And this week, you've heard a lot about recent developments in the AJAX world that let people apply the same engineering processes to client side code that have been used for a long time on the back end. But the two don't work together. The same-origin model assumes things that are no longer true. I'm going to try to explain why that is, how AJAX and mash-ups have obsoleted the same-origin policy, and how the projects up here are trying to fill that gap, and how filling that gap the right way can open up new markets for AJAX developers. In the future, I want AJAX app developers who really understand a niche audience to be able to write a custom UI and plug it into a banking site, and have banks able to reasonably trust it with important user data. We're a long way from that today. == Before I get into detail, I'd like you all to keep in mind some requirements I think any new security policy should have. It needs to work with existing tech. Our industry has invested a lot in learning how to write apps using HTML, CSS, and Javascript. Those are here to stay. It needs to support proven development practices. Before AJAX, javascript development was really for toy programs, but now we have a community of specialists: library writers, UI designers, API developers, tools developers; all working together to produce applications that have the same richness as desktop apps. Any new policy needs to address the security problems that Doug outlined, but good security is about finding rules that most honest actors follow intuitively, and that when enforced, build a basis for trust between distant parties. And by allowing distant people to reasonably trust one another, you open up new markets. And finally, you can't solve people's problems by requiring them to understand the details at the same level you do. Any solution must not require Joe developer to have a PhD in IT security. == I don't really, but the many libraries available today: JQuery, prototype, YUI; all show how much web development has changed. Before AJAX, most Javascript apps were small simple things. But now people are writing complex apps, and to do that, developers need to specialize: library writers write libraries, API designers design APIs, UI developers tie them together to make UIs. A lot of different people's code end up in the same soup. But the same origin model only works if all the code comes from one place. I can give my data to the New York Times because I trust them, and by extension their staff of programmers. The same origin policy says that code loaded by site X can muck with data in a page from site X – if the code comes from their site, it was written by their staff, so it doesn't matter whether code written by their staff runs on the server or the client. But today's AJAX apps are mixing together code from many sources. And the mash-up and plugin model today means that the coders responsible for the apps don't even know the sources of all the code. So we need a new way to deal with web security that acknowledges the reality – complex apps have to mix code from many sources. == So how can we provide a stable secure platform for AJAX apps without requiring people to throw away the code they've written and the skills they've learned? Well, code modules need to be able to interact with other code modules without allowing the other module access to all the authority they have. Authority might be the ability to read/change part of a page, or send an XMLHttpRequest to a particular domain, or listen in on keystrokes to a password field, etc. But javascript code assumes certain browser APIs. So we try to let each module of code think it's dealing with a whole web-page, but in reality limit it to dealing with a portion. And then we use an object- capability model to let modules interact with each other – delegate operations – without leaking all the authority they have. This requires virtualizing the browser APIs – the DOM and network APIs, etc. The diagram above shows a lens, magnifying a portion of the DOM. A module on the right of the DOM sees what looks like a full web-page, but in reality, it's a portion of the page that it's dealing with. And as with real lenses, we can not only change perspective, but we can also correct visual defects. The real browser on the left has quirks, but the virtual browser behaves more standards-compliant than the actual browser. == So how does Caja virtualize the browser? Well, an AJAX app is typically a bundle of HTML, CSS, and JS. Browsers are pretty tolerant of messy code, but we want to not only virtualize, but make sure the meaning of the app is unambiguous. So we do a lot of normalization to clean up the input. Then we rewrite the input to limit the gadget to a portion of the real page – all global references get pointed to a fake window object, all DOM IDs and are suffixed to separate them from other modules, and CSS rules are scoped. Then the rewritten app, a bundle of static HTML, and a bundle of javascript, is mixed with user data, and sent to the browser. == This example is fictional – our real rewriting is more extensive. But it illustrates some of the ways we normalize input. … == To recap, any solution needs to (1)work with existing technologies (2)fill the gaps in the same origin model and let people reasonably run AJAX apps where they're afraid to today (3)encourage the adoption of coding practices that scale to complex apps by the AJAX community (4)not require lots of devs to become security experts Now, Scott, who knows more about DHTML than anyone else up here since he invented a lot of it, is going to explain his current project, Web Sandbox, and show us some demos.
