4 ms·
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'
by AndrewStephens 9y ago
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 to inject your evil CSS into a page, why not go the whole hog and inject evil ecmascript instead?
- regularhackerer 9y agoAll you need is a website with a vulnerable password form and the ability to serve malicious CSS, say, via an ad. Seems pretty dangerous to me.
- slig 9y ago> The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me Instagram is a React app and React works that way.
- AndrewStephens 9y agoThanks, always nice to hear from somebody who knows something. So this seem like a flaw in React rather than a flaw in browsers - there is no reason to leak the typed-in password value into the the value attribute where CSS can get its' grubby mitts on it.
- bfrydl 9y agoReact doesn't work that way. It's a convention which I persoally have always found questionable.
- benatkin 9y agoIt's more than a convention. It's presented as the default way to do it in the official docs. https://reactjs.org/docs/forms.html#controlled-components https://reactjs.org/docs/forms.html#controlled-components
- acostanza 9y agoCould use an uncontrolled component, which I don't think is vulnerable? https://reactjs.org/docs/uncontrolled-components.html https://reactjs.org/docs/uncontrolled-components.html For simple username/password entry I see no reason to use a controlled component.
- baddox 9y agoThat 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.
- rav 9y agoYou can still do form validation on submit though, according to dimgl's earlier comment: https://news.ycombinator.com/item?id=16426131 https://news.ycombinator.com/item?id=16426131
- baddox 9y agoVery 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.
- insin 9y agoYou 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?
- baddox 9y agoWhy do you find it questionable, other than the possibility of attacks like this?
- maxchehab 9y agoJavascript can be blocked from chrome extensions. In fact, Instagram does block javascript. However, clearly css is not blocked.
- humblebee 9y ago> The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me. React.
- moojd 9y agoI could see this being an issue on sites that allow custom css (reddit)
- fareesh 9y agoThe 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.
- AntonyGarand 9y agoFirewalls blocking javascript would let this pass, NoScript users would get their info stolen, CSS injection vulnerabilities may not allow a XSS as well. If you do control the page, there may not be that many reasons, but if you only have a limited entry-point, this is very interesting.
- lambda 9y ago> Also, if you are going to all the trouble of making an extension to inject your evil CSS into a page, why not go the whole hog and inject evil ecmascript instead? That may just be for the proof of concept. There are websites which allow users to customize themes of certain pages; such at Tumblr and Reddit. I believe these allow custom CSS. There are probably plenty of other places where it may be possible to inject CSS but not JavaScript. So, it's worth demonstrating the vulnerability, even if the current way of distributing it only really makes sense for testing purposes.
- xab9 9y agoBecause of access levels. You may install an extension that requires no access to anything interesting (hey it's just harmless css), but may refuse to install something that wants to read your dom. Another fun thing: user css / theme extensions where you only install themes. Themes are not dangerous, are they? It's just eyecandy.