search

puma / puma-dev

A tool to manage rack apps in development with puma
BSD 3-Clause "New" or "Revised" License
1.73k stars 106 forks source link

Feature Request: option to bind to 127.0.0.1 instead of 0.0.0.0 in launchd.plist for mac #306

Open e28eta opened 2 years ago

e28eta commented 2 years ago

I’m fine if you decide this is WONTFIX, but I think it’s worth the trouble. This is specific to the launchd.plist created on macOS.

I believe that, security-wise, it’s better to have fewer services on a development machine listening to public requests. puma-dev -install binds to 0.0.0.0, and that opens up all of the services to any machine that can reach it over the network. I think the /status api makes it easy to enumerate the dev services, and then a malicious actor (or the company’s red team) can explore at will (and iirc I’ve seen a vuln in Sketch get turned into arbitrary file access as an internal example for why this can be bad).

I won’t go so far to ask that 127.0.0.1 become the default (although secure by default is arguably better), but IMO it’d be a really great option to provide.

I realize the nip.io feature relies on 0.0.0.0, and some people will definitely want to keep 0.0.0.0. However, providing documentation & an easy way to make this safer & more secure seems like a net win to me. If you’re willing to make a “breaking” change, requiring explicit action before allowing external access does seem reasonable to me.

I certainly know enough to edit the plist and unload/load it, but I think it’s the kind of thing most people won’t consider unless it’s mentioned in the readme and/or offered as a programmatic option. Especially if they’re regenerating the plist occasionally (for example #112).

Thanks for your work on this tool!

cjlarose commented 2 years ago

I like the idea of adding this as an option. I understand a lot of people depend on the 0.0.0.0 for being to access puma from VMs or stuff like that, but I don't love that if I'm on a public Wi-Fi network, anyone can connect to my puma apps.

nonrational commented 2 years ago

Adding something like -install-bind-localhost or similar sounds like a fine idea.

Re: making this the default behavior (and making the flag -install-bind-public or something), there's a slowly growing list of default behavior that I'd like to be able to make non-default. Prob good to start tracking a wishlist for 1.0.

tcannonfodder commented 1 year ago

What if there was a -listen-hosts flag, similar to -d, that allowed the user to specify what the HTTP server should listen on? I wrote about this some here; the gist is that running puma-dev in the foreground only listens on 127.0.0.1, without the ability to change where the socket is listening. Being able to specify what addresses are acceptable would be a huge boon.