Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Subresource integrity for images and other media?

Subresource integrity seems to be an awesome stopgap allowing to use third-party controlled HTTP-served resources in a secure way.

However the spec considers HTMLLinkElement and HTMLScriptElement interfaces only:

NOTE

A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

I understand that content referred to by script and link elements is more 'active', yet browsers remove the green padlock for fetching even relatively innocuous images via plain HTTP, while the spec chooses to ignore them? This seems to be a massive lack of foresight to me.

What was the reasoning behind this and when can we expect a 'future revision', if at all?

like image 235
minj Avatar asked Jan 27 '16 00:01

minj


People also ask

How do you Subresource integrity?

Using Subresource Integrity You use the Subresource Integrity feature by specifying a base64-encoded cryptographic hash of a resource (file) you're telling the browser to fetch, in the value of the integrity attribute of any <script> or <link> element.

What is integrity and Crossorigin in script tag?

Integrity attribute is to allow the browser to check the file source to ensure that the code is never loaded if the source has been manipulated. Crossorigin attribute is present when a request is loaded using 'CORS' which is now a requirement of SRI checking when not loaded from the 'same-origin'.

What is CSS integrity?

The integrity attribute is used to give permission to the Browser to check the fetched script to make ensure the source code is never loaded. It is used to check that whether the third party has been altered the resource or not.

What is integrity in HTML link?

The integrity attribute allows a browser to check the fetched script to ensure that the code is never loaded if the source has been manipulated.


1 Answers

SRI gives you some guarantees that the resource you're asking for has not been altered. For example if you are loading JQuery from a CDN then you want to be sure no one has modified it to include nefarious code (one of the major downsides of loading code from another site - you are implicitly trusting that site's security). SRI gives you that guarantee.

SRI has nothing to say on how it's loaded. You could just as easily download JQuery over http and get an insecure content alert for that despite the fact it's verified by SRI.

Insecure content is bad for lots of reasons, including:

  1. No guarantees the content hasn't been altered on the wire (which SRI addresses somewhat).
  2. Leakage of cookies (unless protected by Secure attribute).
  3. Leakage of privacy (a snooper knows you've requested that resource).

SRI only addresses that first issue. And even then it only stops it being loaded if it's been altered, and doesn't reduce the chance of it being altered (like https does).

If you want to address insecure content issues then you can look at Content Security Policy instead, either to explicitly block those, or by using the upgrade-insecure-requests directive to automatically upgrade them (for browsers that support this).

like image 78
Barry Pollard Avatar answered Sep 29 '22 14:09

Barry Pollard