Perl CGI.pm script executing differently on different systems

[Cyde Weys]

Well, I've finished the script I was working on that I needed help
doing dates for. It works correctly on one of my webservers, but it
doesn't seem to work on my other webserver (it never gets the
parameters). I'm at a loss as for why that would be. Also, I tried to
make it as secure as possible by only 'eval'ing inputs consisting solely
of digits and decimal points. Is it secure, or am I still vulnerable to
some sort of attack?

Here is the working script:
http://fyre.sytes.net:8007/mealplan.pl

Here is the non-working script (both are exactly the same, just on
different webservers):
http://terpy.sytes.net/mealplan.pl

And here is the source code. Thanks for the help.
http://terpy.student.umd.edu/mealplan.txt

 

[Beable van Polasm]

And here is the source code. Thanks for the help.
http://terpy.student.umd.edu/mealplan.txt

#!/usr/bin/perl

#use strict;
#use warnings;

Have you tried it without commenting these lines out?

 

[Cyde Weys]

#!/usr/bin/perl

#use strict;
#use warnings;

Have you tried it without commenting these lines out?

I commented those out and nothing changed.

 

[Beable van Polasm]

I commented those out and nothing changed.

You want them not commented out. Why would you comment these
very important lines? Also, have you looked in the webserver
error log file? Have you tried adding a line like this to the
start of your script?

use CGI::Carp qw(fatalsToBrowser);

 

[Cyde Weys]

You want them not commented out. Why would you comment these
very important lines? Also, have you looked in the webserver
error log file? Have you tried adding a line like this to the
start of your script?

use CGI::Carp qw(fatalsToBrowser);

I meant I uncommented them and nothing changed. Slip of the tongue.
There's nothing in the webserver error log file. Whatever is going
wrong, it's not throwing off errors. Even after I throw in the Carp
line you told me to use.

 

[Bill Smith]

Well, I've finished the script I was working on that I needed help
doing dates for. It works correctly on one of my webservers, but it
doesn't seem to work on my other webserver (it never gets the
parameters). I'm at a loss as for why that would be. Also, I tried to
make it as secure as possible by only 'eval'ing inputs consisting solely
of digits and decimal points. Is it secure, or am I still vulnerable to
some sort of attack?

Here is the working script:
http://fyre.sytes.net:8007/mealplan.pl

Here is the non-working script (both are exactly the same, just on
different webservers):
http://terpy.sytes.net/mealplan.pl

And here is the source code. Thanks for the help.
http://terpy.student.umd.edu/mealplan.txt

Can you run any other perl/CGI script on the offending server? If not,
do you know of anyone else who can? Can they run your script?

These are easy ways to verify your setup and file permissions before you
start to debug the perl code. The fact that your script works anywhere
suggests that your main problem is not a perl problem.

Good Luck
Bill

 

[Cyde Weys]

Can you run any other perl/CGI script on the offending server? If not,
do you know of anyone else who can? Can they run your script?

These are easy ways to verify your setup and file permissions before you
start to debug the perl code. The fact that your script works anywhere
suggests that your main problem is not a perl problem.

Yeah, I can run Perl scripts just fine on my Terpy server. The only
problem it seems to have is getting parameter values from textfields in
CGI. Everything else works fine (hell, I'm running a slashcode website,
which is all based on Perl).

 

[gnari]

... Also, I tried to
make it as secure as possible by only 'eval'ing inputs consisting solely
of digits and decimal points. Is it secure, or am I still vulnerable to
some sort of attack?

my question is, why eval at all ? the lines in question are:

if ($money =~ /^([0-9.]+)$/ ) {
$money = eval( $money );
my $spent = 966.5 - $money;

there is no real need to to eval the variable if you have
already validated it with a regexp. the substraction will
make sure it is a number.

why the captures in the regexp? you do not seem tu use $1

Re: the problems on one server:
did you try to make a minimal 'hello world' cgi script on that server?
are all modules available there, like Date::Calc ?

did you make sure the source on the bad server does not contain
carriage returns at the end of lines?

is perl located at /usr/bin/perl on it ?

what type of server is it?

gnari

 

[Cyde Weys]

my question is, why eval at all ? the lines in question are:

If I don't eval() it, it doesn't work. I'm getting my input from a CGI
text field and it doesn't treat that like a number unless I evaluate it.

if ($money =~ /^([0-9.]+)$/ ) {
$money = eval( $money );
my $spent = 966.5 - $money;

there is no real need to to eval the variable if you have
already validated it with a regexp. the substraction will
make sure it is a number.

why the captures in the regexp? you do not seem tu use $1

Well, I'm kinda newbie at Perl, so I can take the dollar sign out
because it's unnecessary?

Re: the problems on one server:
did you try to make a minimal 'hello world' cgi script on that server?
are all modules available there, like Date::Calc ?

Yes all modules are there, and it runs "Hello world" CGI scripts quite
well. It just doesn't work at all when I try to use it with a slightly
more advanced CGI script that is dependent on inputting values from any
sort of text fields. I've put up another example and you can see that
it doesn't work:
http://terpy.student.umd.edu/test.pl
http://terpy.student.umd.edu/test.txt

did you make sure the source on the bad server does not contain
carriage returns at the end of lines?

Huh? Not sure what you mean, but I don't think that's the problem.

is perl located at /usr/bin/perl on it ?

Yes it is.

what type of server is it?

Redhat 9 barebones (customized installed packages, no windows managers)

 

[Gunnar Hjalmarsson]

It just doesn't work at all when I try to use it with a slightly
more advanced CGI script that is dependent on inputting values from
any sort of text fields.

What about if you try this test script:

#!/usr/bin/perl
use strict;
use warnings;
use CGI::Carp 'fatalsToBrowser';

print <<START;
Content-type: text/html

<html><body>
<form method="post" action="test.pl">
<input type="text" name="test">
<input type="submit">
</form>
<p><b>Output:</b></p>
<p>
START

my $test = ( <STDIN> or '' );

print $test;

print "</p></body></html>\n";

__END__

 

[Bill Smith]

Yeah, I can run Perl scripts just fine on my Terpy server. The only
problem it seems to have is getting parameter values from textfields in
CGI. Everything else works fine (hell, I'm running a slashcode website,
which is all based on Perl).

Sorry that I cannot offer any solutions, but I have noticed a possible
clue. Both servers execute your script correctly when the "amount"
parameter is manually appended to its URL. This tends to confirm your
speculation that the primary problem is that parameters are not being
passed from the textfield.

Good Luck!
Bill.

 

[gnari]

if ($money =~ /^([0-9.]+)$/ ) {
$money = eval( $money );
my $spent = 966.5 - $money;

why the captures in the regexp? you do not seem tu use $1

Well, I'm kinda newbie at Perl, so I can take the dollar sign out
because it's unnecessary?

no. I was refering to the inner parens. when a match like
if (/^([0-9.]+)$/) {...}
succeeds, whatever was matched to the part of the regexp
inside the parentheses is assigned to special variable $1.
in this case [0-9.]+
this is called a capture

if you do not need that feature, you can do
if (/^[0-9.]+$/) {...}

look at the docs:
perdoc perlre

gnari

 

[gnari]

If I don't eval() it, it doesn't work. I'm getting my input from a CGI
text field and it doesn't treat that like a number unless I evaluate it.

spooky. does it work without eval on the other server?



anyways. the script works with GET but not POST

you can try, as a stopgap measure, to change the
start_form,
to
start_form(-method=>'GET'),

My guess is that there is something wrong with the server setup.
I noticed, that there were some extra HTTP-headers in the
result, with a fortune. maybe some such useless trick is doing
strange things to the POSTs.

do you know if there are any strange redirects setup on your URL?
they can sometime interfere with POSTs


can you set up a test page similar to these that in addition,
shows all entries of %ENV and all params ?

gnari

 

[Cyde Weys]

spooky. does it work without eval on the other server?

No, is it supposed to?

anyways. the script works with GET but not POST

you can try, as a stopgap measure, to change the
start_form,
to
start_form(-method=>'GET'),

Thanks a lot! That worked! Is there any potential negative side effect
to using this, or can I just leave it the way it is?

My guess is that there is something wrong with the server setup.
I noticed, that there were some extra HTTP-headers in the
result, with a fortune. maybe some such useless trick is doing
strange things to the POSTs.

do you know if there are any strange redirects setup on your URL?
they can sometime interfere with POSTs

Well I am running a slashcode site on the server that wasn't working and
standard apache on the server that was working. Differences in configs
between the 2 probably has something to do with it.

can you set up a test page similar to these that in addition,
shows all entries of %ENV and all params ?

How would I go about doing that?

 

[gnari]

No, is it supposed to?
yes


How would I go about doing that?

basically something like:

+++ start
use strict;
use warnings;
use CGI;
my $q=new CGI;
my %vars=$q->Vars();

print "Content-Type: text/plain\n\n";

foreach my $k (sort keys %vars) {
print "var: [$k]=[$vars{$k}]\n";
}

foreach my $k (sort keys %ENV) {
print "env: [$k]=[$ENV{$k}]\n";
}

print "amount+0=[". ($vars{amount}+0) ."]\n";
print "amount+100=[". ($vars{amount}+100) ."]\n";
+++ end

the last 2 lines are just to show that the eval is not needed.

then try to POST to this and see if the output gives any hints.
for this you can use the commands GET and POST that come with
LWP (or don't they?)


gnari