Pass value to perl script from URL 2

[jrig]

Hi all, after a bit of searching on google I have (re)turned to tek tips. I have a perl cgi script which generates a dynamic listing of files in a folder for a webpage.

Right now it default sorts by name, but would like to also sort on date, if a link is clicked. Seems pointless to have 2 scripts when I think I can do it with one. I'm familiar of how to do w/asp pages. Any suggestions would be much appreciated.

Also could this be a potential security issue? TIA-

 

[ChrisHunt]

If you look at the URL for this page, you'll see the answer to your question.

[URL unfurl="true"]http://tek-tips.com/viewthread.cfm?qid=1283111&page=1[/URL]

qid and page are parameters passed from the URL to the back-end program.

If you use the CGI.pm library in your perl program, it's easy to retrieve the values of such parameters.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[PaulTEG]

if you're presenting the data already, just making it sortable a different way, could be the horse has already bolted in the security department?

What's the content/purpose of the files? Do you currently permit directory browsing? You could mod the script to function only if a session or cookie is valid, after proper authorisation

HTH
--Paul

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[jrig]

The files in question are mp3s that I store on my server. They are all stored in a single folder with permissions locked down. My script sorts them, numbers them, and creates a hyperlink that can play/save them. No other directory browsing on this server.

 sub mysort(
if ($param eq "q"){sort alpha}
else {sort date}
)

shouldn't get me much trouble right?
I just get a little nervous at the thought of someone plugging in values to a script that can execute on my server. Does that make sense? btw, thanks chris plugging in 'parameters' for my search got me going. I couldn't believe how easy it was!

 

[Kirsle]

The use of parameters in itself doesn't open the opportunity for hackers to attack your server. It's what your code DOES with the parameters.

For instance, if you use param variables to read or write to files, or put them into an eval statement, or anything similar like that, it can lead to problems if somebody puts in data that you weren't expecting.

For example, a calculator CGI with a source like this:

use CGI;
my $q = new CGI;

my $expr = $q->param ('expr');

my $result = eval($expr); # if $expr = "2 + 10 / 2" $result = 7

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

if ($expr) {
   print "$expr = $result<p>";
}

print "<form action='calc.cgi'><input type=text name=expr><input type=submit>";

Well, in that case, if somebody typed something into the text box which wasn't a mathematical calculation (i.e. they could type unlink ("*.*"), then the script would run that command and you'd be in some big trouble.

With reading files, say you have a site management system where a parameter "page" opens a text file to insert content into the page:

use CGI;
my $q = CGI->new;

my $page = $q->param ("page");
open (PAGE, "./private/pages/$page\.txt");
my @page = <PAGE>;
close (PAGE);
chomp @page;

print "Content-Type: text/html\n\n";
print join ("\n",@page);

Well, in that case, they could run a URL like this:

index.cgi?page=../users/admin

And instead of reading ./private/pages/admin.txt, it would read ./private/users/admin.txt and if that's where you keep private user data, they could potentially read your password.

Or they could even go as far as to do something like

index.cgi?page=/home/some/private/folder

They could potentially read every file on your system which could pose a serious security risk.

So, parameters can be dangerous only when you're not filtering them. A common rule of thumb is to simply never trust the information coming in. A simple solution to that file reading code is to filter out any dots or slashes in the parameter text, not allowing them to change directories in it. Or for the calculator, remove everything from $expr that isn't a mathematical operator:

$page =~ s/(\.|\/|\\)//g; # remove . and \ and / from $page

$expr =~ s/[^0-9\+\-\*\/ ]//g; # remove everything from $expr except numbers, +, -, *, /, and spaces

In the example with the calculator, you don't want to allow the backslash \ -- only allow the forward slash / as this is the one used in division in programming languages. Allowing a \ allows a l33t hacker to run malicious codes too, because \ is the escape character (for example, \123 might represent a certain ASCII character, and your calculator would fully accept it. A hacker could run all the escape codes to spell out "unlink" or any other Perl command).

So, when writing code, think of all the possible things somebody could do when sending in data, never trust the data coming in, and be especially cautious when using that data to run program code or read or write files, or basically, anytime the variables "do" anything, make sure that they can't "do" everything at the same time.

 

[jrig]

Thanks Kirsle, nice informative post, too bad I can only give one star. Darn those leet haxors, always mucking up the interwebs. I'm just starting out with passing parameters, dynamic content, etc...so I figure if I try to account for these things up front, I'll have less problems in the long run.

I've also been looking some at 'taint' which appears to address some of the issues you point out above. Ironic, I suppose, because the more I learn about security, the more I learn about vulnerbilities inherent in the system. Man if I knew more php, I could do some REAL damage-

 

[PaulTEG]

by damage, I hope you mean d'homage, meaning 'of the homage' otherwise ...

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)