(Ovid) Re: Is this CGI search secure?

[Ovid]

I can't see anything in your script that is insecure. However, You don't provide us with the code for get_data() and you don't show us what you do with @lines.

The only user-supplied data appears to be $find and with your setting $CGI::POST_MAX to 1K, it looks perfectly safe. However, what do you do with @lines? Since they are going to match what you have in user-supplied data, there could potentially be issues there.

Is this just a test script? I noticed that $db_file appears to be a perl program and that doesn't seem to quite match the variable. Does &get_data do anything with $find?

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[tachyon]

Hi Ovid,

I just supplied the bit I am worried about to keep it as short as possible and was just grepping a convenient perl file on my system. Yes to proof of concept. The @ lines data just get munged and goes back to the browser with links to the found stuff so that is/should be fine.

The get_data() routine is just your usual bread and butter Perl. As the user does not interact directly with it I did not think it necessary to be inclued. Here it is anyway.

sub get_data {
    my $file = shift;
    open (FILE, "<$file") or die_nice("Oops can't read $file: $!\n");
    if ($flock) {
        my $count = 0;
        until (flock FILE, LOCK_SH) {
            sleep 1;
            die_nice("Can't lock file '$file': $!\n") if ++$count >= $
+timeout;
        }
    }
    my @file = <FILE>;
    close FILE;
  return \@file;
}

My main worry was null byte; "\n..."; "/@file; `rm rf`; #" type hacks. These won't work but are there others? Oh the die_nice() prints the usual "Sorry the system can not respond to your request due to routine maintenence, please try again later." back to the browser and sends the admin the real message ;-)

cheers

tachyon

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

[ichimunki]

Not that you are going to worry about this too much if the search input is only reused on a page returned to that very user, but you may want to do something to escape any HTML that is included in the user input before it gets sent back to the browser (in an HTML document). At best, it will goof up the display (i.e. the browser will interpret the tags as tags). At worst, if one user is allowed to enter input that will be output to another user there is significant potential for foul play (javascript, pictures of Barney... people do weird stuff if this hole is open).