[wp-trac] [WordPress Trac] #39941: Allow using Content-Security-Policy without unsafe-inline
WordPress Trac
noreply at wordpress.org
Wed Jul 10 18:04:21 UTC 2019
#39941: Allow using Content-Security-Policy without unsafe-inline
-------------------------------------------------+-------------------------
Reporter: tomdxw | Owner:
| johnbillion
Type: enhancement | Status: accepted
Priority: normal | Milestone: Future
| Release
Component: Security | Version: 4.8
Severity: normal | Resolution:
Keywords: has-patch needs-refresh 2nd-opinion | Focuses: javascript
-------------------------------------------------+-------------------------
Comment (by alinod):
Replying to [comment:34 epicfaace]:
> What if we instead created a nonce that is only used for scripts loaded
from WordPress Core, and thus cannot be accessed by the developer for use
by arbitrary scripts? What do you think, @jadeddragoon and others?
It seems to me that you might be missing the definition of a nonce. A
nonce is a number used only once. The [https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src MDN reference]
explains it pretty well:
>**'nonce-<base64-value>'**
>A whitelist for specific inline scripts using a cryptographic nonce
(number used once). The server must generate a unique nonce value each
time it transmits a policy. It is critical to provide an unguessable
nonce, as bypassing a resource’s policy is otherwise trivial. See unsafe
inline script for an example. Specifying nonce makes a modern browser
ignore 'unsafe-inline' which could still be set for older browsers without
nonce support.
Therefore a new random value must be generated for each inline script and
it must be unique across page requests. In addition, a CSP header must be
issued that contains the exact same nonce that was randomly generated for
each inline script. Without these controls, the CSP is not providing any
protection since it would be trivial to circumvent. Clearly, any kind of
page caching would break the site, if nonces are used.
Hashes are a much better choice. However, it is imperative that the hash
is a static value that only changes when upgrading to a new revision of
WordPress; calculating the hash at runtime based on the existing content
of the inline script is no safer than using 'unsafe-inline'. We would
essentially be telling the browser to trust everything in the inline
script, regardless of whether it is malicious or not. Worse, this would
mask the underlying vulnerability and give users a false sense of
security.
Security practitioners like to call this "security theatre" and for good
reason.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/39941#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list