How can I securely develop a local webapp at a coffee shop?

Question

When I'm developing a webapp, let's say a Django site, I run it locally and typically access it at http://localhost.

I thought this was inherently secure because I assumed that localhost can only be accessed locally. However, I discovered that even running a local web server (Apache, Nginx...) with a self-signed HTTPS certificate won't help because localhost is not really required to be local:

In empirical testing, we've seen multiple resolvers... send localhost queries to the network... As a result accessing "https://localhost", say, on a hostile WiFi access point (such as your coffee shops) can be intercepted by a network attacker and redirected to a site (or a certificate) of their choosing. (In email chain "Exception to Baseline Requirements, section 7.1.4.2.1".)

If I'm developing a webapp, I need to run it locally and access it through a browser. Sometimes I need to do this at a coffee shop with an internet connection. What access point should I use, if not localhost?

Note

Some of my desktop applications also expose themselves via HTTP at other ports, for example http://localhost:9000. Presumably I shouldn't access those at a coffee shop either?

Answer 1

Safely developing against localhost can be done provided:

• your machine is configured to resolve localhost to a loopback address (note, it's possible to change your hosts file to resolve localhost to a different address)
• your machine is configured to route the loopback address via the loopback interface (it's possible to route loopback addresses to non loopback interface)
• you configure your application to listen on the loopback address, not 0.0.0.0 (many web frameworks listens on 0.0.0.0 by default, this is probably the most common reason for unexpectedly exposing services to untrusted network during development)
• if you use a proxy, your browser is configured not to route localhost/loopback through the proxy

In other words, a fairly typical networking configuration.

Also, take care that your database server aren't binding to 0.0.0.0, as that'll allow anyone on the network to connect directly to the database server. It's probably best to set a firewall configuration so you know exactly what ports and addresses that local services are listening on.

The link you pointed is under the context of a publicly trusted CA issuing certificates with "localhost" name. This is unsafe under that context because the recipient of such certificate may use the certificate to intercept the communication of someone with some unusual networking configurations. When you have full control over your own machine's configuration and you know that you don't have some weird configurations on your machines, the loopback interface is safe.

Answer 2

First, you could use http://127.0.0.1 to bypass the DNS lookup.

Secondly, you can create your own self-signed CA certificate, create a certificate for localhost and connect to https://localhost securely. There is no way an attacker can intercept that connection.

As a result, accessing "https://localhost", say, on a hostile WiFi access point (such as your coffee shops) can be intercepted by a network attacker and redirected to a site (or a certificate) of their choosing.

This is true in the context of the email thread. The email thread is about whether someone could obtain a valid certificate for localhost from a trusted CA. If this were possible, then yes, someone else could impersonate https://localhost. But a public CA is not permitted to issue certificates for localhost (Baseline Requirements, section 7.1.4.2.1; see also this discussion on the Let's Encrypt tracker).

Because this is not possible, your own private CA is the only one that you trust that issued a localhost certificate.

Answer 3

If you're doing this type of stuff often, why not just get a travel router?

With a small travel router, you can set up your own internal network with its own SSID, add encryption, and set up a customized whitelist so only your MAC addresses are allowed on it.

Answer 4

If you develop in Docker, then when you start your web app (in a Docker container), the container will have its own IP address that may not be accessible from the outside. You would access it with a special IP, that only you can see, as assigned by Docker - e.g. http://172.17.0.2:9000.

Whether your web app is also accessible on your host's physical network interface depends on how you start the container. For example, the docker run command won't bind to the host interface unless you use the -p, -P, or --expose options.

Other benefits:

• The app is otherwise isolated from your host system.
• Deployment to other systems is more reproducible.

Answer 5

There probably isn't a viable MITM attack here. Assuming Ubuntu and Django, there are two big factors that conspire against an attacker:

• Ubuntu's default hosts and dns configuration will resolve localhost using a hardcoded setting. It won't even perform a DNS query. You can change this... But don't instead :)

• Django binds to 127.0.0.1:8000 by default. To fully MitM you, the attacker would need to intercept the traffic being served by Django but they don't have access.

That said, web security is complicated. There might be things you're doing that an attacker could exploit to have some sort of an effect on you.

External resources have to be secure

Many of us embed third-party, CDN-hosted files. Jquery, Bootstrap, etc. If these are http:// or // (remember the dev server doesn't use TLS), that could give an attacker an opportunity to MITM those files and inject live script into your pages.

For the sake of local development away from an internet connection, it may be best on all counts to just host all the stuff yourself.

Click-jacking and iframe techniques

Just because they can't access your local-running server, doesn't mean they couldn't tell your browser to access it. Cross origin security will (probably) stop them doing things with it directly but they could stick it in an iframe. This is sort of a reverse-clickjack.

To the user this would just look like your website. They could even capture all URLs at their end and feed them through to the frame. If it were a public website they could also work out what you were clicking.

But of course you're already using django-secure, aren't you? I'd recommend it. One setting and you'll start sending out X-Frame-Options: DENY headers with every Django request. Alternatively there is a Django-builtin option that does the same. I recommend django-secure because it does a lot more.

Your security on a hostile network is more than a web server

You probably have other daemons running, well beside things like PostgreSQL that you're using for development. You might be running SSH servers, filesharing servers, etc and if you're used to a home environment, you may have skipped leg day gone with weaker security for convenience.

The easiest single thing to do is block all incoming traffic. Assuming you have no existing UFW configuration, that's as simple as:

sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing

That will persist reboots. If you get home and want to access something, you can either turn it off with sudo ufw disable or change the default and open certain ports explicitly.

If you are going to leave a SSH port exposed, I have written an article on hardening SSH configurations. Unless you're in the NSA canteen, that should keep most people out of your system.

Answer 6

The problem that forum is describing is actually the opposite one from what you are worried about. You are worried someone else on the network will be able to see what is being served on localhost. That problem is you trying to see what's being served on localhost and instead being served a malicious web page by someone else on the network.

That problem is actually not that hard to set up. I've had it happen by accident here at work. We make network equipment and software, so there are a lot of people with various levels of experience putting machines in various states of experimentation on the network. Someone accidentally set 'localhost' as their hostname, it got registered in Active Directory, and served up to everyone in DNS.

At a coffee shop, that wouldn't be that difficult to notice, because your webapp would suddenly be some other page instead. If you're using a TLS certificate, it wouldn't have a valid certificate.

If you're worried about your webapp details leaking, just block the relevant incoming ports on your external firewall. On linux, you would do something like this:

/sbin/iptables -A INPUT -o eth0 -p tcp --dport 80 -j DROP

Answer 7

Access your site with http(s)://127.0.0.1/, configure your app to listen to 127.0.0.1 only and you are safe. Encryption is not necessary as there is no possibility for someone outside to listen: nothing goes outside of your computer, your app on your computer "talk" with your browser on your computer via an address witch cannot be used outside of your computer.

Answer 8

You could code, host and run in your browser in the cloud over https using Cloud9 ide, a GitHub repo and Heroku. Unless a keylogger is installed or somebody is looking at your screen, nobody in that room can detect what you are doing.