CSS-Keylogging
Security and privacy
security proof of concept
SHOW HN2018
How HN took it
6 positive, 75 neutral or asking, 0 mixed, 21 critical, out of 102 comments about the project. Thread score -0.15.
Privacy: 0 for, 12 againstIdea: 5 for, 2 againstExecution: 0 for, 5 againstPerformance: 0 for, 1 againstDocs: 0 for, 1 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Clever exploit, neat trick using the selector
From 2 comments
Nice job. Css had similar attacks maybe a decade ago, with link:visited (referer snooping) and image with src to a logged in site... but I like the selector trick. Extensions are…
xab9 on HNI have not tried it, but if it works (it should): Chapeau, a very neat exploit indeed.
jlg23 on HN
Objections
Only works when the DOM value attribute is updated, e.g. by React, not on normal typing
From 3 comments
This is neat but doesn't really work as an attack. The CSS selectors work on the value HtmlNode attribute rather than the Javascript "value" value, which aren't linked normally.…
AndrewStephens on HNThis is incorrect. The [value=foo] selector does not work for the actual value of the field, only the `value` attribute (used to set the initial value). This means that both: -…
Manishearth on HNNo it does not. CSS selectors do not apply to input content and `[value]` selectors apply to attributes, which are not updated by just typing in it. This is not a CSS keylogger…
bfred_it on HN
Real vulnerability lies in sites storing passwords in the DOM, not CSS itself
From 2 comments
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…
teilo on HNThis 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…
twhb on HN
CSP or disabling injected CSS would mitigate it
From 2 comments
Couldn't Content Security Policy (CSP) [1] be used to mitigate this attack? [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
wuyishan on HNOr just use correctly defined CSP
yuchi on HN
Requests
Guidance on making React password fields uncontrolled
From 3 comments
This is speculative as I haven't tested out this vulnerability or attempted to avoid it (yet), but I imagine this means it would be a good idea to make password fields…
enobrev on HNI believe using `defaultValue` instead of `value` would be an appropriate remediation.
Cyranix on HNOne option is to make the input component uncontrolled by removing the value={this.state.password} prop, but keeping the onChange handler to maintain the password in the state…
oblosys on HN
Questions
Does it work on normal typed input without attribute updates?
From 2 comments
Hmm, that's pretty bad. CSS probably shouldn't be able to read password inputs. Edit: This doesn't seem to work for me in Chrome 63.0.3239.132 Edit 2: OK, so it appears that this…
rickdmer on HNNo it does not. CSS selectors do not apply to input content and `[value]` selectors apply to attributes, which are not updated by just typing in it. This is not a CSS keylogger…
bfred_it on HN
Alternatives named
CrookedStyleSheets webfont unicode-range keylogging
From 1 comment
To some limited degree (you can detect presence, not position or number of occurences of character), you can do CSS only 'keylogging' even for non-reactive (sans JavaScript)…
myfonj on HN
CSS Exfil research by Mike Gualtieri
From 1 comment
You'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. The original post on this talks about it…
sachleen on HN