webappsec-csp

Good time to surface the limitations of a Content Security Policy: https://github.com/w3c/webappsec-csp/issues/92 Also the double iframe technique is important for preventing exfiltration through navigation, but you have to make sure you don't allow top navigation. The outer iframe will prevent the inner iframe from loading something outside of the frame-src origins. This could mean restricting it to only a server which would allow sending it to the server, but if it's your server or a server you trust that might be OK. Or it could mean srcdoc and/or data urls for local-only navigation. I find the WebAssembly route a lot more likely to be able to produce true sandboxen.

Alas, many sites have Content-Security Policies, which doesn't block bookmarklets outright, but keeps them from functioning in basic ways: often CSP prevents contact with other sites. So you can modify the page, yes. But you can't submit content to other domains. You can't load more code. This double-dooms kick-ass awesome extensions like Hypothes.is[1], the brilliant Web Annotation tool/bookmarklet: the bookmarklet can't load the rest of the code needed to launch the experience, and the bookmarklet can't send those annotations the user makes to the user's destination. I've seen very little interest when issues are raised about doing anything to help Bookmarklets[1]. Browsers seemingly don't care about these users & are fine with Bookmarklets being left to rot away. Meanwhile Chrome on Android still has no other means for users to extend/

The mainstream browsers & spec authors sneer at & detest userscripts, wish they'd never been a thing. https://github.com/w3c/webappsec-csp/issues/444 I agree. This is simple & stupid a problem. It's grossly anti-user. But today, security rules, and security sees all the misdeeds of users, and those who would prey on them, and they have no emapathy left for creativity and fun. There's no moral-value-party left anywhere that defends user freedom, that is pro end-user-hacking. The Manifest V3 (MV3) catastrophe is still scheduled for 4 months out, even though there is still only 1/3rd the work done thay it would take to allow GreaseMonkeyTamperMonkey/et-cetera to live. The new browsers are actively unwinding power & possibility, forever trying to undo the permissiveness that it had (ex: CORB, and now ORB). The standards authors & browser make

I found the bug I opened against the csp spec, asking for it to not obstruct userscripts. https://github.com/w3c/webappsec-csp/issues/444

Probably an issue that should've gotten addressed ahead of standardization, IMHO: https://github.com/w3c/webappsec-csp/issues/92

TBH, this whole blog post just seemed like a poor ad for Akamai's Page Integrity product, and deliberately overcomplicated 2 problems that should be very simple to deal with: 1. How did the malicious script get injected in the first place? CSP should eliminate if not greatly reduce this attack surface. 2. The blog post states "Also, a lot of CSP policies don't limit WebSockets usage." Umm, what? Why not, this seems incredibly stupid to me, that's the whole point of connect-src. What I did find was this issue report, https://github.com/w3c/webappsec-csp/issues/7 , stating that connect-src 'self' doesn't allow websockets in many browsers because it's technically not same-origin, so all I can imagine is that there is some (bad, lazy) practice where if you wanted connect-src 'self' to allow websockets back to the same host you just said "fuck