Implement subresource integrity (SRI)

[johnbillion]

Chrome 45 (released 1st September) has shipped with ​subresource integrity. Firefox will ship with it in 43 (expected December 2015). Browsers that support SRI will block a script or style resource from loading if the hash of its contents doesn't match the precomputed hash in the integrity attribute for the resource.

We should investigate adding the integrity attribute to core's scripts and styles. While it affords little protection by default (because a hacked site could also have its hashes recomputed), it does protect sites that offload CSS and JS to a CDN.

The hashes can be computed during the build process.

One concern I have is that this introduces a requirement to re-compute the file hash every time a CSS or JS file is changed during development, which will be a complete pain for anyone hacking on WordPress. The answer could be to exclude the integrity attribute when WP_DEBUG is set to true (and thus, only compute the hashes for minified files).

[jorbin]

I could imagine having the hashes update based on the build script. It's not something we would want to manage manually.

​https://www.npmjs.com/package/grunt-sri looks like it could be a start for investigating this.

[dbarlett]

What about adding an optional integrity parameter to wp_register_script(), etc for non-core CSS and JS?

[johnbillion]

@dbarlett Yep that could work. To prevent parameter overload in the wp_enqueue_*() functions it would probably have to end up being some sort of $arguments or $attributes parameter.

Another concern I thought of regarding core implement SRI on core assets: A plugin might be overriding assets with a CDN which might not return exactly the same file as core, and then SRI would block the asset from loading. This might actually be a blocker.

[joe_bopper]

Hi,

I have created and attached a patch that allows the application (and removal) of extra attributes to both a wp_script and wp_style (that is, enqueued <script> and <link> tags). The functions for these are:

$handle = 'my-script';
$attrs = array( 'async'=>'true' );
wp_script_add_extra_attributes( $handle, $attrs );

and

wp_script_delete_extra_attributes( $handle, $attrs );

I've then added a function for the integrity specific case:

function wp_script_integrity( $handle, $hash, $crossorigin = 'anonymous' ){...}

Note: style functions just replace script with style in the function name.

I think this should suitably fulfill this ticket.

It appears to me that the main purpose of SRI is to prevent XSS when using third-party resources (e.g. cdn). Therefore, the need for a function to create hashes for local scripts seems moot (though I'm not against the idea).

Further note: I added a new formatting function esc_attr_name as well. This simply ensures no bad characters are used in attribute names and that it is not the empty string.

Cheers.

[swissspidy]

Sounds like a duplicate of #22249.

[joe_bopper]

There's certainly a large amount of overlap. I'm happy to adjust my patch to fit should the other one be adopted.

[meitar]

In case it's of interest, the WP-SRI plugin (​https://github.com/meitar/wp-sri) has been doing this as a feature plugin for a while.

[GaryJ]

Example attack where SRI could have helped:

​https://scotthelme.co.uk/protect-site-from-cryptojacking-csp-sri/

[johnbillion]

Interestingly, it's unlikely that anyone would have used SRI for that script due to its potentially dynamic nature. ​https://www.troyhunt.com/the-javascript-supply-chain-paradox-sri-csp-and-trust-in-third-party-libraries/

But that's beside the point. I'd like to get some form of SRI support into core. This is probably blocked by #22249.

[Otto42]

+1

This would also be useful for plugins that include code from other sevrices. We've recently had a case where a service had their javascript changed to include coinhive mining code, ostensibly without their knowledge. If wp_enqueue_script included the ability for their plugin to define the integrity hash of that external JS, then the code would have been blocked.

As it is, they can certainly change the plugin to output their own script tag to include such a hash, but having this built into the scripts/styles system would be very helpful.

[zakkath]

Any movement on this?