Subresource Integrity (SRI) is a W3C specification that allows web developers to ensure that resources hosted on third-party servers have not been altered. When using Subresource Integrity (SRI), the webpage holds the hash and the server holds the file (the .js file in this case). The browser downloads the file, then checks it, to make sure that it is a match with the hash in the “integrity” attribute. If it matches, the file is used, and if not, the file is blocked.
The problem I see with Subresource Integrity (SRI) is that this process is added in an html string by “integrity” atrribute with value “SHA-384-hashValue”. Also, this process is done without the user’s consent. In addition to these two central problems, there are other problems such as:
- Hash collision attacks: Digests are only as strong as the hash function used to generate them. It is recommended that user agents refuse to support known-weak hashing functions and limit supported algorithms to those known to be collision resistant. Examples of hashing functions that are not recommended include MD5 and SHA-1. At the time of writing, SHA-384 is a good baseline.
- Non-secure contexts remain non-secure: Integrity metadata delivered by a context that is not a Secure Context, such as an HTTP page, only protects an origin against a compromise of the server where an external resources is hosted. Network attackers can alter the digest in-flight (or remove it entirely, or do absolutely anything else to the document), just as they could alter the response the hash is meant to validate.
The proposal written here solves the problem of the topic above: user consent and greater security and automation to Subresource Integrity (SRI). Furthermore, it provides a special case of using the open protocol oauth for SRI automatically, without the need for integrity attribute with the hash value in html.
Oauth is a good security consideration as the hashes would be unique. Thus avoiding Hash collision attacks - because with oauth you to share or download libraries between websites without exposing your hash. Also, It’s a widely-adopted standard that’s used by developers of websites and apps, and you probably use services every day that utilize OAuth.
I would like to point out that this proposal is an early draft and is not a complete replacement for the integrity attribute in html. In other words, it doesn’t cancel the previous proposal, but it adds more features. This proposal I believe it is interesting for some reasons:
the initial advantage is that each cdn can be an authentication provider for certain libraries, css and static files - this allows users and developers to get closer.
is it possible that the user has the possibility to authenticate js libraries, css etc - directly on a public or private cdn network on any website, web-app etc. Which guarantees greater consent, security of the site for the user and from the user to the site. The previous proposal, the Subresource Integrity (SRI) proposal does not have this feature or this idea. Although there is no such idea or resource, this proposal - it is still an alternative, complement or solution to SRI with Oauth or I call this “Subresource Integrity Security (SRIS)”. For example:
a cdn type public or private network validates access to html metadata and other static data for users, developers or anyone . This allows for greater control and licensing as well from users to developers and from developers to users etc.
the advantage of using a cdn-oauth network is security, consent and content licensing for developers, users, home users, end users etc. Oauth is an open protocol to enable secure authorization in a simple and standard method for web, mobile and desktop applications - in my view this should happen for static libraries on a public or private cdn network as well.
before - without oauth in integrity attribute:
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. The problem here is that it is not possible to authenticate js libraries, css etc.
after - with oauth in integrity attribute (now, we have):
Every time someone accesses a site or logs into a site, they need to authenticate the libraries and other html metadata.
The proposal here is Subresource Integrity Security (SRIS) or Subresource Integrity (SRI) with Oauth. The “integrity” is
oauth for authentication method in an url for cdn, instead of
sha384- value by default.
The identification would be valid for any website in a unique way. One perceived problem is that people may not want to authenticate to each site.