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

    Seems like a TCP/IP stack issue rather than a browser issue… 0.0.0.0 is not supposed to be a valid address (in fact, no IPv4 address with 0 as the first octet is a valid destination IP). The network stack should be dropping those packets.

    0.0.0.0 is only valid in a few use cases. When listening for connections, it means “listen on all IPs”. This is a placeholder that the OS handles - it doesn’t literally use that IP. Also, it’s used as the source address for packets where the system doesn’t have an IP yet (eg for DHCP). That’s it.

      • dan@upvote.au
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        From that RFC:

        0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
        network.  Address 0.0.0.0/32 may be used as a source address for this
        host on this network; other addresses within 0.0.0.0/8 may be used to
        refer to specified hosts on this network ([RFC1122], Section
        3.2.1.3).
        

        (note that it only says “source address”)

        which was based on RFC 1122, which states:

        We now summarize the important special cases for Class A, B,
        and C IP addresses, using the following notation for an IP
        address:
        
            { <Network-number>, <Host-number> }
        
        or
            { <Network-number>, <Subnet-number>, <Host-number> }
        
        ...
        
        (a)  { 0, 0 }
        
        This host on this network.  MUST NOT be sent, except as
        a source address as part of an initialization procedure
        by which the host learns its own IP address.
        
        See also Section 3.3.6 for a non-standard use of {0,0}.
        

        (section 3.3.6 just talks about it being a legacy IP for broadcasts - I don’t think that even works any more)

      • Kissaki@beehaw.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        notably

        Windows is not impacted by this issue.

        quoting the main, critical part:

        1. Under public domain (.com), the browser sent the request to 0.0.0.0.
        2. The dummy server is listening on 127.0.0.1 (only on the loopback interface, not on all network interfaces).
        3. The server on localhost receives the request, processes it, and sends the response.
        4. The browser blocks the response content from propagating to Javascript due to CORS.

        This means public websites can access any open port on your host, without the ability to see the response.