Public web server by default is insecure
When we launch a newly created Dancer2 application it will listen on every interface of the computer. So anyone on the network will be able to access it. This can be good for a production server, but it is quite insecure as a development practice. Wouldn't it be more secure to allow only 127.0.0.1 by default and make it easy to allow other interfaces as well? What do you think? Gabor
On Sun, 2015-03-15 at 07:10 +0200, Gabor Szabo wrote:
When we launch a newly created Dancer2 application it will listen on every interface of the computer. So anyone on the network will be able to access it.
Personally I like this behaviour, as I normally develop on a remote server. Whatever I'm developing is not normally something that I'm bothered other people having access to. If there are general concerns about other people getting access, then surely it is better to run a local firewall anyway? Andy
On Mar 14, 2015, at 11:10 PM, Gabor Szabo <gabor@szabgab.com> wrote:
This can be good for a production server
I don’t think so. In production, Dancer should be behind some more performant server than HTTP::Server::Simple::PSGI. Starman, nginx, Apache, etc… In the PSGI case (e.g. Starman) Dancer won’t be listening at all, as I understand it. In the reverse proxy case (e.g. nginx, Apache) Dancer should be listening only on localhost in production, on some nonstandard port.
it is quite insecure as a development practice.
The default is good. It means you can run a Dancer app straight out of the box and access it remotely, without going through the Deployment guide to select something better first. If you care about security, you should be developing on a private LAN, not out on a public web host.
What do you think?
I wouldn’t mind if the default environments/production.yml file had server: "127.0.0.1" in it, if only to force people to think about such issues. That’s as far as I’d go. We shouldn’t be throwing up roadblocks in the development path. One of the reasons I stuck with Dancer through the early days when I was still uncertain about it was that it didn’t make anything harder than it had to be. Development should be easy. Production can be hard, because that’s DevOps’ problem. :)
On 2015-03-16 07:07 PM, Warren Young wrote:
it is quite insecure as a development practice. The default is good. It means you can run a Dancer app straight out of the box and access it remotely, without going through the Deployment guide to select something better first.
++ on that. Getting started on dev should be as easy as possible, and there is not really a case to go paranoid on security. If the dev cares about security, either they are already being a firewall, or they have much bigger issues on their hands than the brand-new Dancer "hello world" they have now running on their machine. :-) My 2 cents, `/anick
Interesting responses. I'll tell you the two issues that brought me to writing this e-mail. 1) A long time ago when I was teaching at a company and told people to install some CPAN module, during installation it wanted to open a port on their computer to run the test. Some of the students were were surprised / shocked on the security implications. As I understand they had their firewall on their computer and the module would not test itself without this. We used the LAN in their lab which is considered less secure than their internal LAN. Besides this could happen while I am on the road on a public network. I am not sure what module was that, or if Dancer2 shows this behavior during installation but this issue stuck in my head. 2) I was looking at Flask and it by default it listens to localhost only but right in the quickstart guide they show how to open it to listen to every interface http://flask.pocoo.org/docs/0.10/quickstart/ Now that I read the response of Warren, I was reminded that actually the fact that Dancer was listening to the outside world on my production server bothered me, but then again, when I try to set it up on a remote server first I always want to make sure that the Dancer application (maybe with Starman) answers me and it is much more convenient if it listens to the outside world. So I am not sure which one would I prefer. Actually I think I know what I'd like, regardless the defaults: I'd like the default configuration files to contain commented out entries for every (or every important) parameter with short explanation and/or with link to the longer explanation. Gabor
On Mar 16, 2015, at 11:58 PM, Gabor Szabo <gabor@szabgab.com> wrote:
1) A long time ago when I was teaching at a company and told people to install some CPAN module, during installation it wanted to open a port on their computer to run the test. Some of the students were were surprised / shocked on the security implications.
Network I/O in a CPAN test is indeed a bit questionable. I don’t really see how that has anything to do with Dancer, though. If you go and install a web app server framework, generate a web app with the dancer/dancer2 tool, and then *run it by hand*, you are somehow surprised to find that it is serving a web app?! It’s called the “Web” because it connects all computers running web servers; you can’t do that by listening for connections only on localhost. I suspect if you did a survey of all the vast number of web app frameworks, that most of them listen on 0.0.0.0. All of those that run under Apache and IIS do, for a start. What threat model are you actually working with here? Is it something deeper than just a knee-jerk reaction to an open TCP listener? I mean, what can a default dancer app actually *do* that worries you? Even if you go and run it at the root of your filesystem *as root*, it can’t do anything dangerous like serve up etc/shadow, because it only serves files from its views and public subdirs.
Actually I think I know what I'd like, regardless the defaults: I'd like the default configuration files to contain commented out entries for every (or every important) parameter with short explanation and/or with link to the longer explanation.
So you want roadblocks. You want the dancer helper app to generate an app that won’t run at all until you go in and hack on some configuration files. Do I have that right?
In short: Maybe just adding options to *"dancer2 gen*" is the way. When creating an app, then have the possibility to define these type of parameters. Peco 2015-03-18 15:55 GMT+01:00 Warren Young <wyml@etr-usa.com>:
On Mar 16, 2015, at 11:58 PM, Gabor Szabo <gabor@szabgab.com> wrote:
1) A long time ago when I was teaching at a company and told people to
install some CPAN module, during installation it wanted to open a port on their computer to run the test. Some of the students were were surprised / shocked on the security implications.
Network I/O in a CPAN test is indeed a bit questionable.
I don’t really see how that has anything to do with Dancer, though. If you go and install a web app server framework, generate a web app with the dancer/dancer2 tool, and then *run it by hand*, you are somehow surprised to find that it is serving a web app?! It’s called the “Web” because it connects all computers running web servers; you can’t do that by listening for connections only on localhost.
I suspect if you did a survey of all the vast number of web app frameworks, that most of them listen on 0.0.0.0. All of those that run under Apache and IIS do, for a start.
What threat model are you actually working with here? Is it something deeper than just a knee-jerk reaction to an open TCP listener? I mean, what can a default dancer app actually *do* that worries you? Even if you go and run it at the root of your filesystem *as root*, it can’t do anything dangerous like serve up etc/shadow, because it only serves files from its views and public subdirs.
Actually I think I know what I'd like, regardless the defaults: I'd like the default configuration files to contain commented out entries for every (or every important) parameter with short explanation and/or with link to the longer explanation.
So you want roadblocks. You want the dancer helper app to generate an app that won’t run at all until you go in and hack on some configuration files. Do I have that right? _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Wed, Mar 18, 2015 at 7:55 AM, Warren Young <wyml@etr-usa.com> wrote:
On Mar 16, 2015, at 11:58 PM, Gabor Szabo <gabor@szabgab.com> wrote:
Actually I think I know what I'd like, regardless the defaults: I'd like the default configuration files to contain commented out entries for every (or every important) parameter with short explanation and/or with link to the longer explanation.
So you want roadblocks. You want the dancer helper app to generate an app that won’t run at all until you go in and hack on some configuration files. Do I have that right?
No, you don't. Read it again?
On Mar 18, 2015, at 9:07 AM, Yitzchak Scott-Thoennes <sthoenna@gmail.com> wrote:
On Wed, Mar 18, 2015 at 7:55 AM, Warren Young <wyml@etr-usa.com> wrote:
On Mar 16, 2015, at 11:58 PM, Gabor Szabo <gabor@szabgab.com> wrote:
Actually I think I know what I'd like, regardless the defaults: I'd like the default configuration files to contain commented out entries for every (or every important) parameter with short explanation and/or with link to the longer explanation.
So you want roadblocks. You want the dancer helper app to generate an app that won’t run at all until you go in and hack on some configuration files. Do I have that right?
No, you don't. Read it again?
Yes, I know what it says. I also know what he asked for originally, and what the title of this thread is. I don’t see how it makes Dancer more secure to point users to the docs from a configuration file when those docs are already present. The only way a configuration file change can make Dancer more secure is to either bind to localhost, or turn off the listener entirely, in order to force users to RTFM before they can get a new Dancer app to do what they almost certainly actually want. Regardless, the claim that Dancer is “insecure” by default has yet to be demonstrated. Show me an attack on a default Dancer app, and we can talk about it. Simply pointing out that it listens on a public IP is not a demonstration of insecurity.
On Wed, Mar 18, 2015 at 7:40 PM, Warren Young <wyml@etr-usa.com> wrote:
On Mar 18, 2015, at 9:07 AM, Yitzchak Scott-Thoennes <sthoenna@gmail.com> wrote:
On Wed, Mar 18, 2015 at 7:55 AM, Warren Young <wyml@etr-usa.com> wrote:
On Mar 16, 2015, at 11:58 PM, Gabor Szabo <gabor@szabgab.com> wrote:
Actually I think I know what I'd like, regardless the defaults: I'd
like the default configuration files to contain commented out entries for every (or every important) parameter with short explanation and/or with link to the longer explanation.
So you want roadblocks. You want the dancer helper app to generate an
app that won’t run at all until you go in and hack on some configuration files. Do I have that right?
No, you don't. Read it again?
Yes, I know what it says. I also know what he asked for originally, and what the title of this thread is.
I don’t see how it makes Dancer more secure to point users to the docs from a configuration file when those docs are already present. The only way a configuration file change can make Dancer more secure is to either bind to localhost, or turn off the listener entirely, in order to force users to RTFM before they can get a new Dancer app to do what they almost certainly actually want.
Regardless, the claim that Dancer is “insecure” by default has yet to be demonstrated. Show me an attack on a default Dancer app, and we can talk about it. Simply pointing out that it listens on a public IP is not a demonstration of insecurity.
The title of this message probably should have been a question or phrased in some other way, but the suggestion to have commented out configuration options? How would these entries in the configuration file constitute a roadblock? # Enable the following line to limit the server to only listen to localhost: # server: "127.0.0.1" # Enable the following line to turn on file-based session management: # session: "YAML" Gabor
I agree the title should be different, for more than one reason: * It is not "insecure" to run an application on an interface unless the application mandates it shouldn't. It depends on the situation and there is no definite "should-be" situation anyone can claim here. * It is not "Dancer" the picks the port. The development server start-up is sent to Plack's development server (at least in more recent Dancer2 versions), and *that* is what decides those defaults. * The development server is not supposed to be your full production server and you shouldn't be expecting it to have the behavior of a full on secure production application. It's meant to run something so you could play with it. If the idea is "any development server should automatically always bind to my localhost" - whether I agree with it or not - should be directed to the authors of the development server - Plack. If the idea is "I wish Dancer's defaults when running the development server would including binding to localhost", we can definitely discuss it. (I don't feel strongly about this, so I would enjoy hearing what other people think.) Perhaps such a discussion would lead to scaffolding profiles and having a more secure one instead of changing the default. Still, my fear would be that people would assume the development server does the right thing for a production server and use it as such. I've seen it happen before in other languages and other frameworks, even in Perl (and unfortunately with Dancer as well). An interesting example is Python's SimpleHTTPServer, which, by default, even though it comes with *core* Python, still listens to 0.0.0.0. (I assume it might also work for IPv6, but haven't tried.) They literally allow running "python -m SimpleHTTPServer" to open a public web server on the spot. Different users want different things. Should a development server need a deployment document? I don't know. I would guess it's meant to make development as easy as possible. Then, when you want to really deploy it, you use the Deployment guide, which suggests a proper set up with a proper server. But that's just my $0.02. On Wed, Mar 18, 2015 at 9:57 PM, Warren Young <wyml@etr-usa.com> wrote:
On Mar 18, 2015, at 12:11 PM, Gabor Szabo <gabor@szabgab.com> wrote:
# Enable the following line to limit the server to only listen to
localhost:
# server: “127.0.0.1"
That would be perfectly fine with me.
It’s very different from what you originally asked for. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (7)
-
Andrew Beverley -
Gabor Szabo -
Juan José 'Peco' San Martín -
Sawyer X -
Warren Young -
Yanick Champoux -
Yitzchak Scott-Thoennes