Jake Archibald writes in his blog about the bigger problem presented by importing third-party content into web pages. Even CSS is a problem as a CSS keylogger demo showed the other day.
A few days ago there was a lot of chatter about a 'keylogger' built in CSS.
Some folks called for browsers to 'fix' it. Some folks dug a bit deeper and saw that it only affected sites built in React-like frameworks, and pointed the finger at React. But the real problem is thinking that third party content is 'safe'.
While most are acutely aware, yet ignore, the danger presentd by third-party javascript and javascript in general, most forget about CSS. Jake reminds us and walks through quite a few exampled of how CSS can be misused by third-parties exporting it.
Source : Third party CSS is not safe
(Score: 2, Informative) by Anonymous Coward on Wednesday February 28 2018, @11:24PM (3 children)
No, this does not work as you describe. The CSS attribute selector is based on the element's value attribute in the DOM, which does not depend on what the user types. Try it and see -- this selector simply does not match your example element since it has no value attribute.
With your example input, there is no value attribute, so the selector is not matched. Javascript is required to update the DOM in order for the style to be applied "dynamically". Alternately, the server could send a value attribute to start with (for example, <input type='password' value='endswitha' />, but this is static and also not changed by user input.
(Score: 2) by coolgopher on Thursday March 01 2018, @12:37AM
And this is where the comment about this attack largely depending on React like frameworks, where it's very common to make a control "managed" by keeping the authoritative state outside of the DOM and injecting it as-needed via the value="xyz" attribute of the control.
(Score: 2) by DannyB on Thursday March 01 2018, @02:34PM (1 child)
Okay. So I just now constructed a trivial example, and you're right. I cannot get this to happen.
A page H1.html:
And a responder H2.jsp:
Now my responder does not return an image. But it does print on the server's console when a request is received, and what the "char" parameter value is.
By manually invoking the URL from the browser's address bar:
I can get the server's console to print out:
But not by typing in the password field. I also tried changing the field type from password to text.
I tried in Chrome, FireFox, IE and Edge.
I also tried "relative" URLs rather than fully qualified URLs that specify the https and server name.
So I must be misunderstanding something in TFA.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Tuesday March 06 2018, @08:15PM
Styles can depend on the state of the DOM, and Javascript can update the DOM (and therefore cause style changes). Without Javascript, the DOM is fixed once the document is loaded and, for the most part, so are styles (the exceptions are certain pseudo-classes like :visited and :checked).
In TFA, the 3rd-party stylesheet is "leaking" the state of the DOM, which is updated by some 1st-party Javascript libraries. This could be a problem for website operators because they may be giving more control of their site to third parties than they imagined. (Although even without this kind of information leak stylesheets have almost total control over the document's presentation and malicious styles can do all sorts of nasty things).
But the reason I say this is an almost total non-issue for browser users is because third party content doesn't really change the story for them. Either the site is logging keystrokes or it is not. Whether that's done by 1st-party or 3rd-party scripts/styles/whatever doesn't really matter.