Allow for customized SRI Algorithm

[wkaskie]

Command

build

Description

Currently, configuration allows for setting subresourceIntegrity to true and this adds a sha384 hash to the html output's script tags.

However, sha384 is not supported in all platforms and/or frontend developers cannot control the deployment servers. (eg: AWS S3 doesn't allow for sha384 with its checksum-algorithm flag)

Request is to allow overriding of the default sha384 that is set here:

angular-cli/packages/angular_devkit/build_angular/src/tools/webpack/configs/common.ts

Line 254 in 20411f6

if (subresourceIntegrity) {

Describe the solution you'd like

Two options:

• given that custom webpack configurations are already alowed and plugins added there are already expected to override the defaults, allow the existence of

   plugins: [
    new SubresourceIntegrityPlugin({
      enabled: true,
      hashFuncNames: ['sha256'],
    }), 

to override the hardcodedd configuration.

• Add additional configuration parameter for overriding the hashFuncNames setting like:

         ...,
        "subresourceIntegrity": true,
       "hashFuncNames": ["sha256", "sha512"],
       ...
  

### Describe alternatives you've considered

I have tried adding the plugin in my custom webpack.config.js file.
I've also tried to completely rework the settings in Angular to allow for a fully customizable index file...but I honestly just lack the skill to get that to work.

[alan-agius4]

AWS S3 uses checksums like SHA-256 and CRC32 internally to ensure data integrity during storage and transfer, verifying that files are not corrupted during upload or download.

However, these checksums are unrelated to Subresource Integrity (SRI). SRI is a browser feature that ensures resources served to a web page have not been tampered with by verifying their cryptographic hash. This functionality is handled entirely by the browser and is independent of the hosting provider.

[wkaskie]

I already have a working test. What you missed is the new use of the checksum-algorithm flag to add a checksum that will be added to the file that can be used with the integrity attribute for src files.

That is the feature that is missing.

[alan-agius4]

I already have a working test. What you missed is the new use of the checksum-algorithm flag to add a checksum that will be added to the file that can be used with the integrity attribute for src files.

I’m not entirely sure I understand what you mean. Could you please elaborate?, what is the error that you are seeing?

[clydin]

In addition to what @alan-agius4 mentioned above, the Subresource integrity specification mandates that implementations support all the following algorithms: SHA-256, SHA-384, and SHA-512.
Reference: https://www.w3.org/TR/SRI/#cryptographic-hash-functions

[alan-agius4]

Closing due to the lack of communication.

[wkaskie]

Sorry for the delayed response. There was a major holiday in the USA from Thursday to Sunday and I was AFK.

@clydin I am aware of the spec. The PR referenced above allows for all 3 specifications to be used and will continue to default to sha384.

@alan-agius4 to explain further, given the following scenario:

• Frontend for web app uses Angular
• Backend is hosted in a K8s cluster via AWS that renders the FE source
• Each of the bundled Angular files are hosted on S3 (main.js, polyfill.js, etc.)
• subresourceIntegrity is set to true in the Ng configuration
• index.html has an integrity attribute added to each top-level script tag
• Integrity check fails and the site will not load

Why? AWS S3 does not support SHA384 checksum.

AWS S3 sync command does support SHA256. So the following situation works:

• push source files to S3 with -checksum-algorithm=sha256
• create the integrity value for the Ng files using sha256
• add the integrity attribute with sha256-<the checksum>
• page loads fine, integrity check passes

That is just an AWS S3 example, but I would presume there are other reasons to use either SHA256 or SHA512 with an Angular Build.

[jkrems]

@wkaskie Since the browser validates the checksum, there appears to be two possible reasons why the check fails: Either the resources are modified during upload or the HTML file is modified during upload. If either of those two things happens, do we know why it behaves differently with a different hash algorithm?

Integrity check fails and the site will not load

Is this step not happening in the browser? I can't find a reference to anything that would pass the integrity values to request headers, so it's unclear how AWS would even know which hash algorithm has been used. Do you have documentation on how AWS knows about the algorithm mentioned inside of the HTML text?

[alan-agius4]

To expand on the above, the --checksum-algorithm is unrelated to SRI. They are two distinct file checksum methods. The --checksum-algorithm is applied during upload phase and managed by AWS, while SRI is entirely handled by the browser.

As @jkrems mentioned, if SRI is failing, it's likely that the file's contents are changing during upload or while being served.

[wkaskie]

The file contents aren't changing. I can validate the sha384 manually. It appears that S3 simply doesn't know what the sha384 value is unless I upload it with the --checksum-algorithm flag.

To reproduce:

• Build an angular app with sri: true
• Note the integretity values are added with sha384
• upload all files to s3 bucket (no flag)
• change the ref to point the s3 bucket (note that we use a CDN and the base url is modified as part of a build setting)
• note the failure to load based on failed integrity check.

Then:

• with the same app, manually get the sha256 for any one file
• re-sync that file to s3
• manually paste the sha256 value into the integrity attribute value
• change the prefix to sha256
• Note that it works just fine