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

121–130 of 173 posts

Re: Show HN: A CSS Keylogger

#121

Post by quickthrower2 »

commandlinefan wrote: post #16

ALWAYS browse with devtools open, and pay close attention to every packet that's being sent out (especially when you're not expecting any to...)

That's not enough if you are using an online crypto wallet. You also need to check if the seeding is deterministic. And also it could send the data 'later' when you next visit the site rather than now, storing it in indexeddb/localstorage/ etc. So you have a false sense of security.

Also as in this example loading a .jpg could be a way of communicating something.

Re: Show HN: A CSS Keylogger

#122

Post by roywiggins »

hinkley wrote: post #93
plopz wrote: post #68

Earlier quoted context omitted.

Even if the attacker got them out of order, it would let them be able to brute force guess in a small number of attempts.

For example, there are about 41,000 possible passwords for a given set of 8 characters, out of around 96^8 possible 8 character passwords (in the ASCII character set).

And if any of those are words or almost words, you'd guess that first and probably have it.

Re: Show HN: A CSS Keylogger

#123

Post by cag_ii »

ateesdalejr wrote: post #118
cag_ii wrote: post #57

Earlier quoted context omitted.

It'd be simple enough to add an 'order' identifier (request timestamp, etc) to the requests. Edit: nm. My mistake, not as easy as that using only css!

Why would you even need an order identifier? All you need to do is check the request logs for your server everything should be already in order.

I was replying to the comment above which pointed out correctly that the order in which the server receives the requests may differ from the order in which they were sent.

Re: Show HN: A CSS Keylogger

#124

Post by arca_vorago »

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

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.

Re: Show HN: A CSS Keylogger

#125

Post by dimgl »

poxrud wrote: post #92
criswell wrote: post #54

Earlier quoted context omitted.

Hopefully most are updating the property and not the attribute.

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
    }

Re: Show HN: A CSS Keylogger

#126

Post by elliotec »

arca_vorago wrote: post #124
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

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?

Re: Show HN: A CSS Keylogger

#127

Post by elliotec »

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.

Do you mind expanding on this a little? Or linking to a documentation or something

Re: Show HN: A CSS Keylogger

#129

Post by fareesh »

moojd wrote: post #66
AndrewStephens wrote: post #36

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

I could see this being an issue on sites that allow custom css (reddit)

The combination of the two prerequisite conditions is probably tiny. JS needs to update the css accessible value attribute of the field as well. That's a less likely situation. I guess anything that's react + this auth method + custom CSS is vulnerable. Can't think of anything that does all three.

Re: Show HN: A CSS Keylogger

#130

Post by Kequc »

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.

Post reply on HN