in reply to Errors in my (simple?) CGI Script!

Just some thoughts:
  1. $progid == "bush" should be $progid eq "bush"
  2. You need to untaint your variable $progid, follow the link to Ovids tutorial below for more info on CGI security.
  3. When you open the '$random_file' file you do not test whether it suceeded (see example)
  4. You have no else clause in your conditional block
  5. Try using use CGI::Carp qw(fatalsToBrowser); for debugging. See the CGI::Carp manpage for details.
  6. Use CGI to print your header. Don't do it manually.
  7. You redifine $/ but don't do it locally. Yes I know you are doing this to slurp files but you might find you aren't opening your other files properly (not knowing their content I couldn't say either way).
Your file opening code uses a variable to open the file 'random_file' but you declare it inside the open routine and never give it a value. Assuming its value is in 'bush.conf' then you need to remove the 'my'. An untested snippet would something like 
# Assuming is set in bush.conf
unless(open(FILE,"<$random_file"))
{
 # Handle it gracefully
}
my @lines = <FILE>;
close(FILE);

[download]
Or you could use $!: 
open(FILE,"<$random_file") || die "Could not open file",$!;

[download]
Note that I have added a < to implicitly imply that I am opening the file. You might also want to consider the three argument form of open(). See the manpage for details.

And finally: Ovids course

Replies are listed 'Best First'.
Re: Re: Errors in my (simple?) CGI Script!
by shotgunefx (Parson) on Mar 09, 2002 at 21:46 UTC
    I agree with most of your points but why would he untaint progid? It's not passed to any system calls and doesn't appear to be used anywhere but the if statements which is harmless.

    -Lee

    "To be civilized is to deny one's nature."
[reply]
      Well for a start its coming from the outside world. In my opinion all CGI programs should be able to run under taint mode before they get put onto a live server. All incoming data must be taint checked before being used. In this case we expect a string so we can strip everything that isn't and so remove all the nasty shell characters and \00.

      In the context of the program above it might appear overkill but arguably its better to get into good habits early.
[reply]

        I'm not sure why you are asserting that all parameters must specifically be untainted. I would tend to agree with Juerd that unless you're using it in a system call, it doesn't pose a security problem. (theguvnor would welcome any enlightenment to the contrary).

        On the other hand, I don't understand Juerd's assertion that Perl's tainting is such a problem.

        1. You don't have to run -T if you don't want.
        2. Even when you use it, you only have to untaint those variables that you want to use in system calls.

        So I don't know why Juerd is so down on Perl's tainting mechanism...

        ..Guv

[reply]
        A reply falls below the community's threshold of quality. You may see it by logging in.

        All incoming data must be taint checked before being used.

        I disagree.

        Only data that is used in external calls must be taint checked. For example, when a name is put in a cookie, just for fun, there's absolutely no reason to taint check it (you should think about encoding it, though).

        I dislike Perl's tainting, because it lets _all_ external input be tainted (and that decreases performance), while some things are never used in a dangerous environment. While it might be a good idea for beginners to always taint everything, I personally HATE -T, and would rather be able to have a lexical taint pragma, and taint and untaint functions for those moments where you want to have a check on some data, or when you know some data is completely safe. 

        44696420796F7520732F2F2F65206F
7220756E7061636B3F202F6D736720
6D6521203A29202D2D204A75657264

[reply]
        Personally I don't use taint. Whenever I do anything that could touch the outside I treat it like a bomb. (With great care.) But for someone less familiar with the dangers, It can't hurt. Though it might not help either unless they understand why they are doing and what is dangerous.

        -Lee

        "To be civilized is to deny one's nature."
[reply]
Re: Re: Errors in my (simple?) CGI Script!
by impossiblerobot (Deacon) on Mar 09, 2002 at 21:52 UTC
    What is the advantage of using CGI.pm to print the header?

    Impossible Robot
[reply]

      For one thing is less typing :) Also more recent versions of CGI.pm will print a header like : 

      Content-Type: text/html; charset=ISO-8859-1

      [download]
      which is recommended in a CERT Advisory ... this is one of the advantages of using a module, they often get quietly updated like this long before the information that gave rise to the update has been as widely propagated.

      /J\

[reply]
[d/l]
        Technically, CGI.pm also is cross-platform, that is, it uses the correct CRLF (newline) sequence that is needed for the browser to parse them, on all platforms. As many have pointed out, this is usually a non-issue, as most (modern) web servers correct such things on the fly, before sending the response, but it doesn't hurt in case someone, for some reason, would run your program under one that doesn't. :)
        You have moved into a dark place.
        It is pitch black. You are likely to be eaten by a grue.
[reply]
[d/l]

In Section Seekers of Perl Wisdom