in reply to Re: Re^3: browser not executing perl
in thread browser not executing perl

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.

Replies are listed 'Best First'.
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.