WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #39941, comment 35


Ignore:
Timestamp:
07/10/2019 06:09:36 PM (7 weeks ago)
Author:
alinod
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #39941, comment 35

    initial v1  
    1 Replying to [comment:34 epicfaace]:
     1****Replying to [comment:34 epicfaace]:
    22> 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?
    33It 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:
     
    55>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.
    66
    7 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.
     7Therefore 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, if nonces are used correctly, any kind of page caching would break the site.**''
    88
    9 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.
     9Hashes are a much better choice.  However, it is imperative that the hash be 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.
    1010
    1111Security practitioners like to call this "security theatre" and for good reason.