7 ms·

Meh, such hijinks could be achieved, less neatly, with pseudo elements and getComputedStyle. I haven't tried this, but this should have the same effect: .sn

Meh, such hijinks could be achieved, less neatly, with pseudo elements and getComputedStyle. I haven't tried this, but this should have the same effect: .sneaky-class:before { content: '{"tracking_code": "abc"}'; display: none; } const trackingPayload = JSON.parse( window.getComputedStyle( document.querySelector(".sneaky-class"), ":before") .getPropertyValue("content") );

brigandish 6y ago
This kind of thing why I browse with javascript and CSS blocked.
- capableweb 6y ago
  It also shows a lack of understanding of how JS and CSS works in the browser. Disabling only JS would prevent anything from happen as CSS doesn't execute any code here, the JS part is responsible for that. Except for enjoying a web without styles, there is no reason to disable CSS (together with disabling JS). You're not gonna prevent any more JS fudgery by having JS and CSS disabled compared to just JS disabled.
  - brigandish 6y ago
    > 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...
- Santosh83 6y ago
  Blocking CSS turns most websites into unusable stream of text and oversized SVG images and such. At that point you may as well use something like Lynx or Wget...
  - brigandish 6y ago
    I find it actually improves a number of websites (an increasing number), which may be more of a comment on the number of front-end devs who seem to be able to construct a website that degrades properly without javascript. I also can't make Lynx and Wget into a more graphical form with just a couple of clicks, and there are other reasons reasons to disable CSS[1][2] but each to their own. [1] https://medium.com/javascript-in-plain-english/tracking-with-css-ec98e3d81046 https://medium.com/javascript-in-plain-english/tracking-with... [2] https://www.templarbit.com/blog/2018/03/20/tracking-users-with-css/ https://www.templarbit.com/blog/2018/03/20/tracking-users-wi...
dennisy 6y ago
Can you explain what the issue with this is? What does this circumvent that cannot be done with pure JS?
- capableweb 6y ago
  > Can you explain what the issue with this is? The only issue I can think of is mixing code/data with styling information. Otherwise there is no "issue" per se. > What does this circumvent that cannot be done with pure JS? Nothing, it is just JS after all, and the idea that you can store data in other things than JS variables is not new (jQuery days we stored data in various attributes in the DOM to keep track of state). You could also store the same data in <title/> tag and get the same results. Not sure what the use case is, except it's a fun little hack. Maybe this will spawn some new JS framework, nothing would surprise me anymore.
- rriepe 6y ago
  If you're trying to make your code look non-malicious, it's easier if you have somewhere to hide the malicious-looking stuff.
- dillondoyle 6y ago
  possibly a longer lasting cache 'super cookie' i made a poc comment below. you could do something similar with a dynamically generated js file but i might wonder if a very small css file with headers like a cdn is cached longer

brigandish 6y ago

This kind of thing why I browse with javascript and CSS blocked.

capableweb 6y ago
It also shows a lack of understanding of how JS and CSS works in the browser. Disabling only JS would prevent anything from happen as CSS doesn't execute any code here, the JS part is responsible for that. Except for enjoying a web without styles, there is no reason to disable CSS (together with disabling JS). You're not gonna prevent any more JS fudgery by having JS and CSS disabled compared to just JS disabled.
- brigandish 6y ago
  > 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...
Santosh83 6y ago
Blocking CSS turns most websites into unusable stream of text and oversized SVG images and such. At that point you may as well use something like Lynx or Wget...
- brigandish 6y ago
  I find it actually improves a number of websites (an increasing number), which may be more of a comment on the number of front-end devs who seem to be able to construct a website that degrades properly without javascript. I also can't make Lynx and Wget into a more graphical form with just a couple of clicks, and there are other reasons reasons to disable CSS[1][2] but each to their own. [1] https://medium.com/javascript-in-plain-english/tracking-with-css-ec98e3d81046 https://medium.com/javascript-in-plain-english/tracking-with... [2] https://www.templarbit.com/blog/2018/03/20/tracking-users-with-css/ https://www.templarbit.com/blog/2018/03/20/tracking-users-wi...

dennisy 6y ago

Can you explain what the issue with this is? What does this circumvent that cannot be done with pure JS?

capableweb 6y ago
> Can you explain what the issue with this is? The only issue I can think of is mixing code/data with styling information. Otherwise there is no "issue" per se. > What does this circumvent that cannot be done with pure JS? Nothing, it is just JS after all, and the idea that you can store data in other things than JS variables is not new (jQuery days we stored data in various attributes in the DOM to keep track of state). You could also store the same data in <title/> tag and get the same results. Not sure what the use case is, except it's a fun little hack. Maybe this will spawn some new JS framework, nothing would surprise me anymore.
rriepe 6y ago
If you're trying to make your code look non-malicious, it's easier if you have somewhere to hide the malicious-looking stuff.
dillondoyle 6y ago
possibly a longer lasting cache 'super cookie' i made a poc comment below. you could do something similar with a dynamically generated js file but i might wonder if a very small css file with headers like a cdn is cached longer