We don't need this to be completely sound. We're not seeking to use this mechanism to enforce security control; we just want to allow the creation of tools which warn (us, our tools, other developers) of situations where untrusted data is being used in a potentially dangerous way. Hopefully this means we can, for the time being, ignore some of the harder challenges in creating a completely sound mechanism.
A taint mechanism (even if not perfect - anything is better than what we've got) can help us in two important areas: 1) Manual review. It's easy to review code and test for issues such as DOM XSS in a few trivial applications. It gets hard with large numbers of complex applications using libraries (backbone, zepto, jquery) developed outside of your control. The DOMinator video shows how taint analysis can allow a tester to pinpoint areas of an application that require particular scrutiny. I've used this. It works. Sadly, since it's based on a rather old Firefox, it's now useless on many newer sites. 2) Automation. You'll be familiar with what our fuzzers have done for SpiderMonkey. We're building similar tools for our web sites and, eventually, product frontend (we get DOM XSS in Firefox far more often than we'd like). Taint analysis helps us here because it allows us to build tools which prioritize the fuzzing of the more dangerous inputs and actions. With a change in the way people develop web applications, moving much of the attack surface from the server to the DOM, and the need to rapidly review far more software (thanks to both Marketplace and a growing codebase) any tool that helps, even if not perfect, is a great help. Also, this could be used to make some *awesome* features for our devtools... CCing Paul in case he has any more to add on Firefox OS and / or Marketplace. mgoodwin On 11/08/13 17:26, Jim Blandy wrote: > There's a critical question which I'm afraid I've muddled up in this > thread: *is this analysis actually useful*? I have to admit, I got > distracted by the question of what it would take to get the patch in > shape, and Nicolas's suggestions that we implement it differently. I > appreciate Brendan's putting the question of the thing's *value* at > the center of the discussion. > > I have not used DOMinator; I have talked with Mark and Ivan, who asked > me for help, and watched the video. > > Mark has mentioned using this to assess our own sites' vulnerability > to injection attacks and XSS attacks. Here the site developer is using > it on their own code. So, yes, it's looking for accidental leaks. > > Mark also said something that I didn't understand about helping > fuzzers focus their efforts more effectively; if I haven't garbled > that, it would be nice to hear more about that. > > I've asked Mark and Ivan to post something about their assessment of > the analysis. > > -----Original message----- > > *From: *Brendan Eich <bren...@mozilla.com>* > To: *Jim Blandy <jbla...@mozilla.com>* > Cc: *Nicholas Nethercote <n.netherc...@gmail.com>, > ialagenc...@mozilla.com, > dev-tech-js-engine-internals@lists.mozilla.org, Mark Goodwin > <mgood...@mozilla.com>, dher...@mozilla.com* > Sent: *2013 Aug, Sat, 10 19:43:54 GMT+00:00* > Subject: *Re: [JS-internals] Taint analysis in SpiderMonkey > > Jim Blandy wrote: > > From what our security folks tell me, even taint analyses that > > sometimes drop labels due to simplifications like failing to > taint the > > PC are still valuable. The code under analysis isn't hostile, > > What's the threat model? Accidental leaks? > > /be > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
