[selectors-4] [backgrounds-3] Prevent CSS keylogging

[Ryuno-Ki]

Originally I've opened Bug 1440786 regarding this.

You may have heard about https://github.com/maxchehab/CSS-Keylogging that is, abusing CSS for keylogging by a mix of attribute substrings in selectors and background-image.

My intention was to get ideas on how we as web authors can deal with it.
I am a web developer and user and want my visitors, friends and family to protect against this.
My idea was that, because the browser can't tell from the URL of the background-image to its purpose, to flag this combination as suspicious (i.e. console.warn). This way, we can raise the awareness of it. An even better way would be to gather data to make an informed decision.

@dveditz of Mozilla's security team considered a fix a violation to the spec, so I am turning to the spec authors next :-)

Please keep in mind that this is my first interaction with a W3C working group directly (aside of following the MathML mailing list as reader for a while). I am open to suggestions on how to better fill issues.

Many thanks to @dveditz and @dbaron for their support on Mozilla's bug tracker.

[ewilligers]

Third party CSS is not safe.

[jakearchibald]

My intention was to get ideas on how we as web authors can deal with it.

If you use third party content it must come from a source you trust, and you must also trust their security.

Although, if you don't trust the source but you're happy with the resource content, you can use SRI to ensure the resource load fails if the content changes.

[Loirooriol]

Also see #2339 about the same issue. But don't blame CSS, blame the frameworks that expose passwords as attributes.

[Ryuno-Ki]

@jakearchibald That solves only one part of the puzzle, namely me in my responsibility as author. How can I browse the web safely as user?

[dbaron]

As a user, you should:

• use different passwords for every site (and good passwords)
• use a password manager or similar to manage them

With every site, you're trusting the site to manage your passwords safely, and that includes doing security for both their client-side code and server-side code correctly. Not using untrusted third-party code is just one aspect of good security for client-side code.

[Nadya678]

input[type="password"][value$="a"] is not: input[type="password"]:value($="a")

Sending password from server or setting it in additional parameters like React.js (a synonym of nuclear reactor) is very bad practice.

I think additionally, the value (in HTML) for <input type="password"/> should be deprecated like for files in the past.

IT IS VERY BAD PRACTICE and also is very bad practice support ::after and ::before for passwords.

[jakearchibald]

Sending password from server or setting it in additional parameters like React.js (a synonym of nuclear reactor) is very bad practice.

Sending passwords is bad because it suggests they're storing raw passwords. The sending of personal data over a secure connection isn't inherently bad, else how would you read your emails?

What React's doing isn't inherently bad either. The web guarantees the safety of the origin model.

The thing at fault is the person whole reduced the security of the origin model by trusting third party items that were not trustworthy.

I think additionally, the value (in HTML) for should be deprecated like for files in the past.

These things aren't the same. The data that was removed from the file input was also removed from the data sent to the server. I assume you aren't suggesting that password values should be blocked from the server too 😀.

If browser implemented what you're suggesting, attackers could just use a regular text input and use a font to make it look masked like a password field.

[Nadya678]

You never should send passwords from servers. Embedded ads scripts (and additions to browsers) can read value without background manipulation. If the form is bad filled by user, the password should be reentered. Never send back. Also access to password via JS (ECMAScript should be blocked.

The passwords sent from SEERVER TO BROWSER should be blocked by browser to prevent CSS and JS manipulation. The safety of password should have first priority.

[jakearchibald]

You never should send passwords from servers. Embedded ads scripts (and additions to browsers) can read value

If they have script access to your page, they don't need the server to send the password in order to read it.

[Nadya678]

And the setting and reading password inputs via JS also should be blocked forever. Passwords should be only set by user.

[Ryuno-Ki]

Could we keep in mind, that there are other <input>s than password. I image an <input> used for Credit Card numbers or similiar.

[tabatkins]

The WG resolved to close this as WONTFIX. Ultimately we don't believe there's anything we could do to stop this besides just throwing away attribute selectors entirely; you can't even do something like "don't match attribute selectors against attributes on password inputs", because as @Ryuno-Ki says, inputs other than password can show this as well.

Ultimately this is a problem combining (a) frameworks that reflect the live value of an input into an attribute, and (b) sites that allow uncontrolled 3rd-party CSS to be applied to the page. Both of these are probably mistakes on their own already (especially (b)); when combined they're an information leak.