Re: More on XSS mitigation (was Re: XSS mitigation in browsers)

Hi guys!

It's 3 am and I've finally read through these threads and checked most
references too. My 50 cents ...

*Scripts vs Domains*
I think we will have to be very clear in the spec on whether we're trusting
scripts or domains. NoScript is actually NoDomain which I've tried to
explain numerous times but IT people still interpret NoScript as actually
filtering scripts.

*Script Signatures => Canonicalization and Encoding Problems*
If we use hashes such as Eduardo's ACS I'm just guessing we'll run into the
usual mess of canonicalization and encoding before calculating the hashes. I
see years of internationalization issues. Maybe I'm wrong.

*Developers Will Want a Policy Generator*
A key issue for in-the-field success of CSP is how to write, generate and
maintain the policies. Just look at the epic failure of Java security
policies. The Java policy framework was designed for static releases shipped
on CDs, not for moving code, added frameworks, new framework versions etc.
The world of web apps is so dynamic I'm still amazed. If anything, for
instance messy security policies, gets in the way of daily releases it's a
no go. At least until there's an exploit.
   Where am I going with this? Well, we should implement a PoC *policy
generator* and run it on some fairly large websites before we nail the
standard. There will be subtleties found which we can address and we can
bring the PoC to production level while the standard is being finalized and
shipped in browsers. Then we release the policy generator along with policy
enforcement – success!

*We Mustn't Spoil Performance*
Web developers (and browser developers) are so hung up on performance that
we really need to look at what they're up to and make sure we don't spoil
things. Especially load performance now that it's part of Google's rating.
Just as an example you can have a look at the current state-of-the-art for
non-blocking iframe loading, called *Dynamic Asynch Iframe*:

<script> (function(d){ var iframe =
d.body.appendChild(d.createElement('iframe')), doc =
iframe.contentWindow.document; // style the iframe with some CSS
iframe.style.cssText =
"position:absolute;width:200px;height:100px;left:0px;";
doc.open().write('<body onload="' + 'var d =
document;d.getElementsByTagName(\'head\')[0].' +
'appendChild(d.createElement(\'script\')).src' + '=\'\/path\/to\/file\'">');
doc.close(); //iframe onload event happens })(document); </script>

*"The magic is in the <body onload="">: the iframe has no content initially,
so onload of the iframe fires instantly. Then, you create a new script
element, set its source to the JS file that loads the content/ad/widget,
append the script to the HEAD and voila: the iframe content loads without
blocking the main page onload!"*
http://www.aaronpeters.nl/blog/iframe-loading-techniques-performance

*Finally, Response Splitting*
Since it has been discussed before I'd just like to bring response splitting
to the table. That's an attack vector against header policies. A proposed
countermeasure is some form of signed headers.

   Regards, John

-- 
John Wilander, https://twitter.com/johnwilander
Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
<http://owaspsweden.blogspot.com>Co-organizer Global Summit,
http://www.owasp.org/index.php/Summit_2011
<http://www.owasp.org/index.php/Summit_2011>Conf Comm,
http://www.owasp.org/index.php/Global_Conferences_Committee

Received on Monday, 24 January 2011 02:03:58 UTC