By the way, I too ran into this issue when doing a (partial) implementation of BEEP for Firefox. (BEEP is a technique for stopping script injection and is described here: http://www.research.att.com/~trevor/beep.html)
I believe it's going to be necessary to solve this issue if you want to implement security protections like content header restrictions, BEEP, or any other more fine-grained script injection protection. The Torbutton extension sounds important too. My own modifications focused on nsJSEnvironment.cpp. However, I did not have time to finish a correct implementation. Suggestion: have a series of test cases in which you put scripts in various contexts in web pages (handlers, inline, style sheets, chrome, etc.). It would be particularly good to include the examples from Mike Perry where scripts that should not be running are actually running :-). Have a breakpoint at the entrance to the javascript interpreter (I believe there are only two entrances ...) and print a stack trace. If you find that the scripts somehow bypass the breakpoint, make them call a unique/particular function (I used b64sha1) and set a breakpoint there instead. -Trevor On Jan 3, 2008, at 2:19 PM, Jonas Sicking wrote: > This is exactly what makes the bug really hard to fix. I think > trying to > fix this by not firing the listeners is too hard and error prone. > Rather > it needs to be fixed by detecting that we're about to execute a JS > function that is implemented in a context where JS is turned off. Or > some such. So later in the callchain. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
