webappsec

Blocking/allowlisting all JavaScript is the only way [1] to have a CSP fully contain an app (no exfiltration) [2] and with prefetch that might not be enough. The author is correct at the end to suggest using WebAssembly. (Also, it still has the issue of clicking links, which can be limited to certain domains or even data: by wrapping the untrusted code in an iframe and using child-src on the parent of the iframe) 1: https://github.com/w3c/webappsec/issues/656#issuecomment-246... 2: https://www.w3.org/TR/CSP3/#exfiltration

It's great to hear that you want this added to browsers themselves, and you're right that browsers are more likely to implement such changes if you can show that users are deliberately installing an extension to add the missing functionality. There has been some discussion at the W3C about extending the SRI spec in this direction[0], but it seems they are reluctant to do that unless "multiple browser vendors" choose to implement something like this.[1] Hopefully the existence and adoption of this browser extension helps to solve that bootstrapping / Catch-22 problem. As for usability, would it be sufficient to just adopt a TOFU model, where the browser pins the first key it sees for a domain? To prevent the risk of permanently bricking a site (if the key gets lost, or the host gets temporarily compromised) you could politely warn the us

One user story is that Alice uses Eve's webmail, and Bob uses PGP and mutt on his laptop. Before Eve's webmail supported PGP in JS, Bob had to send his emails to Alice unencrypted (and unsigned), which meant his mail provider could read the plaintext (even if he trusted that mail provider to always require a TLS connection when sending to Eve's servers). From Alice's point of view, she is just using webmail as she always has, except now she has the assurance that no one (other than Eve) can spoof Bob's identity, and that Bob's mail server isn't reading the messages she sends him (unless Eve is deliberately leaking the plaintext somehow despite sending Bob the encrypted version). Long term it would be nice if the W3C's SRI standard was extended to allow offline signing of JavaScript files: https://github.com/w3c/webappsec/issues/449 and f

Here's a potentially easier to read (doesn't require JavaScript) document explaining WebSign: https://www.cyph.com/websign It's a really smart idea, although it did have some odd edge cases, and required you to trust that they really were throwing away the keys as promised. There is some talk in the W3C of extending the SRI standard to let a website declare that all (or just certain) included resources have been signed by an (offline) PGP key: https://github.com/w3c/webappsec/issues/449 so we might one day reach a point where running a webapp at least has the small security guarantee that a TOFU policy gives you. If this could be combined with versioned releases of webapps, and the signature appearing in something like a Binary Transparency log, then the security guarantee could actually be quite meaningful: https://wiki.mozilla.org/Secu

Attackers could otherwise verify that resources on private networks or retrievable only with the victim's cookies have certain content. See, e.g., <https://github.com/w3c/webappsec/issues/418> for some broader discussion.

These problems are really hairy. Thankfully, all the privacy issues are only one-bit leakages (and there are TONS of one-bit leakages in web browsers), but the CSP bypass with SRI attack is really cool. One thing that I've found incredibly disappointing about SRI is that it requires CORS. There's some more information here: https://github.com/w3c/webappsec/issues/418 but it essentially means that you can't SRI-pin content on a sketchy/untrustworthy CDN without them putting in work to enable CORS (which, if they're sketchy and untrustworthy, they probably won't do). The attack that the authors lay out for SRI requiring CORS is legitimate, but incredibly silly - a site could use SRI as an oracle to check the hash value of cross-domain content. You could theoretically use this to brute force secrets on pages, but this is kind of silly becaus

It looks like there was a change on 19th August, 2014: https://github.com/w3c/webappsec/commit/b48b635f93a798da87c6... However, clicking the link to “Latest Version” at the top of the document you linked (from Dec 2015) takes you to the document I posted (from Aug 2014) so…who knows? It will require some testing to see what the browsers have actually implemented I guess.

The header is 9 days old, and now Chrome is sending it by default: https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254... Header bloat, ~28 extra bytes per request from every Chrome user in the world. The whole idea of the header is odd, it should be something the server could send to the client, if needed, not something the client should announce support for. Crazy indeed.

It seems crazy to: 1) Implement a draft header from the W3 at this stage (which I think this is from what I can see.. there's even some fun debate about how many characters long it should be: https://github.com/w3c/webappsec/issues/216). Do they really expect webservers to handle this correctly? 2) Despite having a bug like this open in Beta, allow this to get out to Prod! Surely it's obvious this is a major breaking change?! edit: here's the working draft document: http://www.w3.org/TR/upgrade-insecure-requests/#preference