Archived link

The polyfill.js is a popular open source library to support older browsers. 100K+ sites embed it using the cdn.polyfill.io domain. Notable users are JSTOR, Intuit and World Economic Forum. However, in February this year, a Chinese company bought the domain and the Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io. Any complaints were quickly removed (archive here) from the Github repository.

    • letsgo@lemm.ee
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 months ago

      What rules can we add that solve this problem? (I’ve tried DDG but didn’t find any results)

      • Supermariofan67@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 months ago

        This one is already in the default uBlock filters - Badware risks

        I also strongly suggest adding https://big.oisd.nl/ as a filter list. It’s a large and well maintained domain blocklist (sourced from combining lots of other blocklists) that usually adds lots of these sorts of domains quickly and has very few false positives.

        If you want to take it even further, check out the Pro list and Thread Intelligence Feeds list here https://github.com/hagezi/dns-blocklists

        These can all be added to a pihole too if you use one.

  • originalucifer@moist.catsweat.com
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    nah. over 100k sites ignored dependency risks, even after the original owners warned them this exact thing would happen.

    the real story is 100k sites not being run appropriately.

  • dan@upvote.au
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    2 months ago

    My favourite part is that the developers that currently own it said:

    Someone has maliciously defamed us. We have no supply chain risks because all content is statically cached

    https://github.com/polyfillpolyfill/polyfill-service/issues/2890#issuecomment-2191461961

    Completely missing the point that they are the supply chain risk, and the fact that malicious code was already detected in their system (to the point where Google started blocking ads for sites that loaded polyfill .io scripts.

    We don’t even know who they are - the repo is owned by an anonymous account called “polyfillpolyfill”, and that comment comes from another anonymous account “polyfillcust”.

    • Treczoks@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      I’m not into JS stuff, but when I read that google is blocking ads, shit must be flowing in gargantuan amounts…

    • UnderpantsWeevil@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      Frustrating that the article doesn’t specify and simply links to a different Github page which doesn’t clearly specify the problem either.

      I have to assume the site’s article was dynamically generated, without any actual tech journalist doing the reporting. The byline is “Sansec Forensics Team” which doesn’t even link out to the group. Also, the “Chinese Company” isn’t named either it the article or the references, which is incredibly shoddy reporting. The archive link is dead.

      This whole page is indicative of the failed state of tech journalism. A genuinely explosive story but its so threadbare and vague that it becomes meaningless.

      • sorter_plainview@lemmy.today
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        2 months ago

        The site is Sansec. They uncovered it. They also specify how the malware redirects users to sports betting sites.

  • dan@upvote.au
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 months ago

    Reposting my comment from Github:

    A good reminder to be extremely careful loading scripts from a third-party CDN unless you trust the owner 100% (and even then, ownership can change over time, as shown here). You’re essentially giving the maintainer of that CDN full control of your site. Ideally, never do it, as it’s just begging for a supply chain attack. If you need polyfills for older browsers, host the JS yourself. :)

    If you really must load scripts from a third-party, use subresource integrity so that the browser refuses to load it if the hash changes. A broken site is better than a hacked one.


    And on the value of dynamic polyfills (which is what this service provides):

    Often it’s sufficient to just have two variants of your JS bundles, for example “very old browsers” (all the polyfills required by the oldest browser versions your product supports) and “somewhat new browsers” (just polyfills required for browsers released in the last year or so), which you can do with browserslist and caniuse-lite data.

    • Echo Dot@feddit.uk
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 months ago

      Yeah I used to be guilty of this. Although in slight defense of myself I never used to use random sites like that I always used to pull everything from Google CDN since I can’t see that changing hands.

      They may very well shut it down without warning, but they’re probably not going to sell it to anyone.

      • dan@upvote.au
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        2 months ago

        Yeah, it really depends on how much you trust the vendor.

        Google? Say what you want about the company, but they’ll never intentionally serve malware.

        Random company with no track record where we don’t even know who is maintaining the code? Much less trustworthy. The polyfill . io repo is currently owned by a Github user called “polyfillpolyfill” with no identifying information.

        Third-party CDNs make less sense these days though. A lot of hosting services have a CDN of some sort. Most sites have some sort of build process, and you usually bundle all your JS and CSS (both your code and third-party code, often as separate bundles) as part of that.