So in the ember addon I have explained a little further about the crossorigin attribute usage:
https://github.com/jonathanKingston/ember-cli-sri

Something like:

Crossorigin attribute

When the request doesn't match Same Origin Policy the crossorigin attribute MUST be present for the integrity of the file to be checked.
With an integrity set on an external origin and a missing crossorigin then the browser will choose to 'fail-open' which means it will load the resource as if the integrity attribute was not set.

Values:

• anonymous - A cross-origin request (i.e., with Origin: HTTP header) is performed. But no credential is sent (i.e., no cookie, no X.509 certificate, and no HTTP Basic authentication is sent). If the server does not give credentials to the origin site (by not setting the Access-Control-Allow-Origin: HTTP header), the resource will be tainted and its usage restricted.
• use-credentials - A cross-origin request (i.e., with Origin: HTTP header) performed with credential is sent (i.e., a cookie, a certificate, and HTTP Basic authentication is performed). If the server does not give credentials to the origin site (through Access-Control-Allow-Credentials: HTTP header), the resource will be tainted and its usage restricted.

We should accept scheme-less URLs like code.jquery.com/jquery-1.11.2.min.js and assume that the scheme is http:// before trying to upgrade them to HTTPS.

We should also accept "scheme-relative" URLs like //code.jquery.com/jquery-1.11.2.min.js and assume that the scheme is https://.

We currently use an iframe to return the results of the backend lookup. Since it doesn't need to have any scripts in it, we should sandbox it.

Note: it's already constrained by CSP, but there's no reason not to sandbox it too.

Right now we assume that the sub-resource is a script and we always output a script element.

We should detect stylesheets perhaps from the mimetype or the extension.

Should we still default to scripts? Even when what we got ends with .html and has a mimetype of text/html?

The current implementation does not work with resources hosted on AWS S3.

Reason: AWS S3 only sends access-control-allow-origin in the HTTP response if the original HTTP request has Origin in the header. [1]

Potential Fix: In https://github.com/mozilla/srihash.org/blob/master/lib/helpers.js#L131 it's making HTTP request to fetch resource without Origin header. We can add a Origin header there so the AWS S3 will reply with access-control-allow-origin in headers.

Reference: [1] http://docs.aws.amazon.com/AmazonS3/latest/dev/cors-troubleshooting.html

https://pageshot.net/BqfbQfLoOuvXP7YF/www.srihash.org

Travis doesn't like our jshint config it seems: https://travis-ci.org/mozilla/srihash.org/builds/52579326

This thing should be appeal enough that people want to use it.

Hello, is it possible to add a "select" tag to be able to choose the algorithm?

I have generated the following code using srihash.org for URL https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js:

<script src="https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js"
integrity="sha384-CAN0Iz/H09oATWPeJZclEOAM/nF1cq3DSuAbxi9IMbZIx8m3ERInrpuk11n+lHRq"
crossorigin="anonymous"></script>

When trying to load the page that contains the integrity-checked script, I get the following error in Chrome 50 on Windows:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js' with computed SHA-256 integrity 'vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU='. The resource has been blocked.

I also tried to generate the hash manually (again, on Windows, openssl-1.0.2h), using:

openssl dgst -sha384 -binary Cesium.js | openssl base64 -A

resulting in:

X5EHALkqk8r9hyCKwav7y+6BOUg2dRH90/qSxdytan2SQQB9g8jsYYWLDKzNeKx4

This hash works when loading Cesium.js with Chrome, i.e. the one provided by srihash.org is indeed incorrect.

The incorrect result is due to the combination of two factors:

• Cesium.js from cesiumjs.org is always served with Content-Encoding: gzip, even if the request does not contain Accept-Encoding: gzip.
• srihash.org uses xhr2 to fetch resources, which does not support gzip encoding.

It would be nice if srihash.org could either support fetching gzipped resources, or display a warning instead of an incorrect result in that case.

This could be a good bug for a contributor. :)

npm WARN package.json [email protected] license should be a valid SPDX license expression
npm WARN deprecated [email protected]: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0
npm WARN deprecated [email protected]: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0
npm WARN optional dep failed, continuing [email protected]
npm WARN prefer global [email protected] should be installed with -g
[email protected] node_modules/grunt-copyright

We should link to the SRI developer guide on https://developer.mozilla.org once it exists.

The integrity value of

https://cdn.jsdelivr.net/g/[email protected],[email protected],[email protected](react.min.js+react-dom.min.js)

Should be

sha384-NFvWg391HUzxoyYtBHIFpwz8GQwmfhqOTtkoDntpx1pGfKmWfxwcNFPrjQbEXk9L

But is reported as

sha384-Xq2FD+sjFm4/O+2juF28ku89C4+e85gUKbgx1smo/LtIkjjQmr8oClnpwMs25MOD

Instead of just returning an empty string, we should return a proper message when:

• we ran into problems fetching the resource
• the resource is not eligible for SRI protection

I propose that we no longer provide a "type" directive in the SRI integrity attribute, and instead provide a HTML type attribute:

<script
    src="file.js"
    integrity="sha256-XXXX"
    type="application/javascript; charset=UTF-8">
</script>

RE w3c/webappsec/#176, the optional "type" directive in SRI is intended to prevent the server from having any say in how a script is parsed (GIFAR-style confusion-of-context attacks). It does this by enforcing a failure state, should an unexpected unexpected content-type be served -- even if the hash is valid. In practice, this rule would break the sub-resource whenever a content-type header changes.

Enforcing a parsing rule (via the type attribute), instead of failing outright (per the content-type header), would:

• Continue to prevent content-type confusion-of-context attacks
• Protect against any future confusion-of-context vulnerabilities caused by instructions other than content-type
• Lead to more robust sub-resource handling
• Increase semantic correctness/widen separation of concerns in generated elements
• Remove a potential avenue for the server to probe SRI support
• Allow correct handling of content-type directives (such as "charset")
• Allow library authors to provide one generic SRI-enabled element example for all CDN's, instead of a different element for every CDN (per content-type header)
• Negate the need for a custom parsing rule in mozilla/srihash.org (thus closing #38)

I also propose that use of the type attribute, and disuse of the "type" SRI directive, should be advised as a best-practice.

The current Tap tests have a messy overall structure, and require some pretty crazy nesting for async. Let's make them look good!

Maybe we could use one of the badges, the success one?

Show a warning whenever a non-canonical/uncommon/deprecated content-type header is served.

This will improve SRI portability between CDNs (for example, two CDNs serving the same file with both an application/javascript and application/x-javascript header). It would also make assumptions about a default content-type on the SRI build task easier.

Going further, we should consider picking a single preferred content-type for each file format.

C:\Users\XhmikosR\Desktop>curl -IL https://www.srihash.org/style.css
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
Content-Length: 2577
Content-Type: text/css; charset=utf-8
Last-Modified: Wed, 01 Jun 2016 14:03:50 GMT
Etag: "284860f122a42fcdf92ab821061d4e812b1e639f"
Strict-Transport-Security: max-age=15768000
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Download-Options: noopen
X-Content-Type-Options: nosniff
Cache-Control: no-cache
Date: Wed, 01 Jun 2016 15:29:53 GMT
Via: 1.1 vegur

Also perhaps remove Etag while at it.

Once we have convinced CDN vendors to include the integrity attribute on their sample code pages, we should link to them as "SRI-enabled CDNs".

Is it worth changing the fully test browser link to:
https://w3c-test.org/subresource-integrity/subresource-integrity.html

These tests seem to be far more up to date.

It would be good to have a small test suite that would look at a list of common CDNs and apply the same checks as this app to ensure that resources are eligible.

This would not be part of the main test suite, instead it would be run manually for now.

We should serve a static contribute.json file on srihash.org/contribute.json to tell people how to contribute to this project.

as a follow up from #81

Once the domain name has been acquired.

We should probably be using SRI ourselves :)

But let's wait until the front-end is landed and the styles are stable.

We should have a linter for our CSS files.

Currently one of them has a problem:

Error in parsing value for 'width'. Declaration dropped. badge.css:41

Once we start using client-side JavaScript, we should license it properly so that it doesn't get blocked by LibreJS.

Instructions on how to do that are here:

• https://www.gnu.org/software/librejs/manual/librejs.html#Setting-Your-JavaScript-Free
• https://www.gnu.org/software/librejs/free-your-javascript.html#step3
• https://www.gnu.org/licenses/javascript-labels.html

Write a strict test for the output of generateElement (or a "hash" request from the REST interface).

In particular, we should return an error when the URL returns a 404 status code, but also for anything that's not a 200.

Of course, we should follow redirects, as per #9.

As per the whatyg spec:

• Update the "js" section in lib/resourceTypes.js, with:

application/ecmascript
application/javascript
application/x-ecmascript
application/x-javascript
text/ecmascript
text/javascript
text/javascript1.0
text/javascript1.1
text/javascript1.2
text/javascript1.3
text/javascript1.4
text/javascript1.5
text/jscript
text/livescript
text/x-ecmascript
text/x-javascript

• Add a ".forbidden" section to lib/resourceTypes.js, containing:

text/plain
text/xml
application/octet-stream
application/xml 

• Add a ".forbidden" case to the generateElement switch in lib/helpers.js:

case ".forbidden":
    // Output error message
    break;

We should like to http://caniuse.com for browser support once it includes sub-resource integrity.

We should enforce a CSP policy on this site.

hood might be a good module for that, it's what Firefox Accounts uses.

Once neftaly/npm-sri-toolbox#2 is fixed, we should update the dependencies so that we generate hashes in the new format.

If you put ftp://blah in the URL box, you get an Internal Server Error.

This is what shows up on the console:

Debug: internal, implementation, error 
    {"domain":{"domain":null,"_events":{},"_maxListeners":10,"members":[]},"domainThrown":true,"isBoom":true,"data":null,"output":{"statusCode":500,"payload":{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"},"headers":{}},"message":"Uncaught error","isDeveloperError":true}

Given the recent hash format change, neither my initial patch nor the Chrome Dev channel have support for the spec.

Once it's possible to test this feature using these browsers, we should add instructions on how to do it.

The generator seems to fail in odd ways for certain CSS files:

• 50% of the time it throws a "unknown error"
• The rest of the time it generates a wrong hash

The relevant bug report is Bug No. 1271796. If you need access to the test files, drop me your email address at [email protected], or post it here.

There are multiple issues colliding here, one of them is a suspect bug in FF's hashing routine. You might want to get a CC on that bug.

Now that CORS is required for cross-origin requests, we should issue a warning when it's not there.

It shouldn't be an error because maybe the author will be loading that resource over the same origin, even though that's less likely.

There are three possibilities:

1. Access-Control-Allow-Origin: *: open to everyone, no warning.
2. Access-Control-Allow-Origin: example.com: only works if loaded from example.com or example.net, we should include those in the warning (after sanitizing them of course)
3. No Access-Control-Allow-Origin header: warning that CORS is required for cross-origin loads

I can't find good examples for the second one though, so maybe we should tackle 1 and 3 for now.

C:\Users\XhmikosR\Desktop>curl -IL https://www.srihash.org/style.css
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
Content-Length: 2577
Content-Type: text/css; charset=utf-8
Last-Modified: Wed, 01 Jun 2016 14:03:50 GMT
Etag: "284860f122a42fcdf92ab821061d4e812b1e639f"
Strict-Transport-Security: max-age=15768000
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Download-Options: noopen
X-Content-Type-Options: nosniff
Cache-Control: no-cache
Date: Wed, 01 Jun 2016 15:29:53 GMT
Via: 1.1 vegur

Also perhaps remove Etag while at it.

Currently the "results" iframe is pretty hard to read:

I suggest:

• using either a light color for the text, or using a light background colour
• making the text wrap so that scrolling is not necessary

Merging #138 broke the tests and reverting it didn't fix anything. So it looks like tests are broken (and blocking all deployments) but that this commit doesn't have anything to do with the problem.

If I hash the following asset the service returns a script tag for use:

https://securityheaders.azureedge.net/style-desktop.min.css?v=1.0.2

Dropping the version parameter seems to resolve the problem.

STR

• curl -I srihash.org
• curl -I www.srihash.org

Not sure how redirection is currently configured. Seems like this isn't in the repo.

https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.srihash.org%2F

You could add grunt-html to test locally in the future.

While testing locally with IE9, I noticed some text is missing. It's normal, since you only load a woff.

So, either we use the bulletproff @font-face syntax or we just make sure we have fallbacks everywhere.

/CC @mozfreddyb

We need to parse the content-type header before generating the SRI attribute.

request.result = {
    'content-type': 'text/javascript; charset=UTF-8'
   ...
}
sri.generateHash (request.result);
//=> "<script src="file.js" integrity="type:text/javascript; charset=UTF-8 sha256-..."></script>"

This is a security issue; both XSS and the ability to spoof hashes.

request.result = {
    'content-type': 'text/javascript sha512-fAkEhAsH'
   ...
}
sri.generateHash (request.result);
//=> "<script src="file.js" integrity="type:text/javascript sha512-fAkEhAsH sha256-rEaLhAsH"></script>"

I'm mad at myself for not noticing this earlier.

At the moment we currently fallback to js for unrecognized content-types, and output a <script> tag:

<script src="hello.pdf" integrity="type:application/pdf sha256-ZZZZ"></script>

I propose that for unrecognized content-types we generate only the attribute itself:

integrity="type:application/pdf sha256-ZZZZ"

In the future, we can differentiate the output even further:

Please insert the following attribute into your element:
integrity="type:application/pdf sha256-ZZZZ"

If you put http://feeding.cloud.geek.nz/rss.xml in the search box (an invalid URL that returns a 404), the application crash with the following stack trace:

Debug: internal, implementation, error 
    TypeError: Uncaught error: Not a string or buffer
    at Hash.update (crypto.js:209:17)
    at digest (/home/francois/devel/srihash.org/node_modules/sri-toolbox/generate.js:28:14)
    at /home/francois/devel/srihash.org/node_modules/sri-toolbox/generate.js:48:42
    at Array.map (native)
    at hashes (/home/francois/devel/srihash.org/node_modules/sri-toolbox/generate.js:47:14)
    at Object.main [as generate] (/home/francois/devel/srihash.org/node_modules/sri-toolbox/generate.js:56:32)
    at /home/francois/devel/srihash.org/lib/helpers.js:172:32
    at XMLHttpRequest.processResource (/home/francois/devel/srihash.org/lib/helpers.js:86:12)
    at XMLHttpRequestEventTarget.dispatchEvent (/home/francois/devel/srihash.org/node_modules/xhr2/lib/xhr2.js:64:18)
    at XMLHttpRequest._setReadyState (/home/francois/devel/srihash.org/node_modules/xhr2/lib/xhr2.js:340:12)

We should ensure that we follow redirects and hash the final destination.

Note that #8 should note be understood as blocking redirects. The policy of accepting only 200s applies to the final destination.

Serve wildcard CORS headers from hapi -- particularly the "generate" route.