[Proposal] Subresource Integrity Security (SRIS)

Hey there!

Intro & problem

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.

Partial or final solution

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.

Design

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.

use case

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.

<!--- css --->
<link href="https://cdn.helloworld-libs.net/npm/bootstrap@5.3.0-alpha1/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-GLhlTQ8iRABdZLl6O3oVMWSktQOp6b7In1Zl3/Jr59b6EGGoI1aFkw7cmDA6j6gD" crossorigin="anonymous">

<!--- web-component --->
<link rel="import" href="https://cdn.helloworld-libs.com/ajax/libs/webcomponents/demo.html">

<!--- javascript --->
<script src="https://cdn.helloworld-libs.net/npm/@popperjs/core@2.11.6/dist/umd/popper.min.js" integrity="sha384-oBqDVmMz9ATKxIep9tiCxS/Z9fNfEXiDAYTujMAeBAsjFuCZSmKbSSUnQlmh/jp3" crossorigin="anonymous"></script>

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.

<!--- css --->
<link href="https://cdn.oauth-helloworld-libs.net/npm/bootstrap@5.3.0-alpha1/dist/css/bootstrap.min.css" rel="stylesheet" crossorigin="anonymous">

<!--- web-component --->
<link rel="import" href="https://cdn.oauth-helloworld-libs.com/ajax/libs/webcomponents/demo.html" crossorigin="anonymous"></script>

<!--- javascript --->
<script src="https://cdn.oauth-helloworld-libs.net/npm/@popperjs/core@2.11.6/dist/umd/popper.min.js" crossorigin="anonymous"></script>

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.

Issues

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.

Could you describe the proposal in more layman’s terms? What do you mean by user consent?

Yes. In this proposal I am demonstrating a way to generate the hash value in the integrity attribute automatically without having a specific hash value. Instead of generating a hash for each separate file, we could use authentication protocol like oauth to authenticate multiple files with a user-customizable hash. This prevents someone from changing the hash value if they have access to the file on the cdn network or access to the user’s machine.

For example, let’s say you go to a about cat food site and then to a sports site. It may be that when accessing these two sites there is the same javascript library. With oauth-cdn or SRIS(Subresource Integrity Security), you are guaranteed to have a single library when accessing any website. If both sites use the same version of the library or not - because websites can be the providers of access to the library.

What I call user consent is the process of trust that the user has when accessing any site or logging in. Also, this user consent process is done with a cdn network and a library access provider with the protocol: oauth. For example, the public or private sites say which libraries you have access to or when you will have access. It’s similar to a cookie popup, only instead of cookies there are static files like css, js.

This means, in general terms, that you only access the site that you trust. Knowing that there will be a process in which the libraries or statistical files were verified by the administrator, team, company of the site. The cdn network is only safe if the public or private sites are library access providers.

This can only be done if the cdn network implements the oauth protocol, and the site is also a client-cdn-oauthn.