Firewalling Challenges: The Basic Web
This chapter discuss the challenges firewall implementations face in light of the HyperText Transmission Protocol (HTTP) and some of its security issues. It also discusses the proxing characteristics of HTTP and its security concerns. It explores the secure HTTP (S-HTTP) as well as the use of SSL for enhanced security and reviews the security implications of Common Gateways Interface (CGI
Being an application-level protocol developed for distributed, collaborative, hypermedia information systems, the Hypertext Transfer Protocol (HTTP) is a very generic and stateless protocol, enabling systems to be built independently of the data being transmitted. It is also an object-oriented protocol with capabilities to be used for a variety of tasks, which includes but is not limited to name servers, distributed object management systems and extension of its request methods, or commands.
One of the great features of HTTP is the typing and negotiation of data representation. This protocol has been in use since 1990, with the W3 global information initiative.
The most current version of HTTP is version 1.0, which is supported by all Web servers in the market. But there is also another version of the protocol, HTTP-NG (Next Generation), which promises to use the bandwidth available more efficiently and enhance the HTTP protocol.
Further, HTTP is a protocol that can be generically used for communication between user agents and proxies or gateways to other Internet protocols, such as SMTP, NNTP, FTP, Gopher and WAIS.
Nevertheless, all this flexibility offered by HTTP comes at a price: it makes Web server, and clients, very difficult to secure. The openness and stateless, characteristics of the Web, accounts for its quick success, but makes it very difficult to control and protect.
On the Internet, HTTP communication generally takes place over TCP/IP connections. It uses as default port 80, but other ports can be used, which does not prevent HTTP from being implemented on top of any other protocol. In fact, HTTP can use any reliable transport.
When a browser receives a data type it does not understand, it relies on additional applications to translate it to a form it can understand. These applications are usually called viewers, and should be the one of the first concerns you should have when preserving security. You must be careful when installing one, because, again, the underlying HTTP protocol running on your server will not stop the viewer from executing dangerous commands.
You should be especially careful with proxy and gateway applications. You must be cautions when forwarding requests that are received in a format different than the one HTTP understands. It must take into consideration the HTTP version in use, as the protocol version indicates the protocol capability of the sender. A proxy or gateway should never send a message with a version indicator greater than its native version. Otherwise, if a higher version request is received, both the proxy or the gateway must either downgrade the request version, respond with an error, or switch to a tunnel behavior.
The majority of HTTP clients, such as Purveyor (http://www.process.com) and Netscape Navigator, support a variety of proxying schemes, SOCKS and transparent proxying.
Purveyor, for instance, provides proxy support for not only HTTP, but also FTP and GOPHER protocols, creating a secure LAN environment by restricting internet activities of LAN users. The proxy server offers improved performance by allowing internal proxy caching. Purveyor also provides proxy-to-proxy support for corporations with multiple proxy servers.
If you are running your Web server on Windows NT, Windows 95 or NetWare, you can use Purveyor Webserverís proxy features to enhance security. In addition, you can increase the performance of your server as Purveyor can locally cache Web pages obtained from the Internet.
Installing a firewall at your site should be a must. Regardless if you are placing your server outside or inside your protected network, a firewall will be able to stop most of the attacks, but not all! The openness of HTTP is too great for you to risk. Besides, you still have all the viewers and applets to worry about.
When selecting a firewall, make sure to choose one that includes HTTP proxy server, check Appendix A "Types of Firewalls and Products on the Market" for a complete review of all the major firewalls vendors and specifications of their products. Also, check the CD that accompanies this book, as many of the vendors listed on Appendix A provided demos and evaluation copies of their products, which are worth testing.
Firewalls will tremendously help you protecting your browsers. Some firewalls, such as TIS FWTK provide HTTP proxing totally transparent to the user. More will be seeing about firewall in chapter 7, "What is an Internet/Intranet Firewall After All." For now, you must be aware of the firewalling challenges when dealing with Web security requirements and the HTTP protocol.
The Basic Web
Do you know what happens when a user connects to your site? If you donít know how they come in, you will not know how to lock the door.
If you have a Web server on your site, every time a user establishes a connection to it, his client passes to your Web server the numeric IP address of the machine. In some wise situations, the IP address your Web server will receive is not even the clientís address, but the address of the proxy server his requests goes through. What your server will see then is the address of the proxy requesting the document on behalf of the client. But the client, thanks to the HTTP protocol, can also disclose to the Web server the username logged at the client, making the request.
Unless you have set your server to capture such information, what it will do first is to reverse the numeric IP address in an attempt to get the domain name of the client (e.g. www.vibes.com). But in order for the server to get this domain name, it must first contact a domain name server and present it with the IP address to be converted.
Many times, IP addresses cannot get reversed as they were not correctly configured. Consequently, the server cannot reverse the address. What happens next? The serve goes ahead and forges the address!
Once the Web server has the IP address and the possible domain name for the client, it start to apply a set of authentication rules, trying to determine if the client has access permission to the document requested.
Did you notice the security hole? There are few security holes here, as a result of this transaction:
As discussed above, as far as clientís threats to your server, you should be careful with the security of your server. You should make sure clients will access only what they are supposed to and if there is a hostile attack, that your server has some way to protect the access to it.
However, not all is loss, as there are few basic steps you can follow in order to enhance the security of your server:
To illustrate what a misconfigured domain name can do to a reversal IP address process, take in consideration the entries you enter in your access.conf file. Keep in mind that this file is responsible for the access control of the documents in your server.
When setting up this file, you will need to put a <directory> tag, for each directory being controlled, into the access.conf file. Within the <directory> tag you will also need to use a <limit> tag with the parameters (allow, deny, and order) needed to control access to the directory.
The following is an example where the whole Cyberspace can access the files in you top-level document directory:
One of the key lines here is the "order" directive, telling the server to process "allow" directives (from ALL clients) before any "deny" directives. Have you noticed we donít have any "deny" directive?
Now lets assume you need to restrict an area on your server only for internal users to access it. Unlike the above example, you will need a "deny" directive:
In this case, the "deny" directive came before the "allow" directive, so that the whole Cyberspace can have its access restricted access to the company. The "allow" directive permit access from anyone coming from greatplace.com domain.
If the server canít reverse the IP address of a client, then you have a problem, as the domain name is critical to this process. Simply put, the user will not be able to access the Web page.
But, there it is a "Band-Aid" solution. You can add raw IP numbers to the access list.
This way, the directive "allow" will permit any access coming from "greatplace" but also from any machine where the IP address starts with 198.155.25.
What to Watch for on the HTTP Protocol
The HTTP protocol has some more security holes to justify a firewall. One of them is that it allows remote users to request communication to a remote server machine, and to execute commands remotely. This security hole compromises the Web server and the client in many ways, including but not being limited to:
Most of these security holes are well known. Some applications like Netscapeís SSL and NCSAís S-HTTP try to address the issue, but only partially.
The problem is that Web servers are very vulnerable to clientís behavior over the Internet. I recommend you to force Web clients to prompt a user before allowing HTTP access to reserved ports other than the port reserved for it. Otherwise, these could cause the user to unadvertedly cause a transaction to occur in a different and danger protocol.
Watch the GET and HEAD methods! The so trivial link to click an anchor to subscribe or reply to a service can trigger an applet to run without the userís knowledge, which enables the abuse by malicious users.
Another security hole of HTTP has to do with server logs. Usually, a Web server logs a large amount of personal data about information requested by different users. Evidently, this information should remain confidential. HTTP allows the information to be retrieved without any access permission scheme.
There is a feature, the "Referer:" field, that increases the amount of personal data transferred. This field allows reading patters to be analyzed and even reverse links to be drawn. If in wrong hands, it could become a very useful and powerful tool that can lead to abuse and breach of confidentiality. To this day, there are cases where the suppression of the Referer information is not know. Developers are still working on a solution.
Many other HTTP limitations and security holes exist if we were to break down the ramifications of the above security issues presented by the protocol. Secure HTTP technologies and schemes are an attempt to address and resolve these security holes.
Taking Advantage of S-HTTP
Secure HyperText Transfer Protocol (S-HTTP) was developed to fill the gap of security in protecting sensitive information as it is transmitted over the Internet. As the need for authentication among Internet and Web grows, users need to be authenticated before sending encrypted files to each other.
S-HTTP will promote the growth of the electronic commerce as its transaction security features will promote a spontaneous commercial transactions. As S-HTTP allows Web clients and servers to be secured, the information exchanged among them will also be secured.
With S-HTTP, a secure server can reply to a request with a encrypted and signed message. By the same token, secure clients can verify a signature of a message and authenticate it. This authentication is done through the serverís private key, which is used to generate the serverís digital signatures. When the message was sent to the client, the server had delivered its public key certificate along with the signed message so that the client could verify the digital signature. The server can verify the integrity of a digitally-signed message send by a client through the same process of decrypting inbound messages from the client as well as encrypting outbound messages to the client.
You can encrypt data with shared, private or public keys. If data is encrypted with public keys, messages can be exchanged both ways and decrypted without the need for the clientís public key as the server implement a single server private key that is stored in a key database file, which is encrypted using the Webmasterís password.
The encryption and signature is controlled through a CGI script. It is the local security configuration files and the CGI scripts S-HTTP message headers that will determine if the server will sign, encrypt, both or none.
Unfortunately, S-HTTP only works with SunOS 4.1.3, Solaris 2.4, Irix 5.2, HP-UX 9.03, DEC OSF/1, and AIX 3.2.4.
Using SSL to Enhance Security
The Secure Sockets Layer (SSL) protocol was designed and specified by Netscape Communications with the objective of improving data security layered between application protocols such as HTTP, TELNET, NNTP, FTP, and of course, TCP/IP.
SSL features data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection.
This is an open, nonproprietary protocol, which was submitted by Netscape to the W3 Consortium for consideration as a standard security approach for Web browsers and servers. It has also been sent to the Internet Engineers Task Force (IETF) as an Internet Draft in the pursuit of having SSL standardized within the framework of the IETF.
SSLís main goal is to promote privacy and reliability between two communicating applications. The latest version, Version 3.0 of March 1996, supersedes the earlier version from December 1995.
Still, the bases of the protocol didnít change. It is a two layers protocol, relying, at the lowest level, on some reliable transport protocol, just like the HTTP protocol. This lower layer is called the SSL Record Protocol, which is used for encapsulation of various higher level protocols. One example is the SSL Handshake Protocol, which allows the server and the client to authenticate each other, as well as negotiate an encryption algorithm and cryptographic keys before any transmission.
The connection is private, the peerís identity can be authenticated using asymmetric or public key, and the connection is reliable: this are the three basic properties of SSL.
The main difference between SSL and S-HTTP is that the later is a superset of the Webís HTTP, very specific to the Web usage. The SSL protocol, however, sends messages though a socket. The whole concept of SSL can be summarized in a protocol that can secure transactions between any client and server that use the sockets layer, which involves about all the TCP/IP application.
As far as encryption goes, both SSL and S-HTTP can negotiate different types of encryption algorithms and key authentication schemes, but Netscape and Enterprise Integration Technology (EIT) both have licensed RSA Data Securityís toolkits to provide end-to-end encryption of messages, as well as key creation and certification.
Unfortunately, the future of electronic commerce and secure Web transaction can not rely in a multi-protocol security system. S-HTTP and SSL are not the same, nor work the same way. Fortunately, the Web Consortium is working hard to develop a unified security scheme that would include SSL and S-HTTP.
Moreover, these are not the only schemes been proposed. EINetís Secure Server, which uses Kerberos and other mechanisms, and the Shen proposal, suggest more comprehensive security than SSL or S-HTTP can offer, such as extensive use of Privacy-Enhanced Mail.
Be Careful When Caching the Web!
Caching can tremendously improve the performance of your Web service by ensuring that frequently requested files will tend to be stored in the local cache. However, if the file on the remote server is updated, an out-dated file will be retrieved from the cache by the user.
Also, those files can be retrieved by a remote user, revealing information that may not be for public or external users to read.
An HTTPD server can resolved this problem by looking at the date of the file on the remote server and comparing it with the one cached. The following is a typical cache log file recorded. It provides the domain name as well as the name of the machines:
In the future it may be possible to chain caches. The possibility in the long term of having institutional, metropolitan, national and continental caches are beginning to be considered.
Plugging the Holes: a Configuration Checklist
Here are few configuration checklist to help you out:
A Security Checklist
First of all, the best security checklist you can have is knowing what to check and when. The following is a list of resources on the Internet to help you keeping abreast with security issues arising everyday in Cyberspace. It can also get some free resources to help you enhance security at your site:
Novellís HTTP: Better be Careful
Novellís HTTP is known to have a very unsecured CGI script. If you are running a Novell Web server, you should disable the "convert.bas" CGI script it comes with.
Unfortunately, that script (the out of the box one!) allows any remote user to read any file on the remote server. How? Her it is the harmful code:
Novell will probably come up with a fix for this script, but as I write this chapter, to the best of my knowledge, no fixes have been provided. So make sure to disable the script when setting up you Novell HTTP!
Watch for UNIX-based Web Server Security Problems
History shows (see CERTís reports and Bulletin Advisories) that UNIX-based Web server have tendencies to breach security at:
Uniform Resource Identifiers (URI), are a group of extensive technologies for naming and addressing resources such as pages, services and documents on the web. There are a number of existing addressing schemes, and more may be incorporated over time.
Figure 4.1 shows the basic structure of URI which includes:
An Uniform Resource Locator (URL) is a sort of networked extension of the standard filename concept. An URL enables you to point to a specific file on a specific directory at any giving machine attached to the Internet or Intranet. Also, this file can be served though several different methods, such as HTTP, TELNET, FTP and so forth.
The following is an overview of some of the most common URL types, as described at the National Computer Security Associationsí site at University of Illinois (http://www.ncsa.uiuc.edu/demoweb/url-primer.html).
Suppose there is a document called "foobar.txt"; it sits on an anonymous ftp server called "ftp.yoyodyne.com" in directory "/pub/files". The URL for this file is then:
The top-level directory of this FTP server is simply:
The "pub" directory of this FTP server is then:
Gopher URLs are a little more complicated than file URLs, since Gopher servers are a little trickier to deal with than FTP servers. To visit a particular gopher server (say, the gopher server on gopher.yoyodyne.com), use this URL:
Some gopher servers may reside on unusual network ports on their host machines. (The default gopher port number is 70.) If you know that the gopher server on the machine "gopher.banzai.edu" is on port 1234 instead of port 70, then the corresponding URL would be:
To point to a Usenet newsgroup (say, "rec.gardening"), the URL is simply:
Once you are viewing a document located somewhere on the network (say, the document http://www.yoyodyne.com/pub/afile.html), you can use a partial, or relative, URL to point to another file in the same directory, on the same machine, being served by the same server software. For example, if another file exists in that same directory called "anotherfile.html", then anotherfile.html is a valid partial URL at that point.
This provides an easy way to build sets of hypertext documents. If a set of hypertext documents are sitting in a common directory, they can refer to one another (i.e., be hyperlinked) by just their filenames -- however a reader got to one of the documents, a jump can be made to any other document in the same directory by merely using the other document's filename as the partial URL at that point. The additional information (access method, hostname, port number, directory name, etc.) will be assumed based on the URL used to reach the first document.
Another form of threat that makes harder for a firewall to protect a Web site involves Common Gateway Interface (CGI) scripts. Many Web pages display documents and hyperlink them to other pages or sites. However, some have search engines that will allow you to search the site (or sites) for particular information. This is done through forms that are execute by CGI scripts.
Hackers can modify these CGI script to do things it really ought not to do. Normally, these CGI scripts will only search into the Web server area, but if you modify it, it can search outside the Web server. To prevent it from happening you will need to set these scripts with low user privileges, and if you are running a UNIX-based server, make sure you search for those semicolons again.
There are many known forms of threats and many more of unknown ones. In the next sections you learn about some of the most common and threatening ones.
Further, the open architecture of Web servers allows for arbitrary Common Gateway Interface (CGI) scripts to be executed on the serverís side of the connection in response to remote requests. Any CGI script installed at your site may contain bugs, and every such bug is a potential security hole.
The same goes for Web server software, as more features they have greater is the potential for security holes. Servers that offer a variety of features such as CGI script execution, directory listing in real-time and script error handling, are more likely to be vulnerable to security holes. Even security tools widely used are not guaranteed to always work.
For instance, right before I started writing this book, two present events come to mind. First, is about the well known Kerberos system, widely adopted for security in distributed systems, developed at MIT in the mid-1980s. The people from COAST, at Purdue University, found a vulnerability in current versions of the Kerberos. Couple students, Steve Lodin and Bryn Dole, and the professor Eugene Spafford, discovered a method where someone without privileged access to most implementations of a Kerberos 4 server could break secret session keys issued to users, allowing unauthorized access to distributed services available to a user without even knowing that userís password. They were able to demonstrate it in a record time of less than 1 minute, on average, using a typical workstation, and sometimes as quickly as 1/5 second!
Another example is Netscape, where versions 2.0 and 2.01 were vulnerable to a "malicious" Java applet being spread over the Internet, according to a story on the New York Times of May 18. This applet, although a bit annoying, could cause denial-of-service, which potentially could cause also loss of unsaved edits in a word processor, or erratic behavior of application if you, in a verge of panic decided to reboot your machine instead of just killing your browser.
However, keep in mind that denial-of-service applets are not viruses, which are created with malicious intentions. True, this Java bug had the capability to execute instruction over the Web server, remotely, with the ability even to upload information from within the remote Web server, but the security breaches that have gotten so much press were fixed in JDK 1.0.2, their current release, and in NN3.0b4.
In the interim, Netscape users were instructed to disable "Java" and "Java script" dialog box to prevent the browser from receiving such applets, or upgrade to version 2.02, which supposedly resolved the problem.
Another example you should be aware of is the existing vulnerability in the httpd servers provided by NCSA and the Apache organization. According to the Computer Incident Advisory Capability (CIAC), an user can potentially gain the same access privileges as the httpd server. This security hole not only applies to UNIX servers but to all serverís platform capable of running httpd. If you are running an NCSA httpd, you should upgrade it to version 1.5.1, its latest version.
The problem with the Apache httpd CGI is no different: a hacker could easily enter arbitrary commands on the server host using the same user-id as the user running the httpd server. If httpd is being run as root, the unauthorized commands are also run as root! Since he is using the same user-id, he can also access any file on the system that is accessible to the user-id that is running the httpd server, including but not limited to destroying file contents on the server host.
Further, if he is using an X11-based terminal emulator attached to the httpd server host, he can gain full interactive access to the server host just as if he were logging in locally.
If you are using Apache httpd, this is what you will need to do:
It is very important that you run the upgrade as if let alone, this security hole can lead to a compromise of your Web server.
The same goes for CGI scripts with Novell platforms. The challenge involved with the implementation of CGI gateways on Novell-based platforms is due to the overhead involved in spawning NLMs and implementing language compilers or interpreters that reside and launch on the NetWare server. In order to resolve this problem, Great Lakes will allow data from the Web client to be either stored in a file on the NetWare server or transmitted as an MHS or SMTP E-mail message.
The NT version of both Netscape Communications Server version 1.12 and the Netscape Commerce Server, also are affected by CGI scripts handling. The following are two known problems:
Unfortunately this technique opens a major security hole on the system as it allows a remote user to execute an arbitrary set of Perl commands on the server by invoking such scripts as /cgi-bin/Perl.exe?&-e+unlink+%3C*%3E, which will cause every file in the serverís current directory to be removed.
There is another suggestion on Netscapeís technical note to encapsulate the Perl scripts in a batch (.bat) file. However, be aware that there is also a related problem with batch scripts, which makes this solution unsafe.
Both Purveyor and WebSite NT servers, because of EMWACS, use NTís File Manager extension associations, allowing you to execute Perl scripts without having to place Perl.exe into cgi-bin. This bug does not affect these products.
If you try to call it as /cgi-bin/test.bat?&dir you will get the output of the CGI program, followed by a directory listing! It is like the server is executing two functions here, running the batch file test.bat and running a directory (ĎDIRí DOS Command) list, which the command interpreter is handling in the same way Ď/bin/shí would (run it, then, if okay, run dir command).
A possible solution for this problem would be to wrap the batch file in to a compiled executable (.exe) file. The executable file would first checks the command line parameters for things that could be misinterpreted by DOS, then invoke a command.com subshell, and run the batch file.
This would require some extra work. You probably would be better off to do everything in compiled code. Again, if you are using this version, you definitely should upgrade it. You can easily do so by accessing Netscapeís Web page at URL: http://www.netscape.com.
Also, keep in mind that there are several CGI script that allow users to change their passwords online. However, none of them have been tested enough to recommend. If you want to allow your users to change their passwords on-line, some sites have set up a second HTTP server for that sole purpose. This second server sort of replicate the password file.
Further, if you have an FTP daemon, even though generally you would not be compromising data security by sharing directories between this daemon and your Web daemon, no remote user should ever be able to upload files that can later be read or executed by your Web daemon. Otherwise, a hacker could, for example, upload a CGI script to your ftp site and then use his browser to request the newly uploaded file from your Web server, which could execute the script, totally by-passing security! Therefore, limit ftp uploads to a directory that cannot be read by any user. More about this is discussed on chapter 8, "How Vulnerable are Internet Services."
Evidently, your Web servers should support the development of application gateways, as it is essential for communicating data between an information server--in this case a Web server--and another application.
Wherever the Web server needs to communicate with another application, you will need CGI scripts to negotiate the transactions between the server and an outside application. For instance, CGIs are used to transfer data, filled in by a user in an HTML form, from the Web server to a database.
But if you want to preserve the security of your site, and you must, be alert about allowing your users to run their own CGI scripts. These scripts are very powerful, which could represent some risks for your site. As discussed earlier, CGI scripts, if poorly written could open security roles in your system. Thus, never run your Web server as root; make sure it is configured to change to another user ID at startup time. Also, consider using a CGI wrapper to ensure the scripts run with the permissions and user id of the author. You can easily download one from URL: http//www.umr.edu/~cgiwrap
CGI are not all bad! A good security tool to control who is accessing your Web server is to actually use CGI scripts to identify them. There are five very important environment variables available to help you do that:
Also, CGI can be used to create e-mail forms on the Web. There is a CGI e-mail form, developed in Perl by Doug Stevenson (firstname.lastname@example.org), of Ohio State University, that is fairly secure. The script, called "Web Mailto Gateway," enables you to hide the real e-mail addresses from user, which helps to enhance security. The following source code can be found at URL: http://www.mps.ohio-state.edu/mailto/mailto_info.html.
If your server can run CGI scripts and is configured with sendmail, this is the right, and secure, mail gateway script to have in your HTML, you will need to be able to run CGI scripts on your server though.