4 ms·

> When the stylesheets are not accessible by document.styleSheets API (e.g. on a third party domain, what!?) I agree with the !? sentiment. An even bigger WTF

by cxr 3y ago

> When the stylesheets are not accessible by document.styleSheets API (e.g. on a third party domain, what!?) I agree with the !? sentiment. An even bigger WTF, though, is that the server gets to control through CSP which off-site style sheets the user can link against and even whether use of the style attribute is permitted. CSP is one of the worst pieces of Web security infrastructure that modern browsers unwisely agreed to go along with. Incredibly user-hostile and worse, effectively irreversible—there's basically no going back now because browsers don't have the option at this point to say, "Yeah, we're not going to honor this anymore," without putting users at an even greater risk than before CSP ever existed. So not just detestable in the vein of WEI, but an utterly abominable technical work.

lifthrasiir 3y ago
It's rather an origin check instead of CSP I believe [1], and I can imagine a lot of possible attacks if it's open wide... [1] https://drafts.csswg.org/cssom/#concept-css-style-sheet-origin-clean-flag https://drafts.csswg.org/cssom/#concept-css-style-sheet-orig...
- cxr 3y ago
  To be clear: I wasn't saying that restricted cross-origin access to style rules was a consequence of CSP; I was likening the effects of document.styleSheets restrictions to the effects of CSP restrictions. (It happens that CSP has other, worse effects.)
wscourge 3y ago
> CSP is one of the worst pieces of Web security infrastructure that modern browsers unwisely agreed to go along with This got me interested - care to provide a reasoning behind it? I'd love to read more on the subject and better understand it. Thanks.
- cxr 3y ago
  Unfortunately, someone would have to write it first. (Why not you?) My reasoning is in the next sentence: «Incredibly user-hostile and worse, effectively irreversible—there's basically no going back now because browsers don't have the option at this point to say, "Yeah, we're not going to honor this anymore," without putting users at an even greater risk than before CSP ever existed.»
  - wscourge 3y ago
    I still don't understand WHY is it "Incredibly user-hostile". Will do my own research anyway.
    - cxr 3y ago
      Refer to the place in the linked article where the part I quoted appears in a section called "Limitations"—the bookmarklet is stopped in its tracks when it encounters style sheets that are loaded from off-site (but that are still loaded nonetheless and have an effect on the current page). Considering that the user is the one who invokes bookmarklets and has their own personal accessibility reasons for doing so, that's an unwelcome limitation. There's a similar effect with CSP: server operators and content authors can use CSP to prevent the use of bookmarklets that ordinarily work by overriding the author's style rules through $element$.style (i.e. the style attribute), inserting style elements with the user's own CSS, or loading/linking against off-site style sheets. See also: Google's WEI ("Web Environment Integrity") proposal from earlier last year that was justifiably opposed by pretty much everyone[1] The W3C's Priority of Constituencies[2] (part of its Web Platform Design Principles) and its Ethical Web Principles related to putting users in control[3] 1. <https://en.wikipedia.org/wiki/Web_Environment_Integrity https://en.wikipedia.org/wiki/Web_Environment_Integrity> 2. <https://www.w3.org/TR/design-principles/#priority-of-constituencies https://www.w3.org/TR/design-principles/#priority-of-constit...> 3. <https://www.w3.org/TR/ethical-web-principles/#control https://www.w3.org/TR/ethical-web-principles/#control>
1f60c 3y ago
> CSP is one of the worst pieces of Web security infrastructure I disagree. Like many things, it's a trade-off, in this case between configurability and extensibility for those who know what they're doing and security for those who don't. In the grand scheme of things, it seems pretty reasonable.
- cxr 3y ago
  That doesn't make sense. CSP is opt-in.
madeofpalk 3y ago
> An even bigger WTF, though, is that the server gets to control through CSP which off-site style sheets the user can link against and even whether use of the style attribute is permitted. I don't understand the problem. This is exactly the use case for CSP - allow the server to lock down to a more restricted, and safer subset of the web platform. It plays an important part in providing a failsafe for displaying untrusted/user content on the web (and elsewhere). I know of one podcast client that uses CSP to safely render HTML podcast notes, blocking the loading of images and any external assets. Pretty neat if you ask me. Why do you think CSP is user hostile?
- hahn-kev 3y ago
  There's a difference between user content, which could include injection attacks. And what might be called operator content (operator of the browser in this case, which could also be considered a user), sure I want to be protected against hostile injection, but I should be able to inject code into my own browser without any issue.
  - crtasm 3y ago
    Would a userscript running in Greasemonkey/Violentmonkey help in this case? I inject code into every site I visit.
MereInterest 3y ago
I think browsers should make a distinction between server-provided scripts and local-user-initiated scripts. From what I can tell, CSP should only apply to server-provided scripts. They are a way for the server to restrict the capabilities of its own scripts. “I only require resources from these domains. If you hear otherwise, it wasn’t from me.” For local-user-initiated scripts, this restriction is unnecessary. The server has limited what scripts it itself can run, but that shouldn’t impact what scripts the user can run.

by cxr 3y ago

lifthrasiir 3y ago

It's rather an origin check instead of CSP I believe [1], and I can imagine a lot of possible attacks if it's open wide... [1] https://drafts.csswg.org/cssom/#concept-css-style-sheet-origin-clean-flag https://drafts.csswg.org/cssom/#concept-css-style-sheet-orig...

cxr 3y ago
To be clear: I wasn't saying that restricted cross-origin access to style rules was a consequence of CSP; I was likening the effects of document.styleSheets restrictions to the effects of CSP restrictions. (It happens that CSP has other, worse effects.)

wscourge 3y ago

> CSP is one of the worst pieces of Web security infrastructure that modern browsers unwisely agreed to go along with This got me interested - care to provide a reasoning behind it? I'd love to read more on the subject and better understand it. Thanks.

cxr 3y ago
Unfortunately, someone would have to write it first. (Why not you?) My reasoning is in the next sentence: «Incredibly user-hostile and worse, effectively irreversible—there's basically no going back now because browsers don't have the option at this point to say, "Yeah, we're not going to honor this anymore," without putting users at an even greater risk than before CSP ever existed.»
- wscourge 3y ago
  I still don't understand WHY is it "Incredibly user-hostile". Will do my own research anyway.
  - cxr 3y ago
    Refer to the place in the linked article where the part I quoted appears in a section called "Limitations"—the bookmarklet is stopped in its tracks when it encounters style sheets that are loaded from off-site (but that are still loaded nonetheless and have an effect on the current page). Considering that the user is the one who invokes bookmarklets and has their own personal accessibility reasons for doing so, that's an unwelcome limitation. There's a similar effect with CSP: server operators and content authors can use CSP to prevent the use of bookmarklets that ordinarily work by overriding the author's style rules through $element$.style (i.e. the style attribute), inserting style elements with the user's own CSS, or loading/linking against off-site style sheets. See also: Google's WEI ("Web Environment Integrity") proposal from earlier last year that was justifiably opposed by pretty much everyone[1] The W3C's Priority of Constituencies[2] (part of its Web Platform Design Principles) and its Ethical Web Principles related to putting users in control[3] 1. <https://en.wikipedia.org/wiki/Web_Environment_Integrity https://en.wikipedia.org/wiki/Web_Environment_Integrity> 2. <https://www.w3.org/TR/design-principles/#priority-of-constituencies https://www.w3.org/TR/design-principles/#priority-of-constit...> 3. <https://www.w3.org/TR/ethical-web-principles/#control https://www.w3.org/TR/ethical-web-principles/#control>

1f60c 3y ago

> CSP is one of the worst pieces of Web security infrastructure I disagree. Like many things, it's a trade-off, in this case between configurability and extensibility for those who know what they're doing and security for those who don't. In the grand scheme of things, it seems pretty reasonable.

cxr 3y ago
That doesn't make sense. CSP is opt-in.

madeofpalk 3y ago

> An even bigger WTF, though, is that the server gets to control through CSP which off-site style sheets the user can link against and even whether use of the style attribute is permitted. I don't understand the problem. This is exactly the use case for CSP - allow the server to lock down to a more restricted, and safer subset of the web platform. It plays an important part in providing a failsafe for displaying untrusted/user content on the web (and elsewhere). I know of one podcast client that uses CSP to safely render HTML podcast notes, blocking the loading of images and any external assets. Pretty neat if you ask me. Why do you think CSP is user hostile?

hahn-kev 3y ago
There's a difference between user content, which could include injection attacks. And what might be called operator content (operator of the browser in this case, which could also be considered a user), sure I want to be protected against hostile injection, but I should be able to inject code into my own browser without any issue.
- crtasm 3y ago
  Would a userscript running in Greasemonkey/Violentmonkey help in this case? I inject code into every site I visit.

MereInterest 3y ago

I think browsers should make a distinction between server-provided scripts and local-user-initiated scripts. From what I can tell, CSP should only apply to server-provided scripts. They are a way for the server to restrict the capabilities of its own scripts. “I only require resources from these domains. If you hear otherwise, it wasn’t from me.” For local-user-initiated scripts, this restriction is unnecessary. The server has limited what scripts it itself can run, but that shouldn’t impact what scripts the user can run.