On 30 December 2011 17:05, John J Barton <[email protected]>wrote:
> > > On Fri, Dec 30, 2011 at 3:53 AM, David Bruant <[email protected]> wrote: > How did this competition begin? > > A use case for JS security environment is loading app components > cross-site. The other site is 'trusted' in that you believe it has code > helpful to the user. But you want to limit its control, for reliability > rather than security in the normal sense. Is this what you have in mind? > > >> What I've said before applies and even against an XSS attack, you can >> prevent cookie theft as long as you run first. >> I can't see a way for the browser to enforce that trusted code run before >> untrusted code. >> > > What causes 'untrusted' code to run at all? You must be doing something to > cause the browser to load code outside of normal methods. That 'cause' is > running first. > > To put this another way, what ever runs first *is* the trusted code. > I believe me and Mario Heiderich have solved this problem with JSLR: <http://www.businessinfo.co.uk/labs/jslr/jslr.php> As long as the javascript is executed first then you can protect the page from untrusted javascript execution by whitelisting allowed scripts using randomized tokens. Even when the site is vulnerable to type 1 XSS and DOM based XSS, even within href attributes. I have also developed a whitelisted Javascript environment that can extended by simulating real dom objects making it difficult to discover you are in a protected environment. <http://www.businessinfo.co.uk/labs/jsreg/jsreg.html> It might be of interest to the people of this list to check out Mario Heiderich's slides as he discussed how to use ES5 methods to create a safe js environment. https://www.owasp.org/images/a/a3/Mario_Heiderich_OWASP_Sweden_Locking_the_throneroom.pdf
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
