6 ms·

> It also shows a lack of understanding of how JS and CSS works in the browser. Since you understand how a browser works much better than I do, tell me, can I

> It also shows a lack of understanding of how JS and CSS works in the browser. Since you understand how a browser works much better than I do, tell me, can I disable XHR while still running JS? From the article: > CSS as an API? > This makes me think that a CDN-hosted CSS file like this could have other useful stuff, like today’s date for usage in pseudo content, or other special time-sensitive stuff. Maybe the phase of the moon? Sports scores?! Soup of the day?! > It’s almost like a data API that is tremendously easy to use. Nope, I can't see any problem with JS being able to receive data from an external API, but then I have a lack of understanding of how JS and CSS work in the browser.

scoopertrooper 6y ago
Not OP, but disabling xhr is not possible and disabling it wouldn’t achieve much. The modern browser has many apis with which to make remote calls such as fetch, web sockets, and web rct. They can also fall back to classic methods like jsonp, crafty css skullduggery, and iframes. The reason why this css thing is not a major problem is that the js could retrieve this data just as easily using one of the other methods I listed. JS retrieving data from an external API is generally not a problem unless its used for tracking purposes or as part of an cross site scripting attack. At worst, this gives online tracking companies yet another tool in their toolbox. I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour. I can’t really see it being used for cross site attacks unless some whackadoodle site decided to try and send secreted authenticated data via CSS payloads.
- brigandish 6y ago
  > disabling xhr is not possible uMatrix can do it, I'm sure there are others > fetch fetch is a Javascript API and covered by uMatrix's XHR setting[1]. > web rct That can be disabled[2] and is also covered by uMatrix's XHR setting. > iframes Can be blocked in several ways, including the aformentioned uMatrix. > At worst, this gives online tracking companies yet another tool in their toolbox At worst CSS in the browser has had a CVE[3] and OWASP has some attacks[4] that seem old, but you know which of these have been fixed by all the browser vendors you use, right? Perhaps you've read this paper[5] on scriptless attacks and you know that all of these have been mitigated? > The surprising result is that an attacker can also abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images or font files. Through several case studies, we introduce the so called scriptless attacks and demonstrate that an adversary might not need to execute code to preserve his ability to extract sensitive information from well protected websites. More precisely, we show that an attacker can use seemingly benign features to build side channel attacks that measure and exfiltrate almost arbitrary data displayed on a given website. Even better, you have the faith that there will never be a repeat of these kind of things and that no attackers will bother to go down this route in future. What part does faith have when deciding upon the risks of running things downloaded from untrusted sources? Still, the anti-tracking is good enough reason for me. > I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour. Let's hope so. [1] https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-type-cells https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-... [2] https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ [3] https://cve.circl.lu/cve/CVE-2011-0132 https://cve.circl.lu/cve/CVE-2011-0132 [4] https://owasp.org/www-community/xss-filter-evasion-cheatsheet https://owasp.org/www-community/xss-filter-evasion-cheatshee... [5] https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2012/08/16/scriptlessAttacks-ccs2012.pdf https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlich...
capableweb 6y ago
> can I disable XHR while still running JS? Sure, but it's not easy. You'd have to run content-scripts from some browser extension that polyfills the APIs you want to get rid of. But disabling XHR/fetch/others won't stop your browser from being able to make requests. CSS can make requests (like when you provide custom font paths, or images), HTML can also make requests (<img> and <iframe> elements comes to mind). Without those, we don't have a web anymore, we have a document storage without links to other resources. CSS cannot be used as an external API as much as HTML cannot be used as an API. The trick the author is talking about under "CSS as an API" assumes that JS is activated, otherwise you can't really do anything dynamic with the data. And if you're not doing something dynamic (like you wanna display some text in :content under a :before element), you can just set it in the HTML response instead of in the CSS response. I'm not saying that disabling JS by default is bad (I do so myself, enabling it only for trusted sites). I'm just pointing out that disabling CSS is not gonna give you any additional benefits. As long as you're in the browser, a HTML page can make requests for you, even if you have CSS disabled.
- brigandish 6y ago
  > Sure, but it's not easy. I have XHR disabled by default and can enable it with 2 clicks. > But disabling XHR/fetch/others won't stop your browser from being able to make requests. > CSS can make requests Hence it being disabled. > HTML can also make requests (<img> and <iframe> elements comes to mind). Which is why I have those disabled by default too. > CSS cannot be used as an external API as much as HTML cannot be used as an API But it can be used as an API and because there are people out there, like yourself, who downplay this ability, there are those who will leave it running… > assumes that JS is activated, otherwise you can't really do anything dynamic with the data …and hence, may have disabled the usual routes that you listed - XHR, images, frames etc - and leave JS on for some other reason while believing they've mitigated a number of major threats. It's hard to produce perfect security or anti-tracking behaviour, very hard, but that doesn't mean we should ignore CSS.

scoopertrooper 6y ago

Not OP, but disabling xhr is not possible and disabling it wouldn’t achieve much. The modern browser has many apis with which to make remote calls such as fetch, web sockets, and web rct. They can also fall back to classic methods like jsonp, crafty css skullduggery, and iframes. The reason why this css thing is not a major problem is that the js could retrieve this data just as easily using one of the other methods I listed. JS retrieving data from an external API is generally not a problem unless its used for tracking purposes or as part of an cross site scripting attack. At worst, this gives online tracking companies yet another tool in their toolbox. I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour. I can’t really see it being used for cross site attacks unless some whackadoodle site decided to try and send secreted authenticated data via CSS payloads.

brigandish 6y ago
> disabling xhr is not possible uMatrix can do it, I'm sure there are others > fetch fetch is a Javascript API and covered by uMatrix's XHR setting[1]. > web rct That can be disabled[2] and is also covered by uMatrix's XHR setting. > iframes Can be blocked in several ways, including the aformentioned uMatrix. > At worst, this gives online tracking companies yet another tool in their toolbox At worst CSS in the browser has had a CVE[3] and OWASP has some attacks[4] that seem old, but you know which of these have been fixed by all the browser vendors you use, right? Perhaps you've read this paper[5] on scriptless attacks and you know that all of these have been mitigated? > The surprising result is that an attacker can also abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images or font files. Through several case studies, we introduce the so called scriptless attacks and demonstrate that an adversary might not need to execute code to preserve his ability to extract sensitive information from well protected websites. More precisely, we show that an attacker can use seemingly benign features to build side channel attacks that measure and exfiltrate almost arbitrary data displayed on a given website. Even better, you have the faith that there will never be a repeat of these kind of things and that no attackers will bother to go down this route in future. What part does faith have when deciding upon the risks of running things downloaded from untrusted sources? Still, the anti-tracking is good enough reason for me. > I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour. Let's hope so. [1] https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-type-cells https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-... [2] https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ [3] https://cve.circl.lu/cve/CVE-2011-0132 https://cve.circl.lu/cve/CVE-2011-0132 [4] https://owasp.org/www-community/xss-filter-evasion-cheatsheet https://owasp.org/www-community/xss-filter-evasion-cheatshee... [5] https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2012/08/16/scriptlessAttacks-ccs2012.pdf https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlich...

capableweb 6y ago

> can I disable XHR while still running JS? Sure, but it's not easy. You'd have to run content-scripts from some browser extension that polyfills the APIs you want to get rid of. But disabling XHR/fetch/others won't stop your browser from being able to make requests. CSS can make requests (like when you provide custom font paths, or images), HTML can also make requests (<img> and <iframe> elements comes to mind). Without those, we don't have a web anymore, we have a document storage without links to other resources. CSS cannot be used as an external API as much as HTML cannot be used as an API. The trick the author is talking about under "CSS as an API" assumes that JS is activated, otherwise you can't really do anything dynamic with the data. And if you're not doing something dynamic (like you wanna display some text in :content under a :before element), you can just set it in the HTML response instead of in the CSS response. I'm not saying that disabling JS by default is bad (I do so myself, enabling it only for trusted sites). I'm just pointing out that disabling CSS is not gonna give you any additional benefits. As long as you're in the browser, a HTML page can make requests for you, even if you have CSS disabled.

brigandish 6y ago
> Sure, but it's not easy. I have XHR disabled by default and can enable it with 2 clicks. > But disabling XHR/fetch/others won't stop your browser from being able to make requests. > CSS can make requests Hence it being disabled. > HTML can also make requests (<img> and <iframe> elements comes to mind). Which is why I have those disabled by default too. > CSS cannot be used as an external API as much as HTML cannot be used as an API But it can be used as an API and because there are people out there, like yourself, who downplay this ability, there are those who will leave it running… > assumes that JS is activated, otherwise you can't really do anything dynamic with the data …and hence, may have disabled the usual routes that you listed - XHR, images, frames etc - and leave JS on for some other reason while believing they've mitigated a number of major threats. It's hard to produce perfect security or anti-tracking behaviour, very hard, but that doesn't mean we should ignore CSS.