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

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!


cheers
Dev




>
>>>>>> 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
>>>>>>
>>>>>
>>
>