
I renewed the domain local.computer and set it and all subdomains to 127.0.0.1 - skwashd
https://twitter.com/jonpugh/status/759733817531858944
======
greenyoda
Every computer already defines the domain "localhost" for this purpose, which
never expires and can't be hijacked. Why would someone want to use this risky
alternative?

Also, localhost will work if your machine is disconnected from the internet,
while local.computer, which relies on a remote DNS server, will not.

~~~
jonpugh
It's really just for convenience. I build a lot of drupal sites and often need
to run a lot of them at once locally.

Instead of putting each one on it's own port (hard to remember) or starting
and stopping VMs or containers (tedious), I just use a subdomain like
[http://projectname.local.computer](http://projectname.local.computer)).

I'm a contributor to Aegir, and created the aegir docker containers, which
default to aegir.local.computer for easy testing. When I create sites in
aegir, I don't have to set any DNS if I use a subdomain of
aegir.local.computer, I can just visit node/add/site and fill in the form and
get a site. Great for Aegir development. See
[https://hub.docker.com/r/aegir/hostmaster/](https://hub.docker.com/r/aegir/hostmaster/)

I'm also creator of devshop, a more "cloud-y" version of aegir which gives
each site a domain automatically, so local.computer is really great for
developing devshop as well.
[http://ENVIRONMENT.PROJECT.devshop.local.computer](http://ENVIRONMENT.PROJECT.devshop.local.computer)

I've also got a CLI tool for launching drupal sites locally in docker
containers called Terra. It uses jwilder/nginx-proxy to route requests for
domains to the right container, and makes dynamic domains like devshop. So
*.local.computer is useful there too.

[https://github.com/terra-ops/terra-cli](https://github.com/terra-ops/terra-
cli)
[https://github.com/opendevshop/devshop](https://github.com/opendevshop/devshop)

~~~
smt88
This is still a pointless security risk. Just use projectname.whatever
(something that isn't on a public TLD).

~~~
jonpugh
I still can't quite put my finger on the security risk for others, can you
help explain what makes it one?

Here's the only scenario I can think of:

Say you are a web developer and you use mybusiness.local.computer for
developing your client's website. You use it every day, you are used to
loading up the URL and seeing your website.

One day I, owner of local.computer turn the dark side. I decide that I want to
attack you, this one person who I know uses mybusiness.local.computer, and
change mybusiness.local.computer to redirect to my nefarious server.

When I do that, when you come to work, you load up mybusiness.local.computer
and expect to see the site you've been working on.

Because I know my victim, I know exactly what website to spoof, so I have my
spoof up and running on my nefarious server.

Then, when the victim goes to visit mybusiness.local.computer, thinking they
are visiting a copy of their website, it's actually being served from my
server.

Hopefully, you then input some information, like their username and password,
which I then capture in my spoof website.

This is the only way I can imagine using this domain against someone.

It involves quite a few assumptions:

\- The one in control of DNS is the attacker. \- The attacker has one specific
victim in mind, because they can only spoof one website. \- The attacker
already knows what site the victim is expecting to load at a _.local.computer
domain. This requires personal knowledge of the victim 's site because the DNS
for _.local.computer goes straight to 127.0.0.1. Requests are not proxied or
logged. (Ok, after writing this, I realize I could change the local.computer
to go through my servers then redirect the user to 127.0.0.1 enabling me to at
least learn what subdomains are being requested. Still, I have no idea what
that site is supposed to be.) \- The attacker is able to spoof that website
well enough that the victim (a developer of the website) is able to be fooled
into giving up information.

Is there another way this could be abused? I seriously would like to know.

Thanks!

~~~
smt88
As the owner of local.computer, you are in a position to intercept anything a
developer is sending to her server via HTTP request. This could be
username/password, yes.

You also then know the public IP address and public domain of a development
server, which may allow you to access the server and learn secrets, steal
stack traces, etc.

It's a small security risk, but it's a non-zero risk with zero benefit. Just
use fake, never-to-be-public domains. There's no downside. If you need to
interact with something like Twilio (which you _never_ need to do while
developing), you can wait until you're ready to push to staging.

~~~
jonpugh
The benefit is not zero, it is having unlimited domains pointed to local
without having to ever mess with DNS or /etc/hosts.

~~~
smt88
You can do this using dnsmasq[1] on Linux or OS X and Acrylic DNS on
Windows[2]. I guess if someone wanted to do more work, they could also just
register their own random domain and point it to 127.0.0.1.

We're also talking about maybe 30 seconds of work per project to edit a hosts
file. Someone who knows their command line will be able to do it in 5 seconds.
Multiplied by 20 projects, that's still only 2 to 10 minutes of work every
year.

I personally use localhost for everything and just work on one thing at a
time. I never mess with hosts.

1\. [https://davejamesmiller.com/blog/installing-dnsmasq-
wildcard...](https://davejamesmiller.com/blog/installing-dnsmasq-wildcard-
local-domains-debian)

2\.
[http://mayakron.altervista.org/wikibase/show.php?id=AcrylicH...](http://mayakron.altervista.org/wikibase/show.php?id=AcrylicHome)

~~~
jonpugh
I build systems (devshop/aegir) that create and destroy websites on the fly.

If I'm working on a feature related to that process I could create and delete
a dozen or more arbitrary domains in a day.

I also know plenty of web development teams that are less technical and could
deal without manual hosts file tweaking on a daily basis.

I also use multiple computers. With this domain, I never have setup Dnsmasq,
never have to edit a hosts file, never have to edit DNS.

Being obsessed with automation and efficiency, anywhere I can save a few
seconds, I will.

~~~
MaulingMonkey
> Being obsessed with automation and efficiency, anywhere I can save a few
> seconds, I will.

I just make my CLI tools update my hosts file.

*.local.computer all points to 127.0.0.1 - when I want localhost subdomains, I want unique IPs too (so e.g. I could bind different httpds to 127.0.0.1:80 and 127.0.0.2:80, or other evil thing I've thought up)

