5 ms·

As I read I wondered about the possibility of its abuse as a payload system, then I reached this linked post[1]: > What happens when you combine the fact that

As I read I wondered about the possibility of its abuse as a payload system, then I reached this linked post[1]: > What happens when you combine the fact that part after the : for CSS Custom Properties doesn’t need to be valid CSS with window.getComputedStyle()? You get a way of passing data – including Arrays, Objects, and even JSON – from CSS to JavaScript. The first article proposes the possibility of sending updated variables via a CDN, and the linked one shows a CSS variable being parsed as JSON and then executed by the Javascript engine. There's probably some fun and high jinks to be had there… [1] https://www.bram.us/2020/03/30/pass-data-from-css-to-javascript-with-css-variables/ https://www.bram.us/2020/03/30/pass-data-from-css-to-javascr...

dillondoyle 6y ago
I thought the same thing.... classic cross domain ad tracking trick. BUT seems like chrome is trying to limit by keying caches to the domain. BUT BUT maybe not in cross domain web workers? IDK though might be some interesting ideas. *edit maybe just cname cloak like are doing to get around itp poc: https://github.com/dillondoyle/css_cache https://github.com/dillondoyle/css_cache https://dillondoyle.github.io/css_cache/index.html https://dillondoyle.github.io/css_cache/index.html
- dennisy 6y ago
  Could you explain what this POC shows?
  - dillondoyle 6y ago
    sure. - basic js generates a css file with a random uuid and an example just my name. puts into a css var as a JSON object - sets long term cache headers AND a matching etag (same as uuid) - etag is a classic tracking trick but this is really cool it makes it accessible as state in JS client side - index.html prints/logs the css var - if css file is cached the uuid you see is static. no cookies needed - i was also going to add just an array of recent request domains, last and first session. would help test the chrome cache keying. could even put a jwt in there it's just a cool hack I never thought of. it's really cool how one thing can trigger an 'omg that's so obvious' brain fart. Like even before CSS vars you could have done this just set really specific css width 12.999933/122.3333 or something then measure the div you set or maybe simpler just a random "'uuid_"+the_uuid_var+"'" classname add to body and then read if it exists with js. But I never thought of it until I saw this article!!! Same with just generating a JS file with static var which I've played with but never deployed. though I might guess a css file is cached longer? idk i don't have proof of that just a guess could be wrong could maybe extend this to get around chrome cache keying with cname cloaking *edit actually maybe more likely that doesn't make sense idk i'd have to think about it or just reading their docs last night about their new policy (only a couple months old) it looks like webworkers aren't enforced yet and you can explicitly control & cache a file with JS in a webworker
    - dennisy 6y ago
      Thanks for that!
scoopertrooper 6y ago
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.

dillondoyle 6y ago

I thought the same thing.... classic cross domain ad tracking trick. BUT seems like chrome is trying to limit by keying caches to the domain. BUT BUT maybe not in cross domain web workers? IDK though might be some interesting ideas. *edit maybe just cname cloak like are doing to get around itp poc: https://github.com/dillondoyle/css_cache https://github.com/dillondoyle/css_cache https://dillondoyle.github.io/css_cache/index.html https://dillondoyle.github.io/css_cache/index.html

dennisy 6y ago
Could you explain what this POC shows?
- dillondoyle 6y ago
  sure. - basic js generates a css file with a random uuid and an example just my name. puts into a css var as a JSON object - sets long term cache headers AND a matching etag (same as uuid) - etag is a classic tracking trick but this is really cool it makes it accessible as state in JS client side - index.html prints/logs the css var - if css file is cached the uuid you see is static. no cookies needed - i was also going to add just an array of recent request domains, last and first session. would help test the chrome cache keying. could even put a jwt in there it's just a cool hack I never thought of. it's really cool how one thing can trigger an 'omg that's so obvious' brain fart. Like even before CSS vars you could have done this just set really specific css width 12.999933/122.3333 or something then measure the div you set or maybe simpler just a random "'uuid_"+the_uuid_var+"'" classname add to body and then read if it exists with js. But I never thought of it until I saw this article!!! Same with just generating a JS file with static var which I've played with but never deployed. though I might guess a css file is cached longer? idk i don't have proof of that just a guess could be wrong could maybe extend this to get around chrome cache keying with cname cloaking *edit actually maybe more likely that doesn't make sense idk i'd have to think about it or just reading their docs last night about their new policy (only a couple months old) it looks like webworkers aren't enforced yet and you can explicitly control & cache a file with JS in a webworker
  - dennisy 6y ago
    Thanks for that!

scoopertrooper 6y ago

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.