W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2013

Re: CSP and innerHTML

From: Ian Melven <imelven@mozilla.com>
Date: Thu, 2 May 2013 10:44:34 -0700 (PDT)
To: Brad Hill <bhill@paypal-inc.com>
Cc: WebAppSec WG <public-webappsec@w3.org>
Message-ID: <1952518362.14163986.1367516674017.JavaMail.root@mozilla.com>


that was my first question as well.

some examples raised were 'defacement' ie altering the appearance of the page (which I know in general
has been considered 'not a goal/out of scope' for CSP) and a DoS/possible spoofing? by injecting a div
with a class that would cause it to overlay real content due to existing CSS rules. The other
point that was raised, which I think is more compelling, is the idea of 'defense in depth', ie.
if there's a bug or edge case in a script or style blocking implementation still couldn't be exploited
via an innerHTML injection.

Note also that this idea was raised in the context of apps, not web content, where
DOM injections may be a little more serious perhaps ?


----- Original Message -----
From: "Brad Hill" <bhill@paypal-inc.com>
To: "Ian Melven" <imelven@mozilla.com>, "WebAppSec WG" <public-webappsec@w3.org>
Sent: Tuesday, April 30, 2013 11:17:15 AM
Subject: RE: CSP and innerHTML

I'm interested in an example attack this would stop, which depends uniquely on inner/outerHTML.

The only use I can think of for this off the top of my head is if you're attempting to use a supervisory script to monitor and approve changes to the DOM  - which the implementation details of innerHTML typically do an end-run around.  Otherwise, isn't innerHTML functionally equivalent to other DOM-based APIs?  (and shouldn't the internal implementation be subject to the same CSP constraints already?)


> -----Original Message-----
> From: Ian Melven [mailto:imelven@mozilla.com]
> Sent: Tuesday, April 30, 2013 11:08 AM
> To: WebAppSec WG
> Subject: CSP and innerHTML
> Hi,
> recently Jonas Sicking raised the idea of having a CSP directive that would
> block usage of innerHTML
> the primary motivation for doing this seems to be additional defence in
> depth on top of CSP already restricting script and style injections
> i'm curious what others think of this idea and looking for feedback :)
> thanks,
> ian
Received on Thursday, 2 May 2013 17:45:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:33 UTC