Hacker News Reader

Comment by AndrewStephens | Hacker News Reader

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?

View on HN

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

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

Thanks, 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.

React doesn't work that way. It's a convention which I persoally have always found questionable.

It'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

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

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.

You 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?

You’re right. With a little effort you could create reusable React form fields that are not controlled but which communicate their value/blur/etc. back to React for validation purposes.

And yes, for password inputs, I can’t think of a case where you would absolutely need to control the value via React. Things like password confirmation validation and password strength indicators can be implemented via onChange and onBlur. It’s more tedious than the normal controlled input pattern, but given vulnerabilities like this one, it’s likely worth creating reusable uncontrolled inputs.

I think the doc ought to be updated to say that you shouldn't make a password field a controlled component, and maybe even warnings added if you set value at all.

Why do you find it questionable, other than the possibility of attacks like this?

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.

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

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

> The Instagram password field mentioned in the readme.md DOES work this way due to some custom javascript, for reasons that escape me.

React.

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

Javascript can be blocked from chrome extensions. In fact, Instagram does block javascript. However, clearly css is not blocked.

What do you mean by "Instagram does block javascript"? What JS does it block?

You can't event get a list of extensions installed (from a page), but please do tell. You mean generic blocking via CSP/HSTS?

Reply on news.ycombinator.com