I agree 100% with you, Ovid, on the need for this type of tutorial / book. Security must be built in from the beginning. The problem is (or the decision), how wide do you make the problem space? For example, it is all well and good for our perl code to "do the right thing", but if the web server is wide open to attack, because access controls within the apache configuration is missing, or because of inadequate firewall settings, someone can access the physical machine, we are still in a bad way.

The argument that "we should not tell potiential script kiddies how to crack systems" is spurious. The crackers will know (or already know) the holes and exploits. I cannot see what additional damage pointing out these holes in a "Perl, CGI and Security" book would be. Sure, some other people may learn and try to use the expolits. But sites that are affected would probably be hit anyway. What it would result is is web administrators tightening up and removing any holes.

Security by Obscurity is no security - someone will find out, and the crackers have a pretty good method for informing each other of these holes.

I agree on the emphasis on CGI.pm, as well. The trouble with many of the "How to be a cool web developer in Perl / CGI in 7 days" type of books is they do not explain the underlying operations in CGI programming, and how HTTP actually works. Just as the rise in wysiwyg HTML "editors" has allowed anyone to have their own web site, without understanding what the processes are in delivering and rendering the resulting page, so many developers do not understand the environment.

A question - are you wanting to make your book (tutorials) server independant, or will you assume an Apache environment? If so, you may want to consider the impact of mod_perl, and the changes to programs that are required to ensure persistance does not cause strange problems (I still get caught occasionally).

Ken