Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Perl, CGI, and Security

by Ovid (Cardinal)
on Aug 13, 2000 at 09:37 UTC ( #27682=monkdiscuss: print w/replies, xml ) Need Help??

I'm a little concerned about this post as generally I would not trust anyone who would post what I am about to post.

As many of you know, I have been contemplating writing a free online "CGI with Perl" course. I anticipate that this will be an extremely long project and have been looking for fellow Perl freaks to assist, or at least to peer review my work. I intend for this to be a better resource than those currently available on the Web and my desire to use strict, -w, and are all part of this.

My biggest concern, however, is security. If everything else in someone's script falls to pieces, at least they can pick up those pieces if their script is secure. To this end, I would like to create "Security Checkpoints" throughout the course to alert students to potential pitfalls. A major problem with many online CGI courses and quite a few CGI books is that they warn about security pitfalls but do not bother to detail them. My concern: how can you know what a security hole is if you cannot exploit it?

That brings me to the heart of the problem. While I don't want to publish a hackers tutorials (and I'm not qualified to do so), I believe that those learning CGI need to see specific, concrete examples of security holes and how to exploit them. How can you protect against attacks you don't understand? What does it mean that some versions of Minivend allow a pipe character in certain text fields? What's the problem with printing a user's input directly back to a Web page? And here's a nasty one: did you know that some Unix-like operating systems use a caret '^' for redirection instead of a pipe? Do you always check for that when you untaint data?

I am not a security expert and I don't know the ins and outs of setuid or system calls. Therefore, while I understand the general concepts, I can't detail specifics terribly well. All of my CGI scripts involve very tight taint checking of variables that are used for database work. I don't do sysadmin work and my work CGI e-mails generally involves sending out canned e-mails that can be used as a resource to check out data. In short: I do nothing that is uncontrolled (that I'm aware of). What this means is that in many respects I am not the best person to be writing this course, but no one else is stepping up to the plate and there is a huge need for good information. Therefore, I need help.

I need monks who can provide me with specific, concrete examples of security issues and how they can be exploited. Either write them up and send them to me or send me links that may assist. I'll need OS specific information, problems with race conditions, server-side include vulnerabilities, etc. You can send them to I thought about simply having them posted to this site since I was planning on publishing them anyway, but I realize that many may be uncomfortable with that. If you would like credit for the vulnerability you send, please let me know.

It's difficult to trust anyone one the Web, so I understand that some may have concerns about this. If so, feel free to ignore this post. However, if you would like to support this endeavor, you may wish to read over some of my earlier posts to determine my "qualifications". Two particularly relevant ones are:

The first post explains my concept for the course and the second is a review I wrote concerning Elizabeth Castro's pitiful Perl/CGI book. Of course, read over my other posts and see how you feel about my writing style (which I will clean up for the course) and general attitude.

Thanks in advance!


Replies are listed 'Best First'.
RE: Perl, CGI, and Security
by merlyn (Sage) on Aug 13, 2000 at 11:58 UTC
    I'll be happy to perform a "security audit" on any code you post. Just drop me some email when you've got it done.

    As an example, you'd not be burned by the "caret in the shell" problem if you just avoid sending any user input anywhere near a shell! As soon as you are looking for specific "bad characters", you've already lost the game. The shell is just too durn flexible. {grin}

    -- Randal L. Schwartz, Perl hacker

      Thanks for the offer. I appreciate it.

      Yeah, my comment about checking for a caret was pretty stupid. One of the security points that I want to harp on is that it is much safer to specify what you will allow as opposed to what you won't allow. All it takes is for the programmer to miss one naughty character and the game could be up.


RE: Perl, CGI, and Security
by nardo (Friar) on Aug 14, 2000 at 02:39 UTC
RE: Perl, CGI, and Security
by Maclir (Curate) on Aug 14, 2000 at 05:36 UTC
    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, 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).


RE: Perl, CGI, and Security
by mischief (Hermit) on Aug 15, 2000 at 20:39 UTC
RE: Perl, CGI, and Security
by lindex (Friar) on Aug 15, 2000 at 16:47 UTC
    Iam up for auditing and thowing out good and bad code at any chance I can get.
    So if you have anything in mind just shoot me an email :)
    As for the ^ thing, I usally dont trust anything that isnt a-z as for as user input
    and randal put it well in saying user data shouldn't come anywhere near a shell :)

    /****************************/, /*****************************/
RE: Perl, CGI, and Security
by KM (Priest) on Aug 15, 2000 at 20:48 UTC
    I didn't see you mention -T in this post, I hope you will be covering it. I'd be interested in helping you at some point, as there is a decent chunk of security for CGI in the book I have been working on.
    As far as examples, well, you can surely find some (many of which would be fixed by using -T and out there, or use examples which have been known, and are now fixed (finger, wwwboard (ick), etc...).


      Oops. I realize that I should have been more clear on that. I alluded to it a couple of times, but did not explicity spell it out. Taint checking is of course one of the most important elements of CGI security and that's one of the one's that I intend to focus on quite heavily.

      My biggest concern now is that I just got a new job doing Perl and I am still finishing up another project for Special Olympics, so I am hoping to find the time to dedicate to this project so it doesn't drag out for two years. Aaargh!! Too much to do in my life. Cheers,

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://27682]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2023-12-04 03:18 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (20 votes). Check out past polls.