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

Thanks John.  These are great points.  Policy generation is certainly easier
when whitelisting origins than it is in the nonce model.  Browsers might
also be able to help suggest policies based on the behavior they observe.

Adam
 On Jan 23, 2011 6:02 PM, "John Wilander" <john.wilander@owasp.org> wrote:
> 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 05:28:03 UTC