W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2016

Re: Finalizing the shape of CSP ‘unsafe-dynamic’

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sat, 4 Jun 2016 16:27:53 -0700
Message-ID: <CAPfop_3wD5D4d_Mp5a+uj_BfdrzN_YhsVmZWghh=RLvN3f-4qA@mail.gmail.com>
To: Artur Janc <aaj@google.com>
Cc: Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Daniel Bates <dabates@apple.com>, Devdatta Akhawe <dev@dropbox.com>, Mike West <mkwst@google.com>
heh .. which brings me to the original question in the thread:

>>>>>> 2. Change the name, but otherwise leave the behavior as specified.
>>>>>> Some possibly better names that have been thrown around were
>>>>>> ‘allow-dynamic’, ‘trust-dynamic’, ‘dynamic-nonce’ and my favorite
>>>>>> ‘safe-dynamic’ ;-) (okay, maybe the last one won’t fly)
>>>>>> 3. Change the behavior to make the feature more understandable to
>>>>>> developers. Ideas for this included introducing another directive (rather
>>>>>> than using script-src), or splitting ‘unsafe-dynamic’ into two keywords
>>>>>> (e.g. ‘drop-whitelist’ and ‘propagate-nonces’) -- each of those comes with
>>>>>> its own set of challenges, but they are probably solvable if it seems like
>>>>>> this is the way to go.
I am a fan of #3 over #2. CSP is already pretty confusing and I value
anything that tries to make it simpler. I can also see some value of
whitelisting one particular JS file via uri or hash and then allow-dynamic.
'drop-uri-src' and 'allow-dynamic' seem good keywords to start with.

Other than that, this is great. thanks for driving this!


>>>>>> My choice would be #2, i.e. to change the name, which AFAIK was the
>>>>>> only strong concern raised in our discussions, but otherwise leave the
>>>>>> behavior as currently written in the spec. But if anyone feels strongly
>>>>>> about #3 or has ideas for a cleaner way to accomplish the same goal, it
>>>>>> would be great to discuss it now.
>>>>>> Cheers,
>>>>>> -Artur
>>>>>> [1] https://w3c.github.io/webappsec-csp/#unsafe-dynamic-usage
>>>>>> [2]
>>>>>> https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0048.html
>>>>>> [3]
>>>>>> https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22
>>>>>> In a recent review of CSP deployments in the wild we observed that
>>>>>> 75% of whitelists contain origins which allow such CSP bypasses because of
>>>>>> Angular/JSONP endpoints. As a result, >95% of current CSP policies offer no
>>>>>> benefit from markup injection/XSS.
>>>>>> [4] https://www.w3.org/TR/html5/scripting-1.html#parser-inserted
>>>>>> The reason to allow only non-parser-inserted APIs to be in scope of
>>>>>> ‘unsafe-dynamic’ is that parser-inserted APIs (Element.innerHTML,
>>>>>> document.write()) tend to suffer from XSS, which would allow attackers to
>>>>>> still exploit such bugs.
>>>>>> [5] https://csp-experiments.appspot.com/unsafe-dynamic
Received on Saturday, 4 June 2016 23:28:41 UTC

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