CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
INDEX
Search Posts SEARCH
POSTS
Who's Online WHO'S
ONLINE
Log in LOG
IN

Home: Perl Programming Help: Beginner:
Security Question??

 



brian.hayes
User

Jan 20, 2000, 6:44 PM

Post #1 of 6 (1246 views)
Security Question?? Can't Post

I have been reading up on perl scripting and security. It has left me a little confused about some things. I understand that If you make a system call with a variable that derives from a CGI.pm "Form" variable that you need to take special care to ensure that the data entered by someone is what you really want it to be. BUT how far should this be taken. I have shtml enable on my web server and did some test.

Test: Created a script
<BLOCKQUOTE><font size="1" face="Arial,Helvetica,sans serif">code:</font><HR>


#/path/to/perl

use CGI;
my $c = new CGI;

print $c->header;

my $in = $c->param('test');

print "<p>",$in,"</p>","\n";

</pre><HR></BLOCKQUOTE>


Then a basic web form with a text box named "Test".

<BLOCKQUOTE><font size="1" face="Arial,Helvetica,sans serif">code:</font><HR>



<HTML>
<HEAD>
<TITLE>Testing</TITLE>
</HEAD>
</BODY>

<FORM method="post" action="pathtoscript">
<INPUT type="text" name="test" value="">
</FORM>

</BODY>
</HTML>
</pre><HR></BLOCKQUOTE>


When this is ran I get the data that was sent returned in the browser window..No mater what I type in the text box.

Test 2:

If I create a test.shtml.
use a include stament.
<!--include virtual=/path/to/script -->
and put the form in the script via.

<BLOCKQUOTE><font size="1" face="Arial,Helvetica,sans serif">code:</font><HR>


print qq~
<FORM method="post" action="pathtoscript">
<INPUT type="text" name="test" value="">
</FORM>
~;
</pre><HR></BLOCKQUOTE>


The page displays ok. The data sent to the script displays ok,

BUT if I put a include statment in the text box it will not display. I do not know where it is going. It is not being sent to anywhere other than a print statement.

Can anyone give some insite on this..

Thankyou,

Brian Hayes



brian.hayes
User

Jan 21, 2000, 5:48 PM

Post #2 of 6 (1246 views)
Re: Security Question?? [In reply to] Can't Post

Anyone?


Borderline
Deleted

Jan 21, 2000, 6:52 PM

Post #3 of 6 (1246 views)
Re: Security Question?? [In reply to] Can't Post

Hey,

I just do not understand what you are trying to do. Could you try and explain it a little better? What do you mean by this?
BUT if I put a include statment in the text box it will not display.

Scott


brian.hayes
User

Jan 21, 2000, 8:27 PM

Post #4 of 6 (1246 views)
Re: Security Question?? [In reply to] Can't Post

Sorry,

I'm talking about a form text box, and passing the variable to a CGI param->('text');

Parsed html file code in a text box and passing it to a CGI.pm script. For that matter any type system call or function being passed into a CGI.pm script.

Like HTML being turned off in this Forum.

What I am trying to aim at here is how far do we need to secure a script before it is to far.

I do realize that there is never to much security, but it can become time consuming and if someone is under time constraints some thing may get missed. which could result in bad thing happening to a web site.

Long story short I guess, I there any good tips on this type of issue?

Brian Hayes


Borderline
Deleted

Jan 21, 2000, 11:10 PM

Post #5 of 6 (1246 views)
Re: Security Question?? [In reply to] Can't Post

Security is a very big issue in any program that gives an outside unknown user access to your system. Which this is exactly what a CGI does. There are so many security concerns that I could not even begin to point them all out. If you are not very familiar with CGI security issues I would recommend you get a book on it. Preferably something published by O'REILY. I know it is kinda lame me telling you to get a book for this sort of thing but believe me it is not a small topic you can just do a few tests on and find out if there is a problem. To be a little more specific on things like the ping program you pointed me to can be a major security risk if they do things like this
$input = param('input');

# Do a bunch of regex on $input here to try and weed out bad
# characters but it is pointless

open PING, "|ping $input" or die "Broken pipe: $!";

This is VERY BAD
Notice how the open is not giving the path to ping. Well this leaves the command open to shell interpretation. You can write an entire program in a Unix shell! Even if you are giving the full path to the program you are calling you must know that program and all the arguments it can take and these programs arguments can change from system to system and from version to version so you have to really know what you are doing before you do something like this. Just because I filter out all the & and | and ; does not mean I am safe.

I really hope this helped and sorry for rambling
Scott


brian.hayes
User

Jan 21, 2000, 11:29 PM

Post #6 of 6 (1246 views)
Re: Security Question?? [In reply to] Can't Post

I understand. This is what I have to check to make sure that the input is valid, but I didn't write it and really do not under stand it much. See check_vars();

<BLOCKQUOTE><font size="1" face="Arial,Helvetica,sans serif">code:</font><HR>


$ping = '/path/to/ping -c 5';
# ping only 5 times.

$clean = &check_vars();


open PING, "|$ping $clean" or die "Broken pipe: $!";

sub check_vars{

if ( $ENV{'REQUEST_METHOD'} ne "POST")

{ $temp=$ENV{'QUERY_STRING'};}

else { read(STDIN,$temp,$ENV{'CONTENT_LENGTH'});}

@pairs=split(/&/,$temp);

foreach $item(@pairs)

{

($target)=split(/=/,$item,2);

$target =~tr/+/ /;

$target =~s/%(..)/pack("c",hex($1))/ge;

$target =~s/\012//g;

$target =~s/\015//g;

$target =~s/ //g;

}

$clean=$target;

if ($target =~ /^([-\@\w.]+)$/ &#0124; &#0124; $target eq "")

{$clean = $target;

return;

}

else

{$target ="";

print "Content-type: text/html\n\n";

print "Illegal Character(s) sent...";

exit;

}

}
</pre><HR></BLOCKQUOTE>

Thanks,

Brian Hayes


 
 


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives