Couldn't Content Security Policy (CSP) [1] be used to mitigate this attack?
Show HN: A CSS Keylogger
41–50 of 173 posts
Re: Show HN: A CSS Keylogger
#42Hmm, 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 will only work on a password input that updates its "value" attribute with the typed in value. This doesn't happen unless there is JavaScript that updates the value attr with the input.value
Is there even a use case where CSS needs to read any field's value? (Checkboxes and radio buttons have :checked.)
It might be useful to show/hide certain parts of the form depending on a value selected in dropdown (SELECT) control. As for text input controls - perhaps to highlight the content when value matches expected (but not required) pattern.
Re: Show HN: A CSS Keylogger
#43Hmm, 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 will only work on a password input that updates its "value" attribute with the typed in value. This doesn't happen unless there is JavaScript that updates the value attr with the input.value
I think it would work against password managers like LastPass which fill in passwords using JS.
It would only give you the last character of the password though. You can use CSS selectors to check the start [value^=a] and anything in the middle [value*=a] as well though which can be revealing I imagine.
Re: Show HN: A CSS Keylogger
#44This 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.
Re: Show HN: A CSS Keylogger
#45This 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. The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me. [edit] Other people pointed this out first. Also, if you are going to all the trouble of making an extension…
Javascript can be blocked from chrome extensions. In fact, Instagram does block javascript. However, clearly css is not blocked.
Re: Show HN: A CSS Keylogger
#46Earlier quoted context omitted.
Browser support (not using Flexbox because of IE) is not that hard once you get your head around it: view-source: http://alistapart.com/d/holygrail/example_3.html http://alistapart.com/d/holygrail/example_3.html
Falls apart entirely on phones (tiny columns of one word wide each, AND horizontal scrolling), so you only proved OP's point...
Well, of course. That's simply a three column layout example without any responsive media queries. It's the bare minimum to a three column "holy grail". If anything, you could simply add the viewport meta tag to have the user's phone zoom in automatically.
However, making this example responsive is a piece of cake:
@media only screen and (max-width: 1024px) {
* {
float: none !important;
width: 100% !important;
margin: 0 !important;
padding: 0 !important;
position: relative !important;
right: auto !important;
left: auto !important;
}
(Terrible CSS simply to show how easy it is to make it responsive. Normally you wouldn't wildcard important everything but target the right classes. I can't be bothered, this gets the point across.)
Re: Show HN: A CSS Keylogger
#47Earlier quoted context omitted.
So wouldn't that mean, then, that your CSS matchers would have to contain absolutely every permutation of text possible?
No, since it matches only the last character, you watch the requests it makes IN order to get the entire password. As you type "qwerty", it will request "Q", "W", "E", "R", "T", and finally "Y" no permutations needed
Assuming the server receives the requests in the same order as the requests were sent, which on mobile networks isn't anywhere near so certain.
Re: Show HN: A CSS Keylogger
#48This 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. The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me. [edit] Other people pointed this out first. Also, if you are going to all the trouble of making an extension…
> The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me.
React.
Re: Show HN: A CSS Keylogger
#49CSS has gone too far. At least when I'm worried about a nasty javascript attack from a site I can be somewhat reassured that noscript/umatrix will work. Am I going to have to start whitelisting CSS now too? Am I too late?
As other comments have stated, this only works if the 'value' attr is being set on the input box as you type (which React will do), so it still requires JS.
Re: Show HN: A CSS Keylogger
#50This 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. The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me. [edit] Other people pointed this out first. Also, if you are going to all the trouble of making an extension…
> The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me Instagram is a React app and React works that way.
Thanks, always nice to hear from somebody who knows something. So this seem like a flaw in React rather than a flaw in browsers - there is no reason to leak the typed-in password value into the the value attribute where CSS can get its' grubby mitts on it.