|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
Common Gateway Interface (CGI) Security, Part 5
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
Allowing scripts to run on your server can create large security
holes. If the script receives information other than what you were
expecting, a malicious user can at least read and/or destroy CGI-
created data and at worst take the first (most difficult) step in
gaining total access to the server.
The two biggest security holes are file i/o (reading from and writing
to files) and sub-shells (where variables in the program can be
interpreted as commands). The general way to avoid security holes
is the same:
Don't trust anything the user sends back!
(and also for you administrators out there, never ever run a web
server as root)
------------------------------------------------------------------------
What to look out for
File I/O File i/o means reading from and writing to files on the
server. If file i/o is done improperly, the web-client can read or
destroy files other than the ones you intended them to. The Perl
commands related to file i/o (roughly in their relative level of
danger) are:
open (">", "<", ">>" also see the sub-shell discussion below for
"|") unlink/rmdir read (also the <FILEHANDLE> construct)
dbmopen (and the use of the associative array created)
print/printf/sprintf write close/dbmclose
------------------------------------------------------------------------
Sub-shells One of the great abilities of Unix is to run other
programs in the middle of one of your programs. This can be quite
dangerous if you don't look out. Ways of spawning sub-shells in
Perl include: (these are pretty much equally dangerous)
eval system exec `shell_command ` (backquotes)
open(HANDLE,"shell_ command|"); or
open(HANDLE,"|shell_command");
------------------------------------------------------------------------
How to make scripts more secure
General Rule: Make the user-returned information fit your
expectations Just because you have a form to access your CGI
script doesn't mean that your script will always be called from that
script; especially if someone's trying to use your script to do
something bad. Don't do anything with an arbitrary set of variables
Make sure you know the specific variables your program uses.
Don't do things like this:
@user_args=split(/&/,$ENV{'QUERY_STRING'});
foreach $file (@user_args) {
open(FILE,">$file");
print FILE "Hi there\n";
close(FILE);
}
Make the contents of your variables look like you expect them to
Use s/// and tr// liberally! Whenever possible, do something like
this:
read(STDIN,$buffer,$ENV{'CONTENT_LENGTH'});
@pairs=split(/&/,$buff);
foreach $pair (@pairs) {
($name,$value)=split(/=/,$pair);
$value=~tr/+/ /;
$value=~s/%([0-9A-Fa-f]{2})/pack("C",hex($1))/eg;
############# the next line is the important one ###############
$value=~tr/A-Za-z0-9//cd; #this wipes out anything non-alphanumeric
$form{$name}=$value;
}
Be even more specific if you can (like tr/0-9//cd; if you only want
digits). If you do the alphanumeric-only tr, you don't need the 2
standard translation lines.
------------------------------------------------------------------------
Specific Guidelines for File I/O If your script has any file i/o, you
want to make sure that any file description has no ~s or ../s in it,
since those characters could be used to create or read from
unexpected files. Do things like this:
## user-input in associative array %form
$form{'filename'}=~tr/~//d; #get rid of ~s
$form{'filename'}=~s/\.\.\///g; #get rid of ../s
open(HANDLE,"$startpath/$form{'filename'}");
Specific Guidelines for Sub-shells If your script spawns any sub-
shells, you need to make sure it contains no shell metacharacters
from user-input. Shell metacharacters are special characters used to
separate, customize, or relate Unix shell commands. Shell
metacharacters include (I doubt this is a comprehensive list):
{ } [ ] | ; < > & ( ) ! \
Any user-supplied information which will be sent to a sub-shell
should be run through something like this:
$form{'search'}=~tr/A-Za-z0-9 ._=+-//cd;
## $form{'search'} is now clean but can still contain the characters we specify
open(FIND,"grep $form{'search'} /export/home/me/mydatabase |");
You can also do something a little less invasive than that by
escaping those bad characters with a line like this:
$form{'search'}=~s/([{}[]|\;<>()])/\\$1/g;
This will put an escaping back-slash in front of any potentially
dangerous character.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
