7.7. Securing Scripts

As mentioned in Section 1.1.2 , scripts present a great danger to Web servers. Many a notorious break-in has been perpetrated by exploiting bugs in scripts. You already know that all unused interpreters should be disabled, leaving only those that are really necessary. This will make breaking into the server difficult but not impossible .

The safest site is one that uses static (HTML) documents without server-side scripts (PHP, ASP, Perl, Python, etc.). If you need an interpreter for your site, limit it to minimal capabilities.

Suppose that your site uses PHP scripts and has functions that access the system. If these functions are used improperly (for example, user -specified parameters are not checked), a malefactor can send such values that may disrupt the server's operation. This book does not teach you how to write correct scripts and how to make them secure, because this is a programmer's job. But you should not rely on programmers' professionalism , because they also are humans, and all humans make errors. What you should do is to take all necessary steps to prevent software bugs from becoming fatal for your server.

The PHP interpreter has a feature called safe_mode. This feature can be used to describe the rules for executing certain actions using more secure configuration settings and access rights. But some scripts may not work in this mode, and many administrators disable it. This is not always the right thing to do. You should check first whether the offending script can be rewritten to work; only when this is impossible should safe_mode be disabled.

When configuring the interpreter, you should start by prohibiting everything. Afterwards, the necessary options are gradually enabled. It would be the best if you could configure not only the work server but also the server used by the programmers for developing and debugging scripts. In this case, you will be able to control all configuration parameters.

The administrator should act in close cooperation with the Web script programmers. If the programmers require some options for the scripts to be enabled, the person to do this on both servers should be you. The developers should inform you of any changes in the scripts that require changes in the access rights, so that you can make the necessary adjustments.

The administrator and developers should maintain close contact to be able to react rapidly to developments necessitating the use of some extra features. Some administrators like to get rid of the interpreter-configuring responsibilities, shifting this function to their script developers. This is not right, because a programmer is trained to write programs and has no sufficient knowledge to configure with the necessary security level provided.

All PHP interpreter-configuration settings are stored in the /etc/php.ini configuration file. Consideration of this file lies beyond the scope of this book.

7.7.1. Security Fundamentals

At present, most Internet break-ins are perpetrated by taking advantage of bugs in Web page scripts. I'll investigate why this happens.

Most personal site owners are just regular users who want to quickly obtain their own Web page with an extensive feature list. What features does a decent site need? These are a guestbook, forum, chat, polling, and so on. These sections cannot be created using simple HTML and require some sort of programming, for example, Perl or PHP. Regular users do not want to (or cannot) become involved with the intricacies of programming, and they use ready-made engines (payware or freeware) in their projects.

But as you already know, sooner or later bugs are discovered in any software. Widely-used programs, in particular, attract hackers' attention, because breaking these allows them to penetrate the numerous systems, on which these programs are installed.

If you use on your site a forum based on a popular engine, you must understand that sooner or later bugs will be discovered in it and the forum can be used by hackers as an entrance into your server. To prevent this, you should update the Web programs and scripts used on the server regularly.

If you know at least the basic principles of Web application protection, you could write your own forum, which may be more secure than similar products by third parties.

But if you do not know the specifics of the programming language or have no programming skills, you will be better off using software products written by other people. A script written by an amateur can be broken even by a novice hacker without knowledge of the source code, database structure, and other details that facilitate breaking Web scripts.

As they say, damned if you do, damned if you don't. The safest course is to use less popular software developed by professional programmers on your site. It would be even better for it to be closed or even custom-written source code. This entails extra financial expenses, but these are smaller than the costs of restoring the system after a break-in.

If you are responsible for only one Web server, the task of software updating is not a problem. But administrators of hosting companies face a daunting task in this respect, because their servers host hundreds if not thousands of Web sites. It is impossible to monitor all Web sites for regular software updates, but some sort of protection against careless or lazy site owners is still needed. The Jail program (see Chapter 4 ) best suits this task. Using this program, you place a Web service into its own virtual directory. If hackers break a Web program and penetrate the Web service using it, their actions will be limited to the confines of the virtual root directory.

When preparing the material for this book, I found that a vulnerability was discovered in a popular forum engine that made it possible to execute any command on a system hosting a Web site with the forum. This was done by sending a command formatted in a special way through the URL string. I started writing this chapter about a month after the bug was discovered and, remembering this, decided to check a few Internet servers for it. I ran a search of all sites using the vulnerable forum. You may find it hard to believe, but there were hundreds of them.

My attention was attracted by a couple of sites hosted on the server of a major hosting company. I executed the ls -a / etc command on both of them. The results were not long in coming: The entire /etc directory was at my disposal with permissions even to delete files. I did not do this even to test the extent of my access rights. I did, however, rename a file on each system and inform the administrators about the vulnerability.

Note

I do not recommend doing anything similar yourself. Not all administrators take it well if their sites are broken into, even when this is done with benevolent intentions. Some of them may even notify law-enforcement agencies, which won't bode well for you. Your good intentions may not necessarily be considered in the proper light. When I inform administrators of the vulnerabilities I find in their servers, I do it through an anonymous message.

Placing Apache into a virtual root directory, you only secure the system; all sites located in the virtual directory remain vulnerable. To protect Web sites, you have to look to other ways for example, by regulating access rights, running several instances of the Apache Web server (each in its own virtual root directory), running dedicated servers for individual sites, or prohibiting insecure PHP functions from executing.

It is difficult and sometimes simply impossible to pick the most effective way to protect multiple virtual servers. For example, one site requires a PHP interpreter, while another requires Perl. You have no choice and must allow both languages.

Based on personal experience, I can suggest using individual physical servers to separate sites according to their requirements, such as the following:

PHP interpreter is used in the safe mode.
Full-rights PHP interpreter is required.
Perl interpreter is used.

You should group sites based on their requirements; this will make administering them easier and simpler.

Important sites should be located on a dedicated server and watched closely. For example, you should not place electronic stores and personal pages on the same server. The latter are often constructed using free modules, which frequently contain bugs; moreover, their owners do not update the site software. Sooner or later, these weaknesses will lead to a break-in into a home page. Once on the server, the miscreant will find a way to penetrate the Web stores located on the server and to obtain confidential financial data. This will put an end to your administrative career.

7.7.2. The mod_security Module

Even though the security of a Web server depends largely on the scripts run on it and the programmers who write these scripts, a server can be protected independently of these factors. An excellent solution to this problem is a free Apache module called mod_security.

The principle of operation of this module is similar to that of a firewall built into the operating system, only it was developed especially for providing interaction with HTTP. Based on the rules set by the administrator, the module analyzes requests from users to the server and decides whether or not let them through to the Web server.

The rules specify what a request may and may not contain. A request usually contains the URL, from which a document or file must be obtained. How can rules for the module be specified to enhance the system's security? Consider a simple example: Unauthorized access to the /etc/passwd file endangers the server's security; consequently, there should be no references to it in the URL string.

Based on this rule, the module checks the URL string. If it does not comply with the rule, the request is rejected.

The mod_security module can be downloaded from the www. modsecurity .org site. Installing the module allows new request-filtering directives to be specified in the httpd.conf file. The most interesting of them are the following:

SecFilterEngine On Enables the request filtering mode.
SecFilterCheckURLEncoding On Checks the validity of the URL encoding.
SecFilterForceByteRange 32 126 Specifies to use characters from the particular range only. There are quite a few control characters (e.g., carriage return and line end) whose codes are less than 32. Most of them are invisible but require the corresponding key presses to be processed . How can such a character be entered into a URL string? This can be done using their codes. For example, the end-of-line character is entered in a URL by typing %13 . In this case, a URL cannot contain character codes less than 32 and greater than 126.
SecAuditLog logs/audit_log Specifies the log file, in which the audit information is to be stored.
SecFilterDefaultAction "deny,log,status:406" Specifies the default action. In this case, it is prohibition .
SecFilter xxx redirect: http://www.Webcreator.com Provides for redirection. If the rules have been met, the user is redirected to www.webcreator.com .
SecFilter yyy log, exec :/home/apache/report-attack.pl Launches a script. If the filter is triggered, the /home/apache/report-attack.pl script will be executed.
SecFilter /etc/password Prohibits referencing the /etc/passwd file in user requests. Referencing the /etc/shadow file can be prohibited in the same way.
SecFilter /bin/ls Prohibits users from accessing commands. In this case, access to the ls command is prohibited, which can be used to view contents of directories if a script contains a bug. Access to such commands as cat, rm, cp , and ftp should also be prohibited.
SecFilter "\.\./" Prohibits dots in URLs. A classic attack is carried out by placing dot characters in a URL.
SecFilter "delete [[: space: ]]+from" Prohibits the delete...s from text, which is most often used in SQL queries to delete data. This string is used frequently in SQL injection-type attacks. In addition, I recommend setting the following three filters:
- SecFilter "insert [[: space: ]] +into" Prohibits the string used in SQL queries for adding data.
- SecFilter "select.+from" Prohibits the string used in SQL queries for reading data from a database.
- SecFilter "<(.\n)+>" and SecFilter "<[[:space:]]*script" Protects against cross-Site Scripting (XSS) attacks.

The preceding are the main methods that can be used to enhance the security of your Web server. Server networks can also be protected in this way. Additional information can be obtained from the developer's Web site.

7.7.3. Secrets Revealed and Advice Dispensed

No matter how carefully scripts may be written and how well they are protected by special modules: Undertaking additional security measures will never hurt. There are several more techniques that can be used toward this goal. In this section, I have collected various recommendations that can help you enhance server security.

Script Restriction

First, restrict script execution to an individual directory. In most cases, this will be the cgi-bin directory: I saw a system once, in which the root directory was specified for this purpose, meaning scripts could be executed from any directory. Don't repeat this mistake, because there are many different Perl programs in the system but they should not be allowed to execute on the Web server.

Backup Copies

Never store backup copies of scripts in directories accessible to Web servers. Consider an example. If a Web page contains PHP scripts, users do not see them in the browser; they only see the results of their execution on the server. To view the source code, some sort of access to the server is necessary, for example, through FTP or Telnet, because Apache does not send this sort of data to clients .

Programmers like to save backup copies of scripts before modifying them, so that if something goes wrong, the old, working version of the script could be restored. Often they save these copies in the same directory as the working script, only with a different extension. For example, old and bak are the two used most frequently.

Because the server does not execute these files, if a file is requested , the source code will be displayed in the browser. We all know that having access to the source code makes finding vulnerabilities in a program much easier.

When a hacker is exploring scripts on the server, there is nothing to keep him or her from checking whether there are backup copies of them. If a hacker sees that there is a file named www.servername.com/index.php on the server, he or she will try to load files www. servername .com/index.bak or www.wervername.com/index.old. Such copies of working script files are often encountered on amateur sites. Learn from other people's mistakes and don't do this on your server.

Any security specialist should prohibit users from accessing backup copies. No matter how often programmers are told not to keep on the server anything unnecessary, such as backup copies, they will continue doing this because they find this convenient . Your task is to store these copies safely that is, to forbid Web clients to access them.

This can be done with the help of the following directives:

 <FilesMatch "\.bak$">  Order deny, allow  Deny from all </FilesMatch> <FilesMatch "\.old$">  Order deny, allow  Deny from all </FilesMatch>