Re: Re^3: browser not executing perl

Ooops, sorry, I'm going to swat you on that one. While you might be suprised at the number of HTTP::Daemons you can start before your system slows, there is no problem with open ports. Perl is incredibly secure, and fooling the perl interpreter remotely to do something bad is unheard of.

danielle would not be writing a daemon, because HTTP::Daemon is the daemon. And HTTP::Daemon is pretty good. The only way you can stuff it up is to send a huge POST request, and then the OS will just swat the daemon for taking up too much room.

I will totally agree with you that HTTP::Daemon is not the right tool for the job most of the time, though.

____________________
Jeremy
I didn't believe in evil until I dated it.

Comment on Re: Re^3: browser not executing perl

Replies are listed 'Best First'.
Re^5: browser not executing perl by Aristotle (Chancellor) on Jun 20, 2002 at 00:39 UTC
Fooling perl is hard, fooling a Perl script is not so. You do agree that CGI scripts can expose vulnerabilities to a cracker, right? Obviously it is so, otherwise we would not have a lot of tutorials, meditations, nodes, newsgroup posts and who knows what other form of posting in all the different media Perl is discussed via, dealing with how to secure one's CGI scripts. I also don't follow the reasoning that HTTP::Daemon is the daemon, but the script is not. Granted the specifics of the HTTP protocol are not handled in the script, but `use HTTP::Daemon;` loads the code inside the same interpreter and process the script runs in. The script does quite certainly provide daemon's actual, functional innards. Makeshifts last the longest.	[reply] [d/l]
Re^6: browser not executing perl by jepri (Parson) on Jun 20, 2002 at 00:52 UTC
Over here, we have 6 lovely fresh baked rolls, and on the other side, half a dozen lovely fresh baked rolls. CGI scripts expose vulnerabilities to a cracker. The innards of a daemon expose vulnerabilities to a cracker. No real difference there. My reasoning that HTTP::Daemon is the daemon is because it handles all the daemony kind of jobs, like dealing with connections, deciphering the HTTP protocol, building data structures... just like the Apache daemon does. No one would say that a CGI script is the same as the Apache daemon, even though a CGI script does certainly provide the apache daemon's actual, functional innards. The only thing the Apache daemon does that the HTTP::Daemon doesn't do is fork and drop privileges before execing the CGI script. And with my subclass of HTTP::Daemon your can avoid Apache's denial of service POST attack by deciding how much of the post stream to read. You can probably do this with Apache, but the thought of the C interface layer leaves me sweating. ____________________ Jeremy I didn't believe in evil until I dated it.	[reply]
Re: Re: Re^3: browser not executing perl by dsheroh (Monsignor) on Jun 20, 2002 at 18:20 UTC
there is no problem with open ports. Perl is incredibly secure (Donning sysadmin hat...) Regardless of whether that's true or not, it doesn't matter. If you set up your HTTP::Daemon on port 1433, it may not be vulnerable to the MS SQL Server worm that keeps banging on my door, but it'll be more of a drain on the server's resources for the HTTP::Daemon to wake up, determine that the incoming request is gibberish, and reject it than it would for the kernel to just ignore it because there isn't anything listening. Not to mention that simply having the port open might be enough to draw additional attention from people interested in whatever normally runs there. (Same argument applies to any other port, of course, I just picked 1433 because that's where most probes have been directed lately.)	[reply]