in reply to Re: A serious security problem with CGI.pm 3.01?
in thread A serious security problem with CGI.pm 3.01?

No, I have not emailed Lincoln rrwo. Unfortunately I have internet connectivity at work but no outgoing email :-( I presumed that there was no way an oversight this big could have occurred so put it up for discussion. It got moved here by one of the editors. It seems the problem is a bad (hand) install as noted above. Still cause for concern as the hand install seems to run (kinda)!

I am a convert of CGI.pm, although as I don't use the HTML display part feel (like others) that it might be better split into two modules - a CGI data parsing part and an HTML generating part. Yes, I know there are alternatives but this module is the *gold standard* that comes with Perl so it is concerning than someone seems to have devised a way to silently break it through a bad install. Some code at the begining of the module like: 

die "Bad install detected" unless module_checks_out();

[download]

might be nice if this is indeed the case. It would be trivial to include some code that adds a __DATA__ element that CGI.pm could have added to it during a proper install and read before running via the module_checks_out() sub postulated above. The speed penalty would be negligible as no system call would be required, just a read off the <DATA> filehandle.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Replies are listed 'Best First'.
Re: Re: Re: A serious security problem with CGI.pm 3.01?
by Thathom (Acolyte) on Jul 11, 2001 at 22:08 UTC
    Im sorry for starting a big problem with the cgi thing :)
    So it wasnt me being thick after all?
    I thought maybe you had to create the cgi.pm yourself by using the makefile.pl.

    Anyway, I've decided to just use a CGI.pm that arturo advised. (tan-ku)
    Seems to be working ok now.
    Why do things have to be so complex?, to be honest I don't like using the CGI.pm as I like making code myself and planning where it goes, how i get it etc. Im one of these people who likes to know i did it all, typed every character of it.
    Its as though the CGI.pm interupts the way i should think. (even though im sure it does everything perfectly well). I know I'll never use the HTML part of it either. Mind you, the things I'm creating arent massive as Im a learner. Im sure its more useful for programmers designing MASSIVE systems... saves typing as much. (or maybe its just for lazy people.. or even people who don't know html).

    Im talking arse aren't I?,
    I'll stop now :))

    ThAtH0M

[reply]

      Inumerable hours have gone into devising CGI.pm It is not perfect but it is well tested and reliable. For some scary info on the problem invoked via bad CGI parsing see:

      Use CGI or die;

      No excuses about not using CGI.pm

      and Ovid's CGI tutorial.

      You had me worried for a minute there!

      cheers

      tachyon

      s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[reply]
      I like CGI.pm, but my very successful six-figure per annum website brother refuses to use it. He says that CGI.pm hides from the programmer what is going on and gives the impression that running CGI is some arcane and mysterious art.

      I asked my brother what about using param() to handle non-standard characters in HTML form input. He said he has a few regexes that do it and he doesn't need Lincoln Stein's code to check input for him.

[reply]
        Way, way back in like 1998 or something in TPJ (bless its little cotton socks) there was an article called something like "Perl Heresies". One of the heresies in this article was that you should <STONG>always use modules.

        Before I get jumped on I'll explain the rest of its gist.

        The argument went something along the lines that, if it's work related then you have a responsibility to your client/employer/whatever to write good code efficiently and quickly, so, in this situation, modules - particularly ones such as CGI.pm - are a good thing, but that, in certain circumstances it can be much more efficient to write a quick line or two to handle a small portion covered by a module rather than go to the trouble of loading a whopping great module in (I think the example was Date::Manip and figuring out what day it was yesterday or something)
        However, when it comes to "messing around", re-inventing the wheel can be really good for you. It will give you a much better understanding of what goes on behind the scenes when you are using other peoples modules and if you ever have to invent the wheel for some reason then you're not going to be totally clueless and starting from scratch.

        My apologies to the author of the article if I've totally mis-represented it :)

[reply]

In Section Seekers of Perl Wisdom