mozilla / srihash.org Goto Github PK
View Code? Open in Web Editor NEWINACTIVE - SRI Hash Generator
Home Page: https://www.srihash.org/
License: Mozilla Public License 2.0
INACTIVE - SRI Hash Generator
Home Page: https://www.srihash.org/
License: Mozilla Public License 2.0
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.
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
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.
We should probably be using SRI ourselves :)
But let's wait until the front-end is landed and the styles are stable.
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.
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.
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:
content-type
confusion-of-context attackscontent-type
content-type
directives (such as "charset")content-type
header)I also propose that use of the type
attribute, and disuse of the "type" SRI directive, should be advised as a best-practice.
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
Write a strict test for the output of generateElement (or a "hash" request from the REST interface).
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
Serve wildcard CORS headers from hapi -- particularly the "generate" route.
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)
STR
Not sure how redirection is currently configured. Seems like this isn't in the repo.
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:
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:
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
The generator seems to fail in odd ways for certain CSS files:
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.
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
?
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.
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:
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.
Hello, is it possible to add a "select" tag to be able to choose the algorithm?
This thing should be appeal enough that people want to use it.
Once the domain name has been acquired.
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.
https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.srihash.org%2F
You could add grunt-html to test locally in the future.
We should serve a static contribute.json file on srihash.org/contribute.json
to tell people how to contribute to this project.
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:
Content-Encoding: gzip
, even if the request does not contain Accept-Encoding: gzip
.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.
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 200
s applies to the final destination.
We should link to the SRI developer guide on https://developer.mozilla.org once it exists.
We should like to http://caniuse.com for browser support once it includes sub-resource integrity.
as a follow up from #81
The current Tap tests have a messy overall structure, and require some pretty crazy nesting for async. Let's make them look good!
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.
Once neftaly/npm-sri-toolbox#2 is fixed, we should update the dependencies so that we generate hashes in the new format.
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".
As per the whatyg spec:
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
lib/resourceTypes.js
, containing:text/plain
text/xml
application/octet-stream
application/xml
generateElement
switch in lib/helpers.js
:case ".forbidden":
// Output error message
break;
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.
Instead of just returning an empty string, we should return a proper message when:
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:
Access-Control-Allow-Origin: *
: open to everyone, no warning.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)Access-Control-Allow-Origin
header: warning that CORS is required for cross-origin loadsI 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.
Maybe we could use one of the badges, the success one?
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://
.
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
We should enforce a CSP policy on this site.
hood might be a good module for that, it's what Firefox Accounts uses.
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}
Travis doesn't like our jshint config it seems: https://travis-ci.org/mozilla/srihash.org/builds/52579326
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.
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"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.