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

161–170 of 173 posts

Re: Show HN: A CSS Keylogger

#161

Post by blablabla123 »

oblosys wrote: post #39
rickdmer wrote: post #3

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

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

Maybe they will have to rethink it. It seemed odd when they introduced it and at least in the early React version kept making problems e.g. when entering German Umlaute on US keyboards. Not working much on Frontend anymore but when I do inputs, I only use uncontrolled ones - it's much less hassle and more flexible anyways.

Re: Show HN: A CSS Keylogger

#162

Post by Buge »

teilo wrote: post #44

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.

Even if the site doesn't use javascript to update the DOM, it's still vulnerable to similar attacks [0]. The real problem that the attacks relies on is the ability to inject CSS that can load external resources. And Instagram doesn't allow that.

[0] https://news.ycombinator.com/item?id=16427394

Re: Show HN: A CSS Keylogger

#163

Post by always_good »

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 }

It might be a fair workaround, but it sucks to regress to storing truth in the DOM.

Re: Show HN: A CSS Keylogger

#164

Post by insin »

baddox wrote: post #149
rav wrote: post #147

Earlier quoted context omitted.

You can still do form validation on submit though, according to dimgl's earlier comment: https://news.ycombinator.com/item?id=16426131

Very good point! With that method you can still display validation errors in a “Reacty” way. But you still don’t get pre-submit validation, like marking an input invalid on blur, or displaying real-time password strength.

You can still capture an uncontrolled input's data `onChange` and `onBlur` for validation, password strength checking, later submission etc., you just don't reflect it back into the input on every render.

The only thing it affects is your ability to change the input's data via a state change, but for a password field would you ever want to do anything but get its current value or clear it?

Re: Show HN: A CSS Keylogger

#165

Post by baddox »

insin wrote: post #164
baddox wrote: post #149

Earlier quoted context omitted.

Very good point! With that method you can still display validation errors in a “Reacty” way. But you still don’t get pre-submit validation, like marking an input invalid on blur, or displaying real-time password strength.

You can still capture an uncontrolled input's data `onChange` and `onBlur` for validation, password strength checking, later submission etc., you just don't reflect it back into the input on every render. The only thing it affects is your ability to change the input's data via a state change, but for a password field would you ever want to do anything but get its current value or clear it?

You’re right. With a little effort you could create reusable React form fields that are not controlled but which communicate their value/blur/etc. back to React for validation purposes.

And yes, for password inputs, I can’t think of a case where you would absolutely need to control the value via React. Things like password confirmation validation and password strength indicators can be implemented via onChange and onBlur. It’s more tedious than the normal controlled input pattern, but given vulnerabilities like this one, it’s likely worth creating reusable uncontrolled inputs.

Re: Show HN: A CSS Keylogger

#166

Post by yuchi »

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

Or just use correctly defined CSP

Re: Show HN: A CSS Keylogger

#167

Post by twhb »

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.

What might be a problem is developers not treating it as such.

Re: Show HN: A CSS Keylogger

#168

Post by Manishearth »

myfonj wrote: post #146

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) input: you don't have to use attribute selector (which does't work without physical updates), but can exploit webfont with single letter `unicode-range` chunks. Posted it [1] to CrookedStyleSheets [2] some time ago: css keylogger @font-face { fon…

This will not work with password fields.

Re: Show HN: A CSS Keylogger

#169

Post by na85 »

gear54rus wrote: post #144
elliotec wrote: post #126

Earlier quoted context omitted.

...What?

just the first stage of 'I hate JS because it's cool to hate JS' second stage is 'OMFG this website doesn't work for me. How could developer not think about my entitled ass and not spend 2x time to make it work without JS?'

No, that's not it at all.

It's the only reasonable response to the user-hostile dumpster fire that is the current web. Javascript has made the web better in a small handful of ways, and made the web significantly worse in every other way.

Re: Show HN: A CSS Keylogger

#170

Post by enobrev »

yuchi wrote: post #166
enobrev wrote: post #67

Earlier quoted context omitted.

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

Or just use correctly defined CSP

I hadn't realized a CSP could protect against this sort of thing. Thanks for the tip!
Post reply on HN