GoFuckYourself.com - Adult Webmaster Forum - View Single Post

goBigtime · 05-16-2003, 07:03 AM

1) Perl executes directly on the system --> any security hole in your script leads to direct command execution on the system with
the privileges of your web server.

You can use a CGIWrapper to prevent perl from doing system calls if that's something you need to worry about. Also keep in mind in most cases they would be ran as the apache user. And the same thing goes for system calls in PHP I believe.

Servers should be kept up to date security wise anyway.

2) PHP is a module, so it relies on apache (unless you are stupid enought to run it as CGI), then any security hole becomes harder to explot (still possible).

No, PHP can be compiled and installed as an apache module. So can perl.

3) You have not the security structure php has with it's config level (safe_mode, include_dir etc..). If you use perl you access to all the server directory unless you use several extra modules to protect the perl environment and pseudochroot it.

Heh or unless you write cleaner/safer code.

But I don't know enough about PHP's 'config levels' to argue about that one.

4) Perl uses to be slower when it comes to web database driven apps. The perl interpreter itself runs faster that PHP, but it takes some time to load it (more memory etc...). PHP is always loaded on your apache if you use it as module. If you have a 200 lines php app it will go faster that with perl, but if you have 20.000 lines application you should choose delphi or C instead of php (perl will do the work but will be still slow).

mod_perl used correctly will smoke PHP I believe.
But this isn't a Perl VS PHP _performance_ thread... it's based on you comments that perl is more of a security risk than perl.

And like I said, historically, over a much shorter period of time, PHP has claimed FAR MORE remote root compromises than Perl has.

05-16-2003, 07:03 AM
goBigtime Confirmed User Join Date: Nov 2002 Posts: 7,761	1) Perl executes directly on the system --> any security hole in your script leads to direct command execution on the system with the privileges of your web server. You can use a CGIWrapper to prevent perl from doing system calls if that's something you need to worry about. Also keep in mind in most cases they would be ran as the apache user. And the same thing goes for system calls in PHP I believe. Servers should be kept up to date security wise anyway. 2) PHP is a module, so it relies on apache (unless you are stupid enought to run it as CGI), then any security hole becomes harder to explot (still possible). No, PHP can be compiled and installed as an apache module. So can perl. 3) You have not the security structure php has with it's config level (safe_mode, include_dir etc..). If you use perl you access to all the server directory unless you use several extra modules to protect the perl environment and pseudochroot it. Heh or unless you write cleaner/safer code. But I don't know enough about PHP's 'config levels' to argue about that one. 4) Perl uses to be slower when it comes to web database driven apps. The perl interpreter itself runs faster that PHP, but it takes some time to load it (more memory etc...). PHP is always loaded on your apache if you use it as module. If you have a 200 lines php app it will go faster that with perl, but if you have 20.000 lines application you should choose delphi or C instead of php (perl will do the work but will be still slow). mod_perl used correctly will smoke PHP I believe. But this isn't a Perl VS PHP _performance_ thread... it's based on you comments that perl is more of a security risk than perl. And like I said, historically, over a much shorter period of time, PHP has claimed FAR MORE remote root compromises than Perl has. Last edited by goBigtime; 05-16-2003 at 07:06 AM..