Chapter 11: Server-side Security

After having looked at client-side security issues in the previous chapter, we now elaborate on security issues related to the server side. Remember from the Preface that most server-side security problems and corresponding exploits that make press headlines are due to software bugs and flawed configurations of Web servers. Consequently, if one really cares about the security of the server side, one has to start with a proper installation and configuration of the Web server software. Because there are many books and manuals that give step-by-step instructions about how to properly install and securely configure a specific Web server, we are not going to repeat them in this book. For example, you may refer to [1, 2] for a general overview, or [3, 4] for more specific information about the Apache Web server.

In the recent past, it has become popular to design and build multitier Web-based applications to make the user s experience more interesting and interactive. In fact, there is an increasingly large number of acronyms that refer to the same idea but use slightly different technologies. The aim of this chapter is to put these technologies into perspective, and to discuss their security implications. After a short introduction in Section 11.1, we elaborate on CGI, server APIs, FastCGI, SSIs, ASP, and JSP in Sections 11.2 to 11.7 (the acronyms are explained in the corresponding sections). We conclude with some final remarks in Section 11.8.

11.1    Introduction

As already mentioned in the introductory chapter of this book, HTTP is a very simple request/response protocol that can be used by a client (i.e., browser) to retrieve some information from a Web server. The requested information, in turn , is represented by static or dynamically created Web pages (written, for example, in HTML or XML).

• If the information is represented by static Web pages, the situation is comparatively simple and the Web pages can be directly retrieved from the server s document tree.

• If, however, the information is represented by dynamically created Web pages, the situation is more complicated and the pages must be generated by a specific application program in response to an incoming HTTP request message. In this case, the application program must be invoked by or communicate somehow with the Web server.

Obviously, the second possibility is much more powerful and is at the core of a multitier Web-based application architecture as illustrated in Figure 11.1. In this architecture, a user employs a browser to access a Web server (sometimes also called a Web frontend) and to request specific functionality. The Web server, in turn, interacts with an application server to provide this functionality. The browser and the Web server usually employ HTTP or HTTPS to communicate, whereas the Web server and the application server may employ any application protocol to communicate. ^[1] In a typical setting, the browser would be located on the Internet, the Web server would be located on a firewall s DMZ, and the application server would be located on the intranet.

Figure 11.1: A multitier Web-based application architecture.

The major advantage of a multitier Web-based application architecture is that normal browsers can be used on the client side. This is in contrast to traditional client/server applications that require (a) clients and servers to use a specific application protocol, and (b) specific client software to be distributed, installed, configured, and maintained . In practice, requirement (b) is particularly challenging and difficult to address on a large scale. Unfortunately, there are also some security problems and challenges related to multitier Web-based application architectures. For example, in the typical setting mentioned above, it is usually difficult to design and properly implement a firewall that is able to proxy the application protocol between the Web server and the application server in a sufficiently secure way. Most of the security problems and challenges, however, are due to the fact that the Web server (together with the application server) may be misused to do things other than what it was originally designed for. Because the Web server provides more functionality (than to simply return static Web pages), this functionality can also be attacked . The probability that this functionality is vulnerable and may be exploited primarily depends on the technology in use to dynamically create the Web pages.

Historically, the first technology to dynamically create Web pages was the Common Gateway Interface (CGI) and programming or scripting languages that made use of it. CGI was first implemented in the NCSA server and has many benefits, such as simplicity, language and architecture independence, process isolation, and the fact that it is specified as an open standard. From a security point of view, process isolation is particularly important, because it means that applications run in separate processes, and that buggy application server software may not crash the entire Web server or access the server s internal state information. CGI, however, also has some significant drawbacks and problems. One of the more important problems is performance. Since a new process is created for every HTTP request message and thrown away when the request is served , efficiency is fairly poor.

In response to the performance problem of CGI, some vendors designed and developed proprietary application programming interfaces (APIs) for their Web server software. In fact, the most important server APIs are NSAPI from Netscape Communications, ISAPI from Microsoft, and the Apache Web server API. ^[2]

Applications linked into a server API may run significantly faster than CGI scripts. In fact, the CGI initialization problem is improved, because the application runs in the server process and is persistent across requests . On the other side, however, Web server APIs also sacrifice many benefits of CGI. In fact, they are more complex, proprietary, tied into the server architecture, and programs must be written in a language supported by the API. Most importantly, Web server APIs do not provide process isolation (as discussed above). Since the applications run in the server s address space, buggy or maliciously written application program code may compromise the security of the Web server as a whole. This can also be used to attack other application programs.

Given the advantages and disadvantages of both CGI and vendor-specific APIs, the FastCGI interface was developed and proposed as a viable solution. Contrary to CGI, FastCGI processes are persistent and the Web server may use TCP connections to communicate with the FastCGI script (instead of environment variables and a mechanism for interprocess communication). Furthermore, there are many other technologies that have been designed, developed and marketed in the past. For example, Server-Side Includes (SSIs) are directives that are directly executed by the Web server. Similarly, Microsoft is pushing a technology called Active Server Pages (ASP) and Sun Microsystems is pushing a similar but more open technology called JavaServer Pages (JSP). All of these technologies work in similar ways and have similar security problems. They are overviewed, briefly discussed, and put into perspective next .

^[1] Following the current trend in industry, the application server is likely to have a Web services interface. In this case, the Web server and the application server may also use HTTP and HTTPS to communicate.

^[2] Further information about the Apache Web server is available at http://www.apache.org. Its API is, for example, overviewed in Chapter 14 of [4].