• Hirom ( Hirom@beehaw.org ) 
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    4時間前

    Add the websites to existing malware blocklists, ideally ones that are loaded by default by uBlock Origin, and browsers with integrated blocklists.

    This would protect visitors, and make the problem harder to ignore for webmasters since lots of visitor would get a big read scary screen. This is a radical option, but fixing this mess would take such a radical action.

    If the list is widely disseminated and absorbed into blocklists, trying to get your domain of those lists afterwards is close to impossible. For a small business, that could be devastating.

    It is also devastating for visitors when their savings gets stolen by malware distributed by infected websites.

    Notify webmasters and give 1 week to fix the issue. If webmasters fails to fix the issue or are unreachable, adding them to blocklist seems appropriate.

    • ryper ( ryper@lemmy.ca ) 
      link
      fedilink
      English
      arrow-up
      18
      ·
      16時間前

      I know the implication is supposed to be “Not to his face”, but if the boss a huge mistake it’s good to have some record (like an email) that you told him.

  • tal ( tal@lemmy.today ) 
    link
    fedilink
    English
    arrow-up
    6
    ·
    15時間前

    Why not just send an email to every website?

    I could probably try to automate that, but to what email address? I’d have to hit a selection of common ones, info@, support@, abuse@, maybe others?

    I’d use “webmaster@”, which is a pretty long-running convention, though I don’t know how many people have it set up. I don’t know if there’s an RFC backing that.

    If you’re going to provide a standard contact admin email for a website, that’s where I’d expect it to be, at any rate.

    EDIT:

    Yeah, webmaster@; RFC 2142.

    https://www.rfc-editor.org/info/rfc2142/

    RFC 2142: Mailbox Names for Common Services, Roles and Functions

    Various Internet documents have specified mailbox names to be used
    when reaching the operators of the new service; for example, [RFC822
    6.3, C.6] requires the presence of a <POSTMASTER@domain> mailbox name
    on all hosts that have an SMTP server.  Other protocols have defacto
    standards for well known mailbox names, such as <USENET@domain> for
    NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]).
    Defacto standards also exist for well known mailbox names which have
    nothing to do with a particular protocol, e.g., <ABUSE@domain> and
    <TROUBLE@domain>.
    
    The purpose of this memo is to aggregate and specify the basic set of
    mailbox names which organizations need to support.
    
    5.  SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES
    
    For major Internet protocol services, there is a mailbox defined for
    receiving queries and reports.  (Synonyms are included, here, due to
    their extensive installed base.)
    
    MAILBOX        SERVICE             SPECIFICATIONS
    -----------    ----------------    ---------------------------
    POSTMASTER     SMTP                [RFC821], [RFC822]
    HOSTMASTER     DNS                 [RFC1033-RFC1035]
    USENET         NNTP                [RFC977]
    NEWS           NNTP                Synonym for USENET
    WEBMASTER      HTTP                [RFC 2068]
    WWW            HTTP                Synonym for WEBMASTER
    UUCP           UUCP                [RFC976]
    FTP            FTP                 [RFC959]
    
    • Ooops ( Ooops@feddit.org ) 
      link
      fedilink
      arrow-up
      2
      ·
      14時間前

      I’d use “webmaster@”, which is a pretty long-running convention

      Another option is looking for the security.txt (toplevel or under .well-known/) of a site (that’s RFC 9116, which should have a Contact field with a mailto:<contact address> field (although tel:<number> and https://<contact information page> are allowed, too, although far less common).

      • tal ( tal@lemmy.today ) 
        link
        fedilink
        English
        arrow-up
        2
        ·
        13時間前

        Yeah, he mentioned security.txt in the article, but complained that few implemented it.

        I guess that even if someone who apparently does computer security isn’t familiar with it, that Average Joe probably has no idea. Maybe there’s an argument that there should be some sort of Web browser support for “report problem with this page/site” that sends an email to an appropriate address with an URL for the page and comment so that people are more aware of it.

        • Ooops ( Ooops@feddit.org ) 
          link
          fedilink
          arrow-up
          3
          ·
          12時間前

          but complained that few implemented it

          Now that you mention it… I decided to check our lemmy instances and both lemmy.today and feddit.org have a robots.txt (of course^^) but no security.txt *sigh*

          Yours didn’t even bother to fill out the /legal page (which should also have contact information) although it’s a fixed part of the lemmy software with a link at the bottom of the site.

  • Can we see the list so I can know if my site is vulnerable and fix it?

    Why hasn’t the list of sites been published? There are a few reasons:

    • I didn’t want this to be a ‘name and shame’ as the sites on that list are, after all, victims of attacks. Someone broke into their site, and the owners probably have no idea.
    • If the list is widely disseminated and absorbed into blocklists, trying to get your domain of those lists afterwards is close to impossible. For a small business, that could be devastating.
    • Many of these websites were likely infected because of an existing vulnerability that was exploited in something like WordPress, Magento or similar. Handing out a list of viable targets does not seem like a good idea.

    Cynically speaking, their story disappears if too many people fix their websites.