On Sun, Feb 12, 2012 at 6:43 PM, Tom Ritter <[email protected]> wrote: > I read up about it on the wiki, and I have some questions, but I think > I have answers to, but am not 100% certain, and I don't wish to > misrepresent things. I'm exploring 'secure' javascript cryptography > from every angle I can, and caja came up as a discussion point. Some > of the problems with javascript crypto (but not all[0]) are: > > - Third-Party Problem: Any third party supplying code can poison the > entire runtime > - XSS Problem: Any XSS flaw can poison the entire runtime > > Now, imagine we wrote all our crypto-code and cajoled it. From what I > see in the playground, while the cajoled javascript is opaque (much > like gmail's javascript), there's no way to prevent innocent code (or > perhaps I should say, malicious uncajoled code) from reaching into the > cajoled code and fudging with it. >
To you other point regarding the the defensive code problem - your assumption is correct for Caja by translation (what in our wiki is called es5/3 or ES5 running as an emulation on ES3 browsers) - it is a non-goal for ES5/3 to defend itself against malicious uncajoled code. Specific examples of attack which malicious uncajoled code can carry out include walking the call chain and modify the environment (and as a result invariants) of calling functions and modifying primodial objects like Object and Array. It is a goal for Caja on modern ES5-strict compliant browsers (what we call SES in our wiki) does seek to make cajoled code defensive against malicious uncajoled code. However, we've not made a rigorous attempt to convince ourselves that the implementation currently achieves this goal. 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. > > Are those statements accurate? > > -tom > > > [0] I think all of them (omitting Poisoned Caches) are outlined here: > http://lists.w3.org/Archives/Public/public-identity/2011Dec/0064.html >
