Show HN: A CSS Keylogger

To some limited degree (you can detect presence, not position or number of occurences of character), you can do CSS only &#x27;keylogging&#x27; even for non-reactive (sans JavaScript) input: you don&#x27;t have to use attribute selector (which does&#x27;t work without physical updates), but can exploit webfont with single letter `unicode-range` chunks. Posted it [1] to CrookedStyleSheets [2] some time ago:<p><pre><code> &lt;!doctype html&gt; &lt;title&gt;css keylogger&lt;&#x2F;title&gt; &lt;style&gt; @font-face { font-family: x; src: url(.&#x2F;log?a), local(Impact); unicode-range: U+61; } @font-face { font-family: x; src: url(.&#x2F;log?b), local(Impact); unicode-range: U+62; } @font-face { font-family: x; src: url(.&#x2F;log?c), local(Impact); unicode-range: U+63; } @font-face { font-family: x; src: url(.&#x2F;log?d), local(Impact); unicode-range: U+64; } input { font-family: x, &#x27;Comic sans ms&#x27;; } &lt;&#x2F;style&gt; &lt;input value=&quot;a&quot;&gt;type `bcd` and watch network log </code></pre> [1] <a href="https:&#x2F;&#x2F;github.com&#x2F;jbtronics&#x2F;CrookedStyleSheets&#x2F;issues&#x2F;24" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jbtronics&#x2F;CrookedStyleSheets&#x2F;issues&#x2F;24</a> [2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16157773" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16157773</a>

Hmm, that&#x27;s pretty bad. CSS probably shouldn&#x27;t be able to read password inputs.<p>Edit: This doesn&#x27;t seem to work for me in Chrome 63.0.3239.132<p>Edit 2: OK, so it appears that this will only work on a password input that updates its &quot;value&quot; attribute with the typed in value. This doesn&#x27;t happen unless there is JavaScript that updates the value attr with the input.value

This has nothing to do with vulnerabilities in CSS or Javascript. It has to do with ill-conceived authentication implementations, written in Javascript, that save passwords in the DOM using attributes that are then accessible via CSS. That is a vulnerability on the website itself. It is also an idiotic thing to do.

This is neat but doesn&#x27;t really work as an attack.<p>The CSS selectors work on the value HtmlNode attribute rather than the Javascript &quot;value&quot; value, which aren&#x27;t linked normally. The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me.<p>[edit] Other people pointed this out first.<p>Also, if you are going to all the trouble of making an extension to inject your evil CSS into a page, why not go the whole hog and inject evil ecmascript instead?

This exploit might be defeated with the following css:<p>input[type=&quot;password&quot;] { background-image: none !important; }<p>And if the exploit uses `!important` then you just need to make your selector more specific such as putting it inside an id. If you have malicious javascript running on your page there are better ways to steal data. I feel there is low risk of coming across this problem in the wild.

I&#x27;ve been noticing a lot of CSP talk lately, how CSP is the end-all be-all solution for lots of these types of attacks. Makes me think we should have more articles about how to properly implement a CSP! (content security policy-prevents requests to websites not on the white-list -- the background image request would be rejected)

No it does not. CSS selectors do <i>not</i> apply to input content and `[value]` selectors apply to attributes, which are <i>not</i> updated by just typing in it.<p>This is <i>not</i> a CSS keylogger if you need to update the attributes with the input value via JS.<p>Edit: this apparently works on React sites because React seems to update the `value` attribute as well. Maybe <i>that</i> should be fixed as it’s unnecessary.

To be really dangerous, I think this would need to defeat client-side cache strategies. If the browser caches each resource, the server-side reads wouldn&#x27;t account for repeated characters or overall length with perfect accuracy. Consider palindromes like &quot;racecar.&quot;<p>This would still put many, if not most, passwords within guessable striking distance, for anyone able to intercept plain-text HTTP traffic, between Alice (the client) and Bob (the CSS image resource server).

I wonder if it&#x27;s possible to make auto-updating CSS. CSS can use @import url(&quot;another.css&quot;), and &quot;another.css&quot; might be returned with delay and import &quot;another2.css&quot;, but I&#x27;m not sure if browser would process current css before it&#x27;ll import everything.<p>If this would work, it could spy even without React. Detect first character, then server returns next CSS to detect second character and so on.

You&#x27;d have to have all permutations of any length password in the css file AND it would have to be pre-filled using the value attribute.<p>The original post on this talks about it in more detail:<p><a href="https:&#x2F;&#x2F;www.mike-gualtieri.com&#x2F;posts&#x2F;stealing-data-with-css-attack-and-defense" rel="nofollow">https:&#x2F;&#x2F;www.mike-gualtieri.com&#x2F;posts&#x2F;stealing-data-with-css-...</a><p>Summary: A method is detailed - dubbed CSS Exfil - which can be used to steal targeted data using Cascading Style Sheets (CSS) as an attack vector. Due to the modern web&#x27;s heavy reliance on CSS, a wide variety of data is potentially at risk, including: usernames, passwords, and sensitive data such as date of birth, social security numbers, and credit card numbers. The technique can also be used to de-anonymize users on dark nets like Tor. Defense methods are discussed for both website operators as well as web users, and a pair of browser extensions are offered which guard against this class of attack.

Why not<p><pre><code> input[type=&quot;password&quot;] { background-image: url(attr(value)); } ?</code></pre>

Interestingly, you can defeat this key logger by typing the last character first, use the arrow key to go left and type in the rest. This works because the CSS selector only matches the end of the value input.

This isn’t a problem. CSS could already control what’s displayed and what effect it has. It could already make clicking “next page” open an invisible chat to their account, your password box send your password as a message, and your message from a friend read anything they want. It’s always been a trusted asset.<p>What might be a problem is developers not treating it as such.

Can&#x27;t Chrome extensions already intercept network traffic though? Why does this need to be done at the CSS level?

Couldn&#x27;t Content Security Policy (CSP) [1] be used to mitigate this attack?<p>[1]: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CSP" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CSP</a>

I can&#x27;t seem to make it work from a web page. Perhaps it&#x27;s for extensions only?<p><a href="https:&#x2F;&#x2F;jsfiddle.net&#x2F;tdwsw6zo&#x2F;3&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsfiddle.net&#x2F;tdwsw6zo&#x2F;3&#x2F;</a>

I have not tried it, but if it works (it should): Chapeau, a very neat exploit indeed.

Why do you have to activate the extension before entering the password?

One way of mitigating this is to have strong passwords NOT in alphanumeric characters (if allowed by website), such as mixing emojis with Asian characters.

I hate the internet.

Reminds me of meltdown. Pretty neat.

CSS has gone too far. At least when I&#x27;m worried about a nasty javascript attack from a site I can be somewhat reassured that noscript&#x2F;umatrix will work. Am I going to have to start whitelisting CSS now too? Am I too late?

ALWAYS browse with devtools open, and pay close attention to every packet that&#x27;s being sent out (especially when you&#x27;re not expecting any to...)