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

111–120 of 173 posts

Re: Show HN: A CSS Keylogger

#111

Post by tritium »

alasdair_ wrote: post #80
tritium wrote: post #7

To be really dangerous, I think this would need to defeat client-side cache strategies. If the browser caches each resource, the server-side reads wouldn't account for repeated characters or overall length with perfect accuracy. Consider palindromes like "racecar." This would still put many, if not most, passwords within guessable striking distance, for anyone able to intercept plain-text HTTP traffic, between Alice…

The server just returns a 400, causing the browser to no longer cache it.

True! And now I’m realizing, depending on position in the network, the server doen’t even need to exist, if one only needed to MITM the request traffic... Geeze.

Re: Show HN: A CSS Keylogger

#112

Post by 15155 »

maxchehab wrote: post #88
wuyishan wrote: post #41

Couldn't Content Security Policy (CSP) [1] be used to mitigate this attack? [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

It actually can't. Instagram does use this protect java-script injection from extensions, but clearly injecting CSS is allowed.

The requested resource, however, could be blocked by a CSP.

Re: Show HN: A CSS Keylogger

#113

Post by mrtksn »

djsumdog wrote: post #99
oblosys wrote: post #39

Earlier quoted context omitted.

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

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

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 special setter function so that the changes can be reflected globally.

Re: Show HN: A CSS Keylogger

#115

Post by Klathmon »

criswell wrote: post #43
akincisor wrote: post #12

Earlier quoted context omitted.

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.

Well there's the start [value^=a], the end [value$=a] and the "anywhere" [value*=a] selectors.

In something like 13000 selectors you could easily get the first 2, last 2, and any characters in the middle that are in the password making targeted attacks significantly easier. (This is based on very-very rough napkin math assuming an ~80 character dictionary for upper/lower, numbers, and "symbols" since I didn't want to count)

That's a lot, but it's well within the realm of possibility (it looks like that would end up as about a 1mb css file)

Re: Show HN: A CSS Keylogger

#116

Post by dillondoyle »

jakobegger wrote: post #40
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.)

Something like conditional formatting maybe? Eg. make negative values red? Make an input field red when it contains an invalid character?

I was also thinking along those lines, a way to LINT/validate form fields when JS is disabled, but seems like a very obscure and inefficient (use html5 validation + js, validate server side on submit)

Re: Show HN: A CSS Keylogger

#117

Post by Klathmon »

eterm wrote: post #100
brailsafe wrote: post #98

Earlier quoted context omitted.

Where does 41000 come from?

It's 8! (8 factorial) which is 40320. This is 127,286,426,869 (~128bn) times smaller than 92^8. Edit: Note that if you have a repeated character in your 8 charcter password then the number of permutations of the set of 8 (7 distinct) characters is further halved to 20,160.

And just by doubling the amount of selectors you could always check for a repeated character! (AKA [value$=aa], [value$=bb], etc...)

Re: Show HN: A CSS Keylogger

#118

Post by ateesdalejr »

cag_ii wrote: post #57
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.

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.

Re: Show HN: A CSS Keylogger

#120

Post by tmerse »

X-Istence wrote: post #85
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.

> it depends on some js code updating the dom for each key press Like React with JSX?

It may be easier to XSS CSS than JS.
Post reply on HN