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

Did you at least contact Lincoln Stein (the author) about this?

  • Comment on Re: A serious security problem with CGI.pm 3.01?

Replies are listed 'Best First'.
Re: Re: A serious security problem with CGI.pm 3.01?
by tachyon (Chancellor) on Jul 11, 2001 at 20:07 UTC

    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();

    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

      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

        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

        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.