[ Pobierz całość w formacie PDF ]
.As you followed along in Chapter 7 you should have noticed that you were creating files with customer information in them.Not only does this cause your disk to fill up over time, but it also presents some security risks.The filenames you created inChapter 7 were relatively hard to crack, but if you put many permutations of anything on your disk, someone is more likely tofind a match.One of the simple ways to solve this problem is to just go into the directory every so often and delete all the oldfiles.It works and doesn't require much initial effort, but there is a much simpler solution that only requires a littleprogramming effort and knowledge of one of those marvelous UNIX tools called cron jobs.Cron jobs are programs scheduled to run at a periodic execution rate.You choose how often you want the program to run andthen tell the system what program you want it to run.The magic is in a system service called the cron daemon, which is toldwhat to run by crontab entries.Crontab entries usually are available to the average user by executing this command:crontab -u username crontab.fileThe crontab.file is a simple text file that tells the system when you want to run a program, what the program name is,and where to send any output from the cron job.If you don't specify where to send output, it is sent to the user who started thecrontab job.The way you tell the system what time you want to run the job is a little confusing.The format of the time commandfollows:minutes hours day-of-month month weekdayWhat confuses most people is how each field is interpreted.If you enter 0 5 1 12 * as the time, your program runs onminute zero of the fifth hour of the first day of the month on the twelfth month, regardless of what day of the week it is.Theday of the week is a range from 1 to 7 on UNIX BSD systems, where 1=Monday; and 0 through 6 on System V UNIXsystems, where 0=Sunday.If you want your program to run every 15 minutes, you enter a time command of 0,15,30,45 * * * *.This tells thecron job you want your program to execute on minute 0, 15, 30, and 45 of every hour, every day of the month, every month,and every weekday.This really is the more common format for a crontab file.If you only want your command to run once an hour between the hours of 8 a.m.and 10 p.m., you enter a time command of0 8-22 * * *.You can use the dash (-) to indicate a range of times.Assume that the HTTP_COOKIES you create for your customers have an Expires field set to two hours in the future fromthe date of the cookie creation.After two hours pass, you have lots of old user-authentication files you need to clean up after.The program that does this for you only needs to get the current time using the time() function and delete all files that aretwo hours older than the current time.This algorithm is based on the idea that you are using the Time field to create the namehttp://docs.rinet.ru:8080/CP7/ch12.htm (16 of 18) [2/17/2007 2:06:56 PM] Chapter 12 -- Guarding Your Server Against Unwanted Guestsof your customer-authentication files.The program follows:#There are 7200 seconds in two hours$old-cookie-date = (time() - 7200);/bin/rm usr/local/business/http/www.practical-inet.com/cookies/*$old-cookie-date* ;All you have to do is get your program to run at regular intervals so that it can clean up after all those stray cookie files.To do that, decide on a time interval.Use 15 minutes, for example, and then edit a text file and enter the following:5,20,35,50 * * * * /usr/local/business/http/www.practical-inet.com/cookies/cleanup >/dev/nullThen save the text file as cookies.cron and execute this crontab command:crontab -u username cookies.cronYou should be in the same directory as the cookies.cron file.The program cleanup in the/usr/local/business/http/www.practical-inet.com/cookies/directory now runs at 5, 20, 35, and 50 minutes past the hour every hour of the day.I used a different time than 0, 15, 30, and45 just so you could see that any time will do in this field.One thing to take special note of is the full pathname given in therm command.Your program will be executed by the system, and you should not use any environment variables to determinewhere your files are located.Always use full pathnames when running cron jobs.With two lines of code and a little reading,you now never have to go in and clean up old cookie files on your server disk.It's the lazy engineer's way out, but now youhave time for more fun programming jobs.SummaryIn this chapter, you learned several ways to protect your programs and your server from intruders.You learned that not onlymust you be concerned about expected user input from text fields and query strings, but you also must be concerned aboutmodification to fixed input like radio button groups.The source of data for your CGI program always should be suspect.Acommon trick of hackers is to download the form you built and modify it for their own purposes.Don't ever use any dataavailable from user input, including seemingly fixed things like radio buttons, without first verifying the data.Next, you learned the details of how to set up the global access-control file, access.conf.In addition, by learning aboutthe global access-control file directives, you learned about per-directory access-control directives because, except for theAllowOverride directive and the directive, all global access-control file directives also are validper-directory access-control directives.Per-directory access-control directives are used in per-directory access-control files,such as.htaccess, that can be used to set up individual di-rectory password control.You also learned that you can do simple things like removing old copies of CGI programs to protect your site.You canprotect your site from intrusion by writing secure programs and maintaining proper control of your programming directories.Q&AQ How can I tell who is hacking into my programs?A Your access_log file in the server root logs directory contains lots of information about how your CGI programs arebeing called, as shown by the selected pieces of the access_log file shown in Listing 12.5.Listing 12.5.A fragment from the access_log file.01: dialup-30.austin.io.com - - [08/Oct/1995:15:05:48 -0500] "GET/phoenix HTTP/1.0" 302 -02: dialup-30.austin.io.com - - [08/Oct/1995:15:25:17 -0500] "GET /phoenix/index.shtml HTTP/1.0" 200 286003: crossnet.org - - [08/Oct/1995:19:56:45 -0500] "HEAD / HTTP/1.0" 200 004: dialup-2.austin.io.com - - [09/Oct/1995:07:54:56 -0500] "GET /leading-rein/orders HTTP/1.0" 401 -http://docs.rinet.ru:8080/CP7/ch12.htm (17 of 18) [2/17/2007 2:06:57 PM] Chapter 12 -- Guarding Your Server Against Unwanted Guests05: dialup-48.austin.io.com - - [10/Oct/1995:11:07:59 -0500] "POST /cgibook/chap7/reg1.cgi HTTP/1.0" 200 23206: dialup-48.austin.io.com - - [10/Oct/1995:11:08:26 -0500] "POST /cgibook/chap7/reg1.cgi HTTP/1.0" 200 23207: onramp1-9.onr.com - - [10/Oct/1995:11:11:40 -0500] "GET / HTTP/1.0" 200 152908: onramp1-9.onr.com - - [10/Oct/1995:11:11:43 -0500] "GET/accn.jpg HTTP/1.0" 200 2034209: onramp1-9.onr.com - - [10/Oct/1995:11:11:46 -0500] "GET/home.gif HTTP/1.0" 200 133110: dialup-3.austin.io.com - - [12/Oct/1995:08:04:27 -0500] "GET /cgi-bin/env.cgi?SavedName=+&First+Name=Eric&Last+Name=Herrmann&Street=&City=&State=&11: zip=&Phone+Number=%28999%29+999-9999+&Email+Address=&simple=12: +Submit+Registration+ HTTP/1.0" 200 1261Take a look at the access_log file on your server.It tells an interesting tale about how your programs are being called.You can get specific information on just a single CGI program by using the grep command, as this example shows:grep program-name.cgi server-root/logs/access_log >program-name
[ Pobierz całość w formacie PDF ]
