Hi Tom, On Sun, Feb 12, 2012 at 6:43 PM, Tom Ritter <[email protected]> wrote:
> So imagine we wrote all our our normal javascript, including all the fancy > animation stuff, and cajoled it. And we likewise wrote our crypto > javascript and cajoled it separately. It seems like it would be very > difficult, if not impossible to have UI javascript that couldn't reach out > into the document object and then into the cajoled crypto javascript, but > let's say we still managed to do it. Any HTML injection flaw (XSS if you > wish) could still reach into the cajoled crypto code and fudge with it. > Let's say you did that. You would have (say) a crypto module C, and a user interface module U, cajoled and executed separately. The remainder -- the stuff that calls and runs C and U, and sets up any communication between then -- is then properly thought of as a microkernel. The question then boils down to the following -- 1. To what extent are C and U vulnerable to the various Web attacks? Caja generally ensures that the various dangerous spellings of "eval" that the HTML DOM makes available to your code are neutered. It does not do so to protect a particular module like C and U from its own errors; we have deliberately relaxed this goal in the interests of Web compatibility. Rather, it does so to make sure a module like C and U cannot have global effects that damage the state of the entire page or affect other modules. As a side effect, the current version of Caja which "cajoles" code on the server before sending it to the client does not support "eval" in any form, and so protects a module from XSS. Our most modern version of Caja, which runs entirely on the client using the new ECMAScript 5 features, will support more run-time "eval" semantics. This means that a module can indeed become vulnerable to XSS if it is careless with how it turns runtime strings from the user into code. 2. To what extent does an attack on U affect C, and vice versa? Regardless of which version of Caja you're using, U and C are isolated except insofar as the microkernel puts them into contact with each other. This is true even when U and/or C are provided with DOM functionality via Caja. The specific APIs that put U and C into contact then become crucial. 3. To what extent is the microkernel independently vulnerable to the various Web attacks? The microkernel should be coded very carefully, specifically for the reason that it runs with full privileges over the entire page. What careful coding means will vary depending on the application, but it's fair to say that the more "micro" the kernel, the more auditable it is. Hope this helps. Ihab -- Ihab A.B. Awad, Palo Alto, CA
