Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A CSS Keylogger

github.com

Post reply on HN
Print view View original

151–160 of 173 posts

Re: Show HN: A CSS Keylogger

#151

Post by early »

netsharc wrote: post #143
Francute wrote: post #65

Earlier quoted context omitted.

Not an efficient keylogger, however, if you know the pressed keys, you can just generate permutations ordered using probabilities, and that would be a lot faster than brute force. The real deal here is, it depends on some js code updating the dom for each key press, which is BAAAD. Not an useless keylogger, because it reminds a vulnerability product of choosing a bad decision.

Interestingly the password "BAAAD" would generate 3 requests to the logging server, since it wouldn't request the background image for the letter "A" more than one time. Or shouldn't, anyway.

That depends on cache headers sent from the server, which the attacker controls

Re: Show HN: A CSS Keylogger

#152

Post by baddox »

dimgl wrote: post #125
poxrud wrote: post #92

Earlier quoted context omitted.

For those that are confused, updating the property would mean: this.input.value = 'password'; This would be fine. However updating the attribute (the way React recommends it with controlled components) would be something like: This would be vulnerable to the the CSS keylogger.

That being said, you might be thinking about this incorrectly if you're doing this. You can use a form and grab the values on submission. this.handleSubmission = event => { // access to event.target.password.value }

You still lose things like validation on blur and displaying real-time password strength.

Re: Show HN: A CSS Keylogger

#153

Post by ry_ry »

Illniyar wrote: post #145
Kequc wrote: post #130

This exploit might be defeated with the following css: input[type="password"] { background-image: none !important; } 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.

Actually if you use inline style with important there is no way to override it. I.e.

Although that does rely on targeting that specific attribute. There are probably a handful of ways to trigger an http request in this instance.

You don't actually even need to select that specific node - whilst you can't use :after on replaced elements, if the input has a sibling an attacker could input[type="password"] + div:after or something along those lines.

The main takeaway for me is that making a password field a controlled component is a marginal security risk in some instances, and letting people pump their own styles into sign-in pages is a bad idea.

Re: Show HN: A CSS Keylogger

#154

Post by ry_ry »

Manishearth wrote: post #109
jandrese wrote: post #4

CSS 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?

This isn't a CSS feature, CSS does not let you select on the value of a password field (it lets you select on the value of the `value` attribute , which doesn't change when you type) This is a React feature, where React apps specifically use the value attribute (`element.setAttribute("value", ...)`) to set the value, instead of `element.value`.

Or if that attribute was populated via props from it's parent, which is a more common implementation.

Re: Show HN: A CSS Keylogger

#157

Post by spyder »

gsnedders wrote: post #47
dmitrygr wrote: post #31

Earlier quoted context omitted.

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.

You can just add the two (or more) letter permutations to the CSS to help to identify the previous characters. ( like [value$="aa"] )

Re: Show HN: A CSS Keylogger

#158

Post by spyder »

javajosh wrote: post #101

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.

yea, and also when copy-pasting the password.

Re: Show HN: A CSS Keylogger

#159

Post by endless1234 »

xab9 wrote: post #103
djsumdog wrote: post #99

Earlier quoted context omitted.

So with frameworks like React/Vue, every change to a field generates a request? Or are those handled locally in the shadow dom?

Technically yes. You can see it in the network panel.

Not at all. Sending off requests is a different thing entirely to controlled inputs, and you don't need a controlled input to do a request every keypress.

Re: Show HN: A CSS Keylogger

#160

Post by oblosys »

enobrev wrote: post #67
oblosys wrote: post #39

Earlier quoted context omitted.

If you use React, updating the value on every change is a very common pattern.

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 "uncontrolled"[1] if you're using react. 1: https://reactjs.org/docs/uncontrolled-components.html

One 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 for validation & strength checking. Typically, the only time you need to programmatically change a password field is when clearing it, which can be done by setting the DOM attribute directly.
Post reply on HN