4 ms·
This is also the weak link in client web apps for security products like 1Password, where the weakest link is the integrity of the static files loaded by the br
by TimTheTinker 6y ago
This is also the weak link in client web apps for security products like 1Password, where the weakest link is the integrity of the static files loaded by the browser. Break into their static file server or CDN/edge cache and you've effectively pwned any browser sessions started after that point.
(This also applies to builds of client software, but for most operating systems those builds have to be signed with a private key, which makes them more difficult to compromise. On Linux, SHA256 checksums are usually provided alongside binaries - which are especially important to use against security-related client software.)
- giantrobot 6y agoBrowsers support Subresource Integrity [0] checks. You provide an integrity attribute (or several) for a script or link resource and the browser will check the hash(es) before using the resource. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... [1] https://w3c-test.org/subresource-integrity/subresource-integrity.html https://w3c-test.org/subresource-integrity/subresource-integ...
- fabrice_d 6y agoYes, but there is the problem of bootstrapping that chain of trust: how do you know that the SRI attribute value has not been tampered with? TLS protects transit, but not server side breaches.
- TimTheTinker 6y agoRight. Subresource integrity checks eliminate the need to trust the source of the subresource, but not the main resource (the HTML response that bootstraps the app). But I'm willing to bet 1Password and the like never trusted third parties to host <link> and <script> assets anyway.
- giantrobot 6y agoIf you're doing an SPA where the HTML is just loading your JavaScript for the meat of your app it's straightforward to verify that file. Besides literally comparing its hash to a known good value there's the Digest header [0] which is a way to provide a resource hash to a client. From the browser side there's the Want-Digest header [1]. These replaced the Content-MD5 header. While browsers support these headers I don't think any currently reject a page or resource if a digest doesn't match. But at least the mechanism is there. There's also the draft [2] for signed HTTP messages. So a response can be signed and verified against a public key. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Di... [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Wa... [2] https://tools.ietf.org/id/draft-cavage-http-signatures-10.html https://tools.ietf.org/id/draft-cavage-http-signatures-10.ht...
- TimTheTinker 6y agoIf I understand correctly the digest is only to make sure it didn't change while in transit. If the file itself that's being served was compromised, the web server will serve it with a new digest that matches.
- giantrobot 6y agoThat's where the Signature header comes in. The host can sign the resource and the client can verify the digest and signature. If you're trusting the TLS connection you'd have the same amount of trust in the resource signature.
- TimTheTinker 6y agoGood point, thanks for the added detail. Note that one still must fully trust the root resource (the HTML response that bootstraps the web app). Whatever generates or stores that response up until it is wrapped in TLS is just as vulnerable.
- oarsinsync 6y agoTIL, thanks! Looks like it works on (mobile) Safari as well, which is fantastic.