Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Document reasoning to block DNS to 127.0.0.1

github.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Document reasoning to block DNS to 127.0.0.1

#21

Post by Alupis »

josephcsible wrote: post #4

This is the explanation given by the person who committed this change: > Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost. It makes no sense to me. Unless someone knows of a better reason, I'…

I've got to ask - if you're doing local dev or whatever, what's so hard about turning ublock off for your dev site?

The logic seems ok for "out in the wild" cases - but ublock still let's you override stuff if you know what you're doing.

Re: Document reasoning to block DNS to 127.0.0.1

#22

Post by oefrha »

bawolff wrote: post #19
josephcsible wrote: post #4

This is the explanation given by the person who committed this change: > Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost. It makes no sense to me. Unless someone knows of a better reason, I'…

I thought chrome was now blocking this anyways unless you specificly opt in with CORS.

It’s called Private Network Access and it’s still behind an experimental flag for now.

https://wicg.github.io/private-network-access/

https://developer.chrome.com/blog/private-network-access-upd...

Also ws/wss has no SOP/CORS which could be a problem, but that has nothing do with the domain blocking here.

Re: Document reasoning to block DNS to 127.0.0.1

#23

Post by albert_e »

LinuxBender wrote: post #12
josephcsible wrote: post #4

This is the explanation given by the person who committed this change: > Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost. It makes no sense to me. Unless someone knows of a better reason, I'…

I've debated that reasoning in the security field and it just goes round-and-round in circles. There are legit cases to avoid this but less about security and more about scanning tools that poorly detect attempts to the loop-back as DNS rebinding attacks vs. an actual DNS rebinding attack which requires malicious code. So avoiding this can avoid some false positives from 3rd party scanners and having to get into sill…

> park wildcard sub-domains on 127.0.0.1

that sounds like a good practice -- why is this not done more often I wonder.

EDIT: on a second thought i am not so sure. I am not an expert here so I will not try to guess :)

Re: Document reasoning to block DNS to 127.0.0.1

#24

Post by kodah »

This is pretty unrealistic even given the maintainers example:

> Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost.

That web server would need to be configured for CSRF and CORS of that specific domain as well. If this were an attacker then it wouldn't take long to seize that domain.

To fully extrapolate that, the server would only be accessible by the users machine. There's no implication of "third party access". Maybe if they were demanding the website to have a higher classification of verification for their certificate I'd understand, but frankly without an example of where and how this is a vector I'm skeptical.

Re: Document reasoning to block DNS to 127.0.0.1

#25

Post by mirashii »

kodah wrote: post #24

This is pretty unrealistic even given the maintainers example: > Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost. That web server would need to be configured for CSRF and CORS of that specif…

The example is later in the thread, search for "DNS Rebinding" and the related discussion on the ticket, or in your search engine of choice.

Re: Document reasoning to block DNS to 127.0.0.1

#26

Post by cookiengineer »

While I think that I somewhat agree with their reasoning, someone must also say that we are quickly in multicast territory here.

Should websites be allowed to resolve airprint or airdrop based devices, given the history of CSRF vulnerabilities in consumer routers? Probably not.

Devs seem to confuse that most humans are not developers, and therefore easylist's decision to do so has that kind of context.

The point of those lists is to block away access to local domains so a malicious website that got through the filters isn't able to pwn your whole network.

And if we are discussing whether or not websites should be allowed to access the local network, then you are probably someone who doesn't give a damn about securing those devices anyways.

Re: Document reasoning to block DNS to 127.0.0.1

#27

Post by charcircuit »

oefrha wrote: post #22
bawolff wrote: post #19

Earlier quoted context omitted.

I thought chrome was now blocking this anyways unless you specificly opt in with CORS.

It’s called Private Network Access and it’s still behind an experimental flag for now. https://wicg.github.io/private-network-access/ https://developer.chrome.com/blog/private-network-access-upd... Also ws/wss has no SOP/CORS which could be a problem, but that has nothing do with the domain blocking here.

The link you gave said it released 2 years ago in Chrome 94.

Re: Document reasoning to block DNS to 127.0.0.1

#28

Post by oefrha »

oefrha wrote: post #16

Not a fan of EasyPrivacy. It seems to be run by trigger happy people with pretty limited understanding of the web. They once blocked workers.dev (Cloudflare Workers) wholesale[1], resulting in a huge flood of issue reports for a few FOSS services of mine. Guess they've never heard of public suffixes. This one appears to be someone reading about DNS rebinding attack somewhere, then pulling the trigger without understa…

Edit: Actually, DNS rebinding was brought up by the issue reporter, all that the committer presented was some handwavy "give me a reason I shouldn't block this"... How about checking the sites you blocked for a reason.

Re: Document reasoning to block DNS to 127.0.0.1

#29

Post by oefrha »

charcircuit wrote: post #27
oefrha wrote: post #22

Earlier quoted context omitted.

It’s called Private Network Access and it’s still behind an experimental flag for now. https://wicg.github.io/private-network-access/ https://developer.chrome.com/blog/private-network-access-upd... Also ws/wss has no SOP/CORS which could be a problem, but that has nothing do with the domain blocking here.

The link you gave said it released 2 years ago in Chrome 94.

That's why I said "behind an experimental flag". Search for "private network" in chrome://flags.

Oh I see what you mean. The default blocking behavior in Chrome 94 only applies to public non-secure contexts. We’re talking about a stricter form applied to secure contexts here.

Re: Document reasoning to block DNS to 127.0.0.1

#30

Post by jeroenhd »

oefrha wrote: post #18
jeroenhd wrote: post #8

Annoying, but understandable. There's a reason localhost gets special treatment, as do many other local addresses. Local dev sites easily form a fingerprint that you don't want trackers to be able to use. I'm not sure why this applies to first party browsing, though. In its current form ( https://github.com/easylist/easylist/blob/master/easyprivacy... ) several of these domains got the $third_party modifier which sho…

> you can't get HTTPS for these domains What are you talking about? Certificate insurance and DNS A/AAAA records are entirely decoupled. Use the ACME dns-01 challenge to get a cert for domains resolving to anything, including 127.0.0.1 or ::1. Alternatively you can even use http-01 or other challenges to get a wildcard cert, with subdomains pointing to localhost. I use Lets Encrypt certs for localhost and LAN every d…

Sure you can get a certificate for those domains, but not the domains you don't own. If I can get a cert for localho.st, someone made a huge mistake.

You can set up a localhost redirect on your own domain no problem, and you can even use a local DNS server to make sure nobody can abuse your localhost redirect so your domain doesn't get filtered out by tools like these.

However, I assume someone using fbi.com because it happens to redirect to localhost doesn't own a domain (or can't be bothered to set up a redirect of their own).

Post reply on HN