O only get: "Scanning localhost ... unreachable.", and there are at least 3 web servers active on the network.
Do you have WebRTC disabled? I disable it in Firefox and it breaks this test.
I can see your local web servers
121–130 of 198 posts
Re: I can see your local web servers
#122> It is not sufficient security to only bind to 127.0.0.1 (the “loopback interface”) What would be a better, more secure thing to do when you have multiple web servers on one machine behind a SSL-terminating reverse proxy?
The thing to do is not run a web browser on that machine. Run the servers in a VM.
But this seems to be able to see servers accessible to the local machine, so if my Dev server in a VM is accessible from my browser, it's accessible to any webpage in my browser?
Re: I can see your local web servers
#123Earlier quoted context omitted.
> You always are when a users visits your domain – you control the DNS of your domain. I meant you need to control the poisoned DNS If I use 8.8.8.8 as DNS you can only work on the domains you already control, which is kinda useless > You don't need access-control headers, because you stay on the same domain. No, you don't My localhost server only respond to localhost and 127.0.0.1 host header Not to mypage.com Nginx…
> But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain > you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacke…
> In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs
But it doesn't really work.
I query my DNS, on my home router, not your DNS.
And the DNS on my home router query the ISP's DNS, which caches requests.
I bet you can't go below few minutes resolution.
I had this problem when validating the Letsencrypt DNS challenge, I had to let certbot run for almost 20 minutes before my home router picked up the new value.
When I'm at work, I use the company's DNS, which ignores non standard TTLs and caches the first answer forever (well... almost) and disallow external domains that resolve to reserved IP addresses.
Re: I can see your local web servers
#124Earlier quoted context omitted.
Custom DNS server with DNS rebind protection. E.g. if you’re running OpenWRT you’re fine[1]. Also just don’t test on localhost. You can use a proper domain (or claim one in .test TLD[1] if you’re fine with selfsigned certs) and point it to localhost. If you’re going to use any redirect flow like OAuth/OpenID you’re going to need this for testing eventually anyway. [1] https://openwrt.org/docs/guide-user/base-system/d…
What do you recommend if you're running a local server? Eg, I've developed programs before with the assumption that the user will be running it either for their local machine, or perhaps for their local network. Think self hosted Wiki/etc. I was never sure (and thusly have yet to properly implement it) what would be secure, but also a good UX. A normal auth + self signed https would be simplest I imagine, but I'm not…
I actually wanted to do something similar one time and I figured there’s one way to do it:
1) Get a domain name for the project, e.g. mycoolwiki.tld
2) In the installer/setup provision for the user a random subdomain, e.g. d2c8116f19d0.mycoolwiki.tld
3) Use Let’s Encrypt DNS method to provision cert
4) Redirect d2c8116f19d0.mycoolwiki.tld to LAN IP
It’s not ideal because you need some external infrastructure and it assumes no DNS rebind protection.
However, if your webapp has a client and server, that is communicates via API only, you can actually do a lot better:
4) Setup local server to accept CORS requests from d2c8116f19d0.mycoolwiki.net only
5) Host client at d2c8116f19d0.mycoolwiki.tld
Additionally,
6) Make the client a PWA with offline support
and/or
6) Offer browser extension to use local copy of the client when user visits ∗.mycoolwiki.tld
Though for my use case I actually wanted to have ∗.mycoolwiki.tld/ipfs/ be backed by IPFS and offer generic extension that both verifies that the IPFS gateway is playing nice and (if configured) redirect to local gateway.
Also offering Electron client instead of browser would work as well and saves you getting the cert.
Re: I can see your local web servers
#125[deleted]
Re: I can see your local web servers
#126Earlier quoted context omitted.
> But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain > you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacke…
> In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs But it doesn't really work. I query my DNS, on my home router, not your DNS. And the DNS on my home router query the ISP's DNS, which caches requests. I bet you can't go below few minutes resolution. I had this problem when validating the Letsencrypt DNS challenge,…
Depends on the resolver configuration. E.g.: unbound has cache-min-ttl, a way to increase cache efficiency (and a mitigation for attacks such as rebinding).
> Time to live minimum for RRsets and messages in the cache. Default is 0. If the the minimum kicks in, the data is cached for longer than the domain owner intended, and thus less queries are made to look up the data. Zero makes sure the data in the cache is as the domain owner intended, higher values, especially more than an hour or so, can lead to trouble as the data in the cache does not match up with the actual data any more.
Which is one of the reasons I think this is manly effective against home networks.
Re: I can see your local web servers
#127Earlier quoted context omitted.
> expose a UI with a local web server I'm not talking about UIs hosted on local web servers being able to send requests to themselves, I'm talking about UIs hosted on REMOTE web servers being able to send requests to local ones. It seems far worse than a random cross-origin request to me and for the life of me I can't imagine uses cases.
That's not really how the internet works. What is a local webserver? Running on your machine? Running on your LAN? Running on your corporate intranet? How should a browser differentiate between these things? What qualifies as a remote server? Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)? Just because something…
It seems like an obvious measure would be for sites served outside the private-use or loopback ranges to be unable to request content from servers in private-use or loopback ranges.
> Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)?
Sucks to be them. If they've exhausted their private use IPv4 addresses, they can either rest comfortably knowing that NAT and IPv6 can solve their problem or they can ignore IETF recommendations and build a card house network that breaks if you give it a stern look.
Re: I can see your local web servers
#128Earlier quoted context omitted.
That's not really how the internet works. What is a local webserver? Running on your machine? Running on your LAN? Running on your corporate intranet? How should a browser differentiate between these things? What qualifies as a remote server? Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)? Just because something…
It seems like an obvious measure would be for sites served outside the private-use or loopback ranges to be unable to request content from servers in private-use or loopback ranges. > Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)? Sucks to be them. If they've exhausted their private use IPv4 addresses, they can…
My preferred solution would be to disable javascript altogether.
> Sucks to be them. If they've exhausted their private use IPv4 addresses, they can either rest comfortably knowing that NAT and IPv6 can solve their problem or they can ignore IETF recommendations and build a card house network that breaks if you give it a stern look.
This will only lead to organizations running IE7 (or whatever outdated IE version is most common now) forever.
Re: I can see your local web servers
#129This just reminds me why I use Vagrant and only run a local webserver while I'm actually doing development work on it.
Re: I can see your local web servers
#130I'm interested in this because I don't fully understand the consequences here. I'd like to gain a deeper understanding through some concrete examples. With the PHP CLI, I can run: php -S localhost:8000 With Python3, I can run: python -m http.server 8000 --bind localhost The demo fails for me in both cases, even though a request to localhost:8000 is sent. (EDIT: The server log in the terminal window does show that the…
Worst case they proxy all of the requests and can essentially access anything open on the port. For me it's all development stuff, so if they want access to a broken-half-the-time application with mock data then whatever.
However they'd have to know the routes to request to (or proxy all requests and do it in realtime) which isn't very likely if it's just some development application specific to you.
Basically there really isn't much risk if you aren't exposing anything interesting. Maybe if you're working on something proprietary it could be leaked?
Either way you may as well reconfigure your applications if the webpage can detect them, the risk is low but still existent.