3 ms·

Why do browsers enforce CSP against bookmarklets and user scripts, though?

by progval 4y ago

TBurette 4y ago
The goal is to prevent any way for attackers to inject code. Bookmarklets and user scripts are collateral damage.
- andai 4y ago
  That's probably the right choice, but it sounds like there should be a "captcha" to separate programmers from non-programmers. The browser remains in a locked down kiddie mode until you solve these riddles three!
matkoniecz 4y ago
Naive users can be convinced to run random code. Go to discord.com (no need for account) and open browser console. You will see > Hold Up! > If someone told you to copy/paste something here you have an 11/10 chance you're being scammed. > Pasting anything in here could give attackers access to your Discord account. presumably they added it after it kept happening. And likely the same things happens when random user can somehow run code they got from scammer :(
- wruza 4y ago
  I can see something like that as a separate red box above the actual console in opera and firefox, regardless of the current site. Annoys me as hell, cause there is no way(?) to turn it off.
ptx 4y ago
It looks like Mozilla fixed it for bookmarklets[1] three years ago in Firefox 69. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478037 https://bugzilla.mozilla.org/show_bug.cgi?id=1478037
rektide 4y ago
Bookmarklets & user scripts evaluate in the page's context. CSP literally says, only talks to these specific domains. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#example_1 https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#exampl... The browser doesnt block thr bookmarklet from running (iirc). But most bookmarklets immediately try to download & run some libraries to do their thing. Or they try to send data somewhere. And CSP is blocking those connections. Its hard form me to guess how much of this is intentional anti-user lock out, and how much is just oversight or technical diffifulty. I could see not wanting to drill backdoors through your own security policy, which is more or less what it woild take, but it sure feels lile a loss. Users can turn off csp for the browser with a flag if they want, but we can only do that to the whole browser, not site by site. Also worth pointing out that just disabling csp for thr browser/site (rather than carving exceptions for userscripts/bookmarklets) is something sites can detect (by succeeding in a request that ought not go through) & could potentially decide not to serve you content or what not if they wanted to be petty. That said, extensions exist & arent readily detectable so there's options... they are just nowhere near as direct to author & use.
- rektide 4y ago
  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 https://github.com/w3c/webappsec-csp/issues/444

Why do browsers enforce CSP against bookmarklets and user scripts, though?

TBurette 4y ago

The goal is to prevent any way for attackers to inject code. Bookmarklets and user scripts are collateral damage.

andai 4y ago
That's probably the right choice, but it sounds like there should be a "captcha" to separate programmers from non-programmers. The browser remains in a locked down kiddie mode until you solve these riddles three!

matkoniecz 4y ago

Naive users can be convinced to run random code. Go to discord.com (no need for account) and open browser console. You will see > Hold Up! > If someone told you to copy/paste something here you have an 11/10 chance you're being scammed. > Pasting anything in here could give attackers access to your Discord account. presumably they added it after it kept happening. And likely the same things happens when random user can somehow run code they got from scammer :(

wruza 4y ago
I can see something like that as a separate red box above the actual console in opera and firefox, regardless of the current site. Annoys me as hell, cause there is no way(?) to turn it off.

ptx 4y ago

It looks like Mozilla fixed it for bookmarklets[1] three years ago in Firefox 69. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478037 https://bugzilla.mozilla.org/show_bug.cgi?id=1478037

rektide 4y ago

Bookmarklets & user scripts evaluate in the page's context. CSP literally says, only talks to these specific domains. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#example_1 https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#exampl... The browser doesnt block thr bookmarklet from running (iirc). But most bookmarklets immediately try to download & run some libraries to do their thing. Or they try to send data somewhere. And CSP is blocking those connections. Its hard form me to guess how much of this is intentional anti-user lock out, and how much is just oversight or technical diffifulty. I could see not wanting to drill backdoors through your own security policy, which is more or less what it woild take, but it sure feels lile a loss. Users can turn off csp for the browser with a flag if they want, but we can only do that to the whole browser, not site by site. Also worth pointing out that just disabling csp for thr browser/site (rather than carving exceptions for userscripts/bookmarklets) is something sites can detect (by succeeding in a request that ought not go through) & could potentially decide not to serve you content or what not if they wanted to be petty. That said, extensions exist & arent readily detectable so there's options... they are just nowhere near as direct to author & use.

rektide 4y ago
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 https://github.com/w3c/webappsec-csp/issues/444