|
|
|
| |
        
|
 |
|
To access the contents, click the chapter and section titles.
Platinum Edition Using HTML 4, XML, and Java 1.2
Look at the following innocuous UNIX CGI script: #!/bin/sh # Send the header echo “Content–type: text/html” echo “” # Send some HTML echo “<HTML><HEADER><TITLE>Fortune</TITLE></HEADER> echo “<BODY>Your fortune:<HR><PRE>” fortune echo “</BODY></HTML>” Now imagine if the permissions on the script allowed a local user to change the program to the following: #!/bin/sh # Send the header echo “Content-type: text/html” echo “” # Do some damage! rm -rf / echo “<HTML><TITLE>Got you!</TITLE><BODY>” echo “<H1>Ha ha!</H1></BODY></HTML>” The next user to access the script over the Web would cause huge amounts of damage, even though that person had done nothing wrong. Checking the integrity of user input over the Web is important, but even more so is making sure that the scripts themselves remain unaltered and unalterable.
Local File SecurityEqually important is the integrity of the files that your scripts create on the local hard disk. After you feel comfortable that you have a good filename from the Web user, how you actually go about using that name is also important. Depending on which operating system your Web server is running, permissions and ownership information can be stored on the file along with the data inside it. Users of your Web server may cause havoc depending on how various permission flags are set. You should be aware, for instance, of the permissions you give a file when you create it. Most Web server software sets the umask, or permission restrictions, to 0000, which means that it’s possible to create a file that anybody can read or write. Although the permissions on a file probably don’t make any difference to people browsing on the Web, people with local access can take advantage of loose restrictions. You should always specify the most conservative permissions possible while still allowing your program the access it needs when creating files.
The simplest way to make sure that each file-open call has a set of minimum restrictions is to set your script’s umask. umask() is a UNIX call that restricts permissions on every subsequent file creation. The parameter passed to umask() is a number that’s “masked” against the permissions mode of any later file creation. An umask of 0022 will cause any file created to be writeable only by the user, no matter what explicit permissions are given to the group and other users during the actual open. But even with the umask set, you should create files with explicit permissions, just to make sure that they’re as restrictive as possible. If the only program that will ever be accessing a file is your CGI script, only the user that your CGI program runs as should be given access to the file: permissions 0600. If another program needs to access the file, try to make the owner of that program a member of the same group as your CGI script so that only group permissions need to be set: permissions 0660. If you must give the world access to the file, make it so the file can only be read, not written to: permissions 0644. Use Explicit PathsFinally, a local user can attack your Web server in one last way by fooling it into running an external program that he wrote instead of what you specified in your CGI script. The following is a simple program that shows a Web surfer a bit of wisdom from the UNIX fortune command: #!/bin/sh # Send the header echo “Content-type: text/html” echo “” # Send the fortune echo “<HTML><HEADER><TITLE>Fortune</TITLE></HEADER><BODY>” echo “You crack open the cookie and the fortune reads:<HR><PRE>” fortune echo “</PRE></BODY></HTML>” This script seems harmless enough. It accepts no input from the user, so he can’t play any tricks on it that way. Because it’s run only by the Web server, the permissions on the script itself can be set to be very restrictive, preventing a trouble-minded local user from changing it. And, if the permissions on the directory in which it resides are set correctly, not much can go wrong—true? Not true. The code snippet above calls two commands, echo and fortune. Because these scripts don’t have explicit paths specifying where they are on the hard disk, the shell uses the PATH environment variable to search for them, and this can be dangerous. If, for example, the fortune program was installed in /usr/games, but PATH listed, say, /tmp before it, then any program that happened to be named “fortune” and resided in the temporary directory would be executed instead of the true fortune (see Figure 35.7).
This program can do anything its creator wants, from deleting files to logging information about the request and then passing the data on to the real fortune—leaving the user and you none the wiser. You should always specify explicit paths when running external programs from your CGI scripts. The PATH environment variable is a great tool, but it can be misused the same as any other.
|
|
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.
|
)
){kind=link}