- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Fri, 2 Dec 2016 08:34:55 -0800
- To: whatwg@lists.whatwg.org
On 12/02/2016 08:23 AM, Boris Zbarsky wrote:
> On 12/2/16 11:01 AM, Michael A. Peters wrote:
>> Personally I love CSP but it does not allow inline scripts or inline CSS
>
> Only if you say to not allow them. The default behavior allows them.
> For example, this disallows inline scripts, because script-src is
> explicitly specified without unsafe-inline, but does nothing about
> inline CSS:
>
> <!DOCTYPE html>
> <meta http-equiv="content-security-policy"
> content="script-src 'self'">
> <style>body { color: green; }</style>
> This is green
> <script>alert("I am not alerted")</script>
>
>> I believe there now are CSP parameters that relax those prohibitions but
>> from I understand they are only relaxed when a hash of the inline
>> scripts / CSS is declared in the head.
>
> That's ... not correct. Simple example; compare it to the previous one:
It seems that CSP behavior has radically changed since the last time I
looked at it, which was to create support for it in my php class that
generates web pages using DOMDocument, so I can't comment on what the
current state of it is then.
At least historically, the on* attributes were not allowed, the style
attributes were not allowed, and any script nodes in the body were not
allowed.
They were not allowed for very good reasons - there is no way for the
browser to determine if they are intentional or are the result of a XSS
injection in the web application.
JS and CSS in external files referenced from the head was the only way
to safely determine they were intended and not injected.
If CSP now allows them by default then I am not very happy about that,
as it would greatly reduce the effective security, but it sounds like I
would have to read through the current documentation to further comment
on CSP.
Received on Friday, 2 December 2016 16:35:29 UTC