When you install your Web server, default directories are created for
for configuration files, another for logs, one for HTML documents, and yet another for CGI scripts. Generally, the directory used to store CGI scripts and programs is called CGI-BIN.
When you look at Figure 4.5, you will notice that the HTML direc-tory (which is used to store Web pages and other content for the Web site) is in a separate directory from the CGI-BIN directory (used to store CGI scripts and programs). By keeping the CGI scripts and programs in a separate directory from other content for the site, users are generally unable to view the contents of the CGI-BIN directory with a Web browser.You may be aware that when you access a Web site by entering a URL like www.syngress.com, a default Web page (such as default.htm or index.htm) is displayed to the user.This Web page, and any other HTML documents accessed on the site, is stored under the directory that’s speci-fied to store HTML documents. In the case of Figure 4.5, this directory is called HTML.While users may be able to access subdirectories under the HTML directory, they are restricted by permissions from navigating above this directory.To do so would allow users to access the files used to run the Web server. Because the CGI-BIN is separated from the direc-tory used to store HTML documents, this aids in preventing users from navigating your directory structure into the CGI-BIN and reading any scripts within it.
Figure 4.5Example of a Web Server’s Directory Structure
Web Server Installation Directory
CGI-BIN
HTML
CONF
LOGS
The directory that’s used to store HTML documents is commonly referred to as the document root. A number of Web servers will allow you to put CGI scripts and programs in this directory, along with the Web pages, graphics, and other elements used for your Web site.This presents a security risk, as files stored in the document root will require read permissions for all users, so that they can read the Web pages and view them on an Internet browser. If CGI scripts are placed in a direc-tory with these rights, then a hacker could read your CGI scripts and find possible ways to attack your site.This may include finding informa-tion about the server’s directory structure, usernames, passwords, com-ments, or other items that could be exploited.
Placing scripts and programs in the CGI-BIN is also advantageous because it is easier to only have to worry about setting permissions on one global CGI directory. If permissions are set properly, users will be able to execute these programs, but won’t have the ability to read or write to the directory. Improper permissions are how many hackers use the CGI-BIN to attack a site. If users can read files in a directory, they can view information contained within it. If the write permission has been set for all users, or user accounts that shouldn’t have this ability, then users could rewrite a script, or upload a program to the directory that has the same name as the original.When the program or script is later executed, then unwanted activities (such as restarting your server or worse) could result.
Of particular importance to placing scripts and programs in a CGI-BIN directory is organization. It is easier to find and maintain these pro-grams if they are located in the same directory; it is wise to place them in the CGI-BIN. Imagine trying to find a single script on a site that has them scattered across several places. In addition to the time you’ll spend trying to find a particular script, there is a greater chance that one will reside in a directory with improper permissions, causing a potential security threat.
Because CGI-BIN is the common name for a directory used in storing CGI scripts and programs, it makes sense that hackers would first look to see if this directory exists, and then try to exploit improper per-missions and bad coding. For this reason, a number of Web servers offer
you the ability to specify a different name for these directories. For example, you could specify that CGI scripts and programs are contained in a directory named CGI, PROGS, or any other name you choose. If a hacker who exploits CGI vulnerabilities goes to your site, he or she will find that a CGI-BIN directory isn’t there.The hacker may feel it’s easier to move on to another site that does have a CGI-BIN, and leave you alone. Moreover, as mentioned earlier, most hacking tools that look for CGI vulnerabilities will only look in the CGI-BIN. Since this directory doesn’t exist, these tools will either show that no vulnerabilities are found, or will show that no CGI scripts exist.
Summary
CGI programs can be a great benefit or a great burden, depending on whether you’ve protected yourself against possible vulnerabilities that can be used to hack your site.We saw in this chapter that CGI programs and scripts run on the server side, and act as a middleman between the Web server and an external application.They are used on numerous sites on the Web, and for a variety of purposes. In terms of e-commerce sites, they are essential to the method in which business is conducted, and many sites cannot function without them.
Break-ins resulting from weak CGI scripts can occur in a variety of ways.This may be through gaining access to the source code of the script and finding vulnerabilities contained in them, or by viewing infor-mation showing directory structure, usernames, and/or passwords. By manipulating these scripts, a hacker can modify or view sensitive data, or even shut down a server so that users are unable to use the site.
In most cases, the cause of a poor CGI script can be traced back to the person who wrote the program. However, by following good coding practices and avoiding common problems, you can avoid such problems, and you will be able to use CGI programs without compromising the security of your site.