Chapter 5
Information security services of a web server in a
virtual web database environment
5.1 Introduction
Web servers are commonly used as universal portals to network services and applications. They manage web pages containing HTML, scripts, Java applets, ActiveX controls, XML, dynamic HTML, images and other content.
The web server is at its simplest a program that runs continuously while “listening” to a network port. The web server intercepts the user’s HTTP requests to the virtual web database environment, as shown in figure 5.1. The web server will initially present the user with the home page of ABC Bids, allowing the user to further request another page. If the user requests to see a listing of all auctions, the web server requests the application server to process the request by invoking components containing business logic. A response is sent back to the web server after an appropriate action, such as reading a database table in the database server, has been taken. The web server then sends the processed information back to the client.
HTTP Client
ODBC
Figure 5.1: A web server in a virtual web database environment
When web servers are installed, numerous services such as FTP, WWW, mail and telnet may be running by default. Other features, such as the ability to enable directory listings or the ability to enhance functionality with CGI scripts and API interfaces, may make a web server vulnerable to attack. [STEI00] A web server that does little more than make static files available for requests is safer to use, since there are less vulnerabilities that can be exploited. The web server
ABC Bids VIRTUAL WEB DATABASE ENVIRONMENT
OS ACLs Web server HTML XML ASP/JSP CGI WWW, mail, FTP, telnet, news
apps
Apps InternetOS ACLs Application server
OS ACLs Database server
administrator should therefore ensure that the web server is configured to be as secure as possible by disabling or configuring these features and services.
Web servers support various security features such as LDAP directories for user and group management, transport layer security with SSL, various ways of performing password authentication, smart cards, digital certificates and support for integrated certificate servers. A comparison has to be made, to determine which product will best suit the security requirements of the virtual web database environment.
Because the web server is the entry point to the virtual web database environment of ABC Bids, it is very attractive to hackers. A company such as ABC Bids cannot consider going online before securing the web server. The remainder of this chapter will address web server information security services in terms of the information security services and mechanisms used to investigate current state-of-the-art database security identified in chapter 3. Additional web server security mechanisms that were not addressed may be identified. The web server information security threats can then be reviewed to see if they have been addressed.
5.2 Information security services of a web server in a virtual web database environment
The information security services that were used to discuss and investigate current state database security are identification and authentication, authorization, confidentiality, integrity, audit, availability, manageability, assurance and physical security. It now needs to be determined how these services and mechanisms can successfully be employed in a web server environment. Each of these information security services can be described with reference to the ABC Bids case study.
• Identification and authentication
The web server must identify and authenticate members who submit requests to access protected HTML pages or scripts on the ABC Bids web server.
• Authorization
The members of ABC Bids may only see HTML pages, or execute scripts for which they have been authorized.
• Confidentiality
Credit card details supplied by members must stay private during transmission from the client browser to the web server, and beyond.
• Integrity
The message received by the web server must be the same as that sent by the customer. Integrity of the web server software must be maintained.
• Audit
The web server must keep track of all requests and administrative changes made by all users of the web server to ensure accountability.
• Availability
The web server of ABC Bids must be able to continuously process the requests that are sent to it by users.
• Manageability
Administrators must be able to easily configure and manage the security of the web server.
• Assurance
The web server software must be assured to operate at a high degree of confidence.
• Physical security
The web server must be protected from theft, natural disasters and malicious damage.
Each of the above security services needs to be further explored to determine how the security of the web server could enhance the security of the virtual web database environment of ABC Bids. At the end of each service, state-of-the-art products will be reviewed to show how implementation can be done.
5.2.1 Identification and authentication
Large numbers of requests made to web servers are done anonymously and do not have to be authenticated. For requests that need authentication, the web server can be configured to do so. The following methods can be used:
• Password authentication is the most popular, but also the least secure method of authentication because of poor password management. Username and password pairs can
be created in the operating system or LDAP (lightweight directory access protocol) directories. [BAO01] LDAP is an open directory access protocol that runs over TCP/IP and is scalable to millions of entries.
Web servers commonly employ basic authentication, where the user is prompted for a password and it is sent in clear text to the web server. This can be improved considerably by encrypting the password while it is transmitted. If browsers have the ability to calculate a hash of the password, digest authentication can be used. The browser does not send the password, but rather a calculated hash of the password to the web server. The hash is compared to a hash calculated by the web server on the password that it has. If both hash values are the same, the user is authenticated without password transmission. This feature is included in the HTTP 1.1 specification [INTE01] and will be used more commonly in the future.
Application developers who try to keep their web applications platform-independent may decide against the use of operating system password authentication mechanisms. Username and password pairs might be kept in user databases where the passwords are sometimes encrypted. This method is not safe, since these types of files could easily be compromised. For instance, a user performing numerous unsuccessful login attempts will not be audited or locked out, as would a user performing the same actions against operating system password authentication mechanisms.
Passwords represent “what you know” and can be improved significantly by a two-factor authentication – “what you have”.
• Digital certificates allow the web server to query the client browser for a certificate, which will identify the client uniquely and safely. A certificate consists of data that specifies the name of an individual, company, or other entity. Public key encryption is used to authenticate the client and web server to each other. The client can also authenticate the web server to ensure that it is not dealing with an imposter web site. The only problem is that certificates identify clients and not users and are therefore not suited to users using multiple computers. Users also need to protect their machines containing the certificates, so that they cannot be used unlawfully. These certificates can be mapped
to user accounts on the operating system or LDAP directories to simplify security administration. A web server such as that of ABC Bids will not be able to employ digital certificates as a way to authenticate members, since the users of these web sites do not generally possess certificates. It would be more suited to a closed group of employees on an intranet or extranet where certificates can be issued to each employee.
• Smart cards are highly secure but require special hardware and software to be installed on the network. They are therefore suited to a closed group of users on an intranet or extranet and not to a web site such as that of ABC Bids.
• Secure cookies provide authentication and can be address-based, password-based or digital signature-based. [PARK00] They are constructed using well-known cryptographic techniques when issued by the web server. Cookies that are not encrypted may become vulnerable, since they are under the control of the end-user. They may also be tampered with as they move across the network.
Because HTTP is a stateless protocol it does not remember user interactions from request to request. The web server should maintain secure session state for a user when a number of pages are requested in succession, to avoid user re-authentication. There are various ways of maintaining secure session state. State can be maintained either stateless or stateful.
Ø Stateless: The web server application will maintain state by storing session data in a common repository such as a database, or in cookies.
• Cookies are small text files that contain information about the user and are saved on the user’s hard drive via the browser. When the user returns with the next request, the web server retrieves the cookies with information such as authentication data. A problem is that users may disable cookies on the browser if they feel concerned about their privacy.
• Session data stored in a database allows session state to be maintained across more than one web server instance and for a longer period than the duration of the session. This database will have a high availability requirement.
Ø Statefull: The web server application will maintain state by storing session data within its runtime environment between client calls. This forces all subsequent requests to flow through the exact same path.
• Session data stored at the server is used for the duration of a user session for a specific web server instance. Because session variables use memory on the web server, they have to be used carefully. These variables are only valid for the duration of the session.
It is vital that all members of ABC Bids be identified and authenticated correctly by the web server of the virtual web database environment. The identification and authentication mechanisms employed by ABC Bids should be secure, simple to use and should scale to a large user population. The authentication mechanisms employed should ideally be able to provide a security context for the member’s request as it is processed at the application server of the virtual web database environment. A solution would be to use password authentication with operating system or LDAP directory user accounts, and to encrypt the password as it is transmitted. This method can be made more secure by storing encrypted and/or digitally signed authentication data in cookies at the member’s machine or in external databases for the duration of the member’s session.
It is clear that the web server provides this service at a more sophisticated level than stipula ted in the current state of database security discussed in chapter 3. There are various additional mechanisms that can be employed to ensure proper identification and authentication of clients as shown in table 5.1.
Table 5.1: Additional web server authentication mechanisms Legend: DB= Database security WS= Web server
Database security service Mechanism Employed by
Identification and authentication
Database authentication and password policy DB Operating system authentication DB WS Others (DCE, Kerberos, trusted client, etc.) DB WS
LDAP directories WS
Digital certificates WS
Smart cards WS
Secure cookies WS
Product review – identification and authentication
Web servers can authenticate users with passwords, digital certificate, smart cards or cookies. For example, iPlanet Web Server stores usernames and passwords in a directory server such as iPlanet Directory Server 5.0, which support LDAP. Digital certificates can be used as proof of identity and verified to certificates published in the LDAP directory.
5.2.2 Authorization
Current state database security provides discretionary, mandatory and role -based access control policies as ways of restricting access control. Of these, the web server supports discretionary access control. An attempt at RBAC, as well as other authorization implementations will also be considered.
a) Discretionary access control (DAC)
Usually, the system administrator who has super-user privilege installs the web server. He/she becomes the owner of the files and can grant access to other users or groups of users with access control lists (ACLs). Authorization to web server resources such as configuration files, log files, administrative files, static HTML files and CGI, ASP or JSP scripts needs to be done explicitly for users or groups of users. Authorization can be based on the identity of the user making the request, the IP address of the host making the request, the time of day, as well as the type of connection used. Web servers that employ LDAP directories can also set access control globally for all resources when several web server instances are used at the same time.
Anonymous access, the most common web server access control mode, allows anyone to visit the public areas of the web server, while preventing unauthorized users from gaining access to the web server's critical administrative features and private information. Otherwise, the web server can allow authorized access. Web pages that are restricted will be viewed, run or manipulated by all users in the same way. For instance, “anyone” may be permitted to read, list, or execute all icons and images, but not write or delete.
Access is granted or denied to the front-end of an application at web server level by granting access to a specific web page. Access control will need to be further refined in
the application server within the virtual web database environment to control user authorization.
b) Role-based access control (RBAC)
As web server authorization is implemented with a DAC policy, where individuals are assigned permissions, it becomes unmanageable in the face of very large user communities. RBAC is a policy that would be better suited to such an environment. [JOSH01] The NIST (National Institute of Standards and Technology) have initiated an effort to enable commercial web servers to employ RBAC, called RBAC/Web. [FERR99] Because of the increased functionality, RBAC can require more processing than ACLs when sessions are established and permissions enforced. This may make it more suitable to be used in intranets or extranet where the numbers of users are limited.
c) Other authorization implementations
Various efforts have be en made to improve web server authorization and to provide a virtual web database environment with single sign-on capabilities. Policy-based authorization servers or other authorization products can be used. Very often, these implementations introduce other problems such as higher cost, extensive initial development, modification of the browser, or increased administration. Their implementation should be carefully considered.
Ideally, authorization to the web server resources of ABC Bids should scale to the large user communities that will access it. A very simple form of RBAC can be implemented through ACLs, by grouping users into groups such as “members” and assigning permissions to groups. Access can then be granted to users, based on their membership of a group. As the right to assign members to groups is considered as non-discretionary, a measure of security can be achieved.
It is clear that the authorization service at the web server lacks the control exercised by the authorization service in the current state of database security discussed in chapter 3. Web server RBAC would be ideal, but this method is not available with current commercial web servers. Table 5.2 shows web server authorization mechanisms.
Table 5.2: Additional web server authorization mechanisms
Database security service Mechanism Employed by
Authorization Policies:
DAC policy ACLs DB WS
MAC policy Bell-LaPadula, RBAC DB
RBAC policy RBAC DB
Other: Authorization implementations WS Product review – authorization
Web servers will allow the administrator to set ACLs to control access to resources in various ways. For example, Microsoft IIS [INTE01] protects web server resources such as web pages with permissions that specify which Windows 2000 users or groups of users may access web pages or scripts. Web server permissions are further applied to ensure that all users view or execute the page in the same way. By contrast, iPlanet web server only uses LDAP directories to control access to resources, which makes it more independent of the operating system. Policy-based authorization servers such as Netegrity and Securant [SNYD00], or implementations such as TrustedWeb [NIXD98] or getAccess [ENCO98] can be used. For instance: getAccess is a product that supports role -based access control through encrypted cookies for intranets or extranets. These cookies are valid for the duration of a user session.
5.2.3 Confidentiality
Members of ABC Bids will at times transmit sensitive data such as passwords or credit card details to the web server in the virtual web database environment. This transmission occurs over open public lines. If electronic snoops were to “eavesdrop” on this connection, they would be able to copy every byte of data transmitted. Transmission from the web server to the application server must also be protected. Confidentiality can be achieved by encrypting communications between a browser and web server. The most common way of doing this is to establish a secure connection using a variation on HTTP called the Secure Sockets Layer (SSL). [NETS01]
The SSL protocol supports the use of a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates and establishing session keys. Decisions about which cipher suites a particular organization decides to enable depend on trade-offs between the sensitivity of the information involved, the speed of the cipher and the applicability of export rules. The SSL
protocol uses a combination of public key and symmetric key encryption. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the web server to authenticate itself to the client using public key techniques, and then allows the client and the server to co-operate in creating symmetric keys used for encryption, decryption and tamper detection during the session that follows. All traffic between an SSL web server and SSL client is encrypted using a unique session key. The server’s key pair is used to encrypt the session key itself when it is passed to the client.
By employing SSL, the password of a member will reach the web server confidentially. Once this data is on the web server, its confidentiality needs to be protected further. Sensitive data such as passwords or credit card details should be stored encrypted, and not within the confines of the web server directories.
Since secure web communication requires more resources than non-secure web communications, the SSL protocol should be used carefully. The home page or a “search results” page will not need to be sent encrypted to the client, whereas a page where credit card information is entered and submitted to the web server should. Remote administration of a web server involves the exchange of sensitive information, such as the password for the administrator's account, and should also be encrypted with SSL.
Confidentiality of information should further be protected from inferences that can be drawn by members. Members will be able to run specific queries from the web server interface provided. This interface should be designed in such a way as not to allow inferences to be drawn from non-sensitive data. Members should for instance not be allowed to access the average of bids made on an item. If all bids were displayed, they would be able to infer the highest bid amount placed, if there is only one.
Finally, administrators of the web server of ABC Bids should be sensitized to situations where social engineering can be employed to access sensitive information such as passwords. No confidential information should be shared with others who do not have the authority to have it.
Web server confidentiality can be implemented to the same level as stated in the current state of database security discussed in chapter 3. The web server of ABC Bids could employ encryption to keep, for instance, passwords confidential, but normally sensitive data should be stored elsewhere. Application code that is sensitive could be encrypted. Encryption could rather be employed, as shown in table 5.3.
Table 5.3: Additional web server confidentiality mechanisms
Database security service Mechanism Employed by
Confidentiality
Encryption DB WS
Inference control DB WS Employee training DB WS SSL (encryption) WS
Product review – confidentiality
Web servers employ encryption to prevent snooping and the processing of these functions can be enhanced by hardware. For example, both Microsoft IIS and iPlanet web server support Secure Sockets Layer (SSL) 3.0, which provides a secure way to exchange information between clients and web servers. Both support FORTEZZA [RSAS01], an encryption system used by US government agencies to manage sensitive but unclassified information. It provides a hardware implementation of two classified ciphers developed by the federal government: FORTEZZA KEA and SKIPJACK. To aid in the overhead of encryption, the SSL-100 acceleration device from Avaya can be used. [AVAY01]
5.2.4 Integrity
The integrity of the web server concerns the message that is sent between the client and web server, as well as the web server and application server. Furthermore, the integrity of the web server software needs to be protected from attacks that exploit vulnerabilities, and viruses and Trojan Horses.
The message sent from the client to the web server must be protected against corruption and tampering. An SSL session between client and web server provides data integrity using a message authentication code (MAC) such as MD5. If someone in the transmission path has corrupted the message, this can be detected. MAC encryption is based on the private key and a part of the message itself.
Messages that are sent to the web server can be malicious of nature. To protect the integrity of the web server, a firewall and signature-based network intrusion detection can be implemented, as a perimeter defense. Firewalls can prevent certain kinds of data from entering network where the web server is exposed, such as scans and probes, or malicious attacks against services. Unfortunately, attacks on the web server can be sent via HTTP requests. This traffic will be captured by the firewall and its parameters analyzed. As the data portion of the message cannot be analyzed, a malicious message can look legitimate. Such a message can be passed to the web server, where it might exploit a vulnerability that it finds there. [FRAN01]
Real-time network intrusion technologies are a second line of defense behind firewalls with the sole purpose of detecting unusual or abnormal activity. This can allow the administrator to respond to any problems and by so doing protect the integrity of the web server software. As signature-based comparison methods are used to detect and report suspected attacks in real-time, it will always be one step behind the attackers.
These perimeter defense methods cannot protect the web server from attacks from outsiders, and even more so from ins iders. It then becomes important to concentrate on the integrity of the web server software, to minimize exploits. Web server software is becoming increasingly complex as more and more functionality is added. This inevitably results in vulnerabilities in the software that can be exploited by hackers. For example, between 1998 and 2000 about 50 web server attack techniques were created that exploited IIS [INTE01] vulnerabilities. [FRAN01] It is therefore important that all security patches released by vendors be applied as soon as possible. Hackers count on users not doing this and they search for these known vulnerabilities. The integrity of the web server can be protected further by keeping it virus-free and installing the latest virus detection software.
Maintaining a proper configuration of the web server is very important. For instance, it should be ensured that the web server does not run under the privilege of the administrator’s account and that directory listing is turned off. All services and ports not used on the machine must be disabled. The web server must be protected from default CGI scripts and SSI (server side includes). To prevent SSIs from being exploited, they can be turned off altogether. [GOSH01]
Vulnerable CGI programs present a particularly attractive target to intruders because they are relatively easy to locate and operate with the privileges and power of the web server software itself. [SANS01] CGI scripts should be carefully controlled and accounted for before they are used to compromise the integrity of the web server. All scripts could be put into one directory, which is protected and under administrator control, and a hash function can be used to ensure that they are not modified before they are run. Some machines have operating systems such as Sun Microsystems' Trusted Solaris 8 [BIGG01] with built-in check-summing functions where files such as system executables and CGI scripts can be included in what is called the trusted computing base (TCB). Periodic checks can then be scheduled to perform these functions. [GOSH98]
The current state of database security discussed in chapter 3 does provide a proper set of mechanisms that can be utilized by the web server to protect its integrity. In addition, the message is protected from tampering as it is moved from the client to the web server or from the web server to the application server. Table 5.4 shows additional integrity mechanisms that can be added to web server security mechanisms.
Table 5.4: Additional web server integrity mechanisms
Database security service Mechanism Employed by
Integrity
Database integrity Checksums DB WS
Virus and Trojan Horse protection DB WS Patch vulnerabilities DB WS Proper configuration DB WS SSL (checksum) WS Firewalls WS Intrusion detection tools WS Operational integrity Transaction processor DB
Semantic integrity Entity integrity DB
Referential integrity DB
Domain integrity DB
User-defined integrity DB
Normalization DB
Product review – integrity
Web servers need to protect integrity with a wide range of mechanisms. Both Microsoft IIS [INTE01] and iPlanet web server [IPAD01] support SSL 3.0, which includes integrity checking of the message sent between client and server. Furthermore, a tool such as Netscape Signing Tool 1.1[NESI01] can be used to ensure the integrity of web server scripts. Internet scanner tools [ISSY01] from, for instance, Internet Security Systems (ISS) will pick up any vulnerability that might exist within the web server. Web sites such as Cassandra [CASS01],
CERT [CERT01] and SANS Institute [SANS01] can be used by the administrator to monitor security vulnerabilities. Other options include us ing an open-source web server such as Apache [APAC01], which has experienced few publicized bugs and vulnerabilities and has a reputation for being secure. [BAHA01]
5.2.5 Accountability
One of the maxims of security is, "Prevention is ideal, but detection is a must." [SANS01] An audit policy can stipulate that the web server keeps a log of all requests to and from it, as well as administrative changes that occur. This information can be used to determine whether any unauthorized accesses are being made to the web server, and can ensure user accountability.
Web server log files grow extremely quickly since each line in the log file is a separate request for an URL. Redundant data is always present in web server log files, since a single hit generates a record of not only the original URL, but also of every graphic found on that page. Users may be accessing many pages, typically across various web server instances that may be used simultaneously, each with their own log files. Because of this, log entries are often ignored.
A number of choices can be made to determine what is logged, such as the username, date/time, URL requested and cookie. Nearly every web server records into some recognizable variant of the following logs: [TITT01] [STEI98]
• Access log: This records all file transfers from the web server to the clients who request information. It shows which files are accessed most frequently and which files are never accessed. The access log can give valuable clues if the web server is being probed for an attack. Because it is very large, it can be reduced by eliminating all successful accesses as well as accesses made to the unrestricted parts of the web server. Status codes 401 (unauthorized) and 403 (forbidden) may indicate unlawful activity and need to be analyzed. Requests for very long URLs or URLs with odd characters may indicate suspicious activity.
• Error log: Whenever requests cannot be honoured, an HTTP error code is recorded, along with other information about the request that produced the error code for errors
such as a file not found, broken connections, or timeouts. All error log activity should be monitored. For instance, an error such as “password mismatch” may indicate an attempt to gain unauthorized access.
• Referrer log: This log keeps track of where users of the site come from. This log has the potential to leak information from one site to another. For instance, if a customer fills in an HTML form with credit card details, and sends it with “Method = GET” to the merchant, the credit card number will appear on the referrer field in the log entry of the next web server visited.
• Agent (or user agent or user) log: This log keeps track of the software that is making HTTP requests to the web server. The user agent name recorded in this log can point to some web browser name and version.
A raw log file entry looks something like this:
206.135.203.174 - - [11/Jul/2001:00:00:04 -0600] "GET /studio/drives.html HTTP/1.1" 200 20607 "http://www.ABCBids.com/studio/hard.html" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
These log files are difficult to read and log analysis software can be used to analyze log data meaningfully.
Hackers will always try to clear their tracks when accessing a web server unlawfully by removing log entries. Log files should be protected under the administrator’s account and could even be stored on another machine. Backups should be encrypted and stored safely. Because of their size, log files should be cycled, with the most recent copies available. Older log files can be compressed and archived.
Administrators of the web server in the virtual web database environment should make regular checks for unusual patterns of activity by analyzing the access and error log with log analysis tools. To investigate security breaches or intrusion, the times on multiple instances of web servers used simultaneously should be synchronized. This will ensure that events that are written to log files are easy to compare. Operating systems logs can also be used to monitor activity.
When compared to current state database security accountability, discussed in chapter 3, this service is found lacking at web server level. Web server log files are not very specific and are
difficult to use because of the volume. A complication is the integration of the log files when multiple instances of web servers are used at the same time. Table 5.5 shows an additional mechanism that accountability should include.
Table 5.5: Additional web server accountability mechanisms
Database security service Mechanism Employed by
Accountability
Audit DB WS
Integrate log files WS Log analysis tools WS Alert when security breach detected WS
Product review – accountability
Web servers allow administrators to configure various audit options to allow them to track the accesses and errors on their site. For example, the iPlanet web server [IPAD01] access log can log Hostname or IP address of client, Username, Date/time of request, Request, Protocol, Status code, and Bytes transferred. An error log file contains errors the web server has encountered since the log file was created, informational messages about the web server, such as when the web server was started, and unsuccessful user authentication. The log analyzer can generate statistics, such as a summary of activity, most commonly accessed URLs, and times during the day when the web server is accessed most frequently. In addition to logging errors to the web server error log, iPlanet Web Server logs severe system errors to the Event Viewer in Windows. Products such as WebTrends Log Analyzer [WEBT01] can be used to perform log file analysis.
5.2.6 Availability
When web server problems prevent members from accessing a revenue-generating web application such as ABC Bids, thousands of rands are lost per minute. Therefore, high availability is mandatory for a web server in a virtual web database environment. If ABC Bids becomes a very popular web site, load balancing can be used to ensure high availability. This will make the architecture of the virtual web database environment more complex to maintain, since more instances of web server processes may have to be managed. There are a number of ways to achieve load balancing. [HUGH01]
• DNS (domain name system) balancing: This allows the DNS lookup for an address to cycle through the multiple IP addresses of instances of the web server used
simultaneously. Thus clients receive IP addresses for web servers in a ‘round robin’ fashion. A disadvantage is that a request can be sent to a web server that is unavailable.
• Software/hardware load balancing: ABC Bids will publish one IP address for all multiple copies of web server instances that exist. A controller machine is then set up to intercept HTTP requests to this one IP address and to distribute them among all web server instances. This method distributes the requests more evenly across the web server instances than the DNS method. The controller can be informed that a web server instance is unavailable so no requests would be routed there.
• Reverse proxying: A reverse proxy intercepts requests from clients and then proxies those requests onto the web server, caching the response itself as it sends it back to the client. Load on the web server is reduced, because the proxy can serve content such as static HTML pages that all users may access from the home page of ABC Bids from its own local cache.
• Distributing content: Content such as pictures and video clips used by the user interface of ABC Bids can be distributed among several web servers and their links hard-coded. Service providers that specialize in hosting images, sound, multimedia and other large files for distribution can also be used to distribute content.
It is important to note that multiple web server instances used for load balancing can be given access to the application server. This will impact the security of the virtual web database environment since aspects such as authorization to various resources and audit done by each web server instance will become more problematic to manage. The security of the virtual web database environment will be as secure as the least secure web server instance. All web server instances should be given the same security configuration to ensure a secure virtual web database environment. In addition, it is difficult for the multiple web server instances to maintain state for a client session. Therefore, session data needs to be maintained stateless. A separate database can be used to which all web server instances will have access, allowing more than one path to be used to maintain state.
Boosting the resources available to the web server, such as disk speed, memory and CPU power, can increase availability. The more memory a web server has, the longer web pages and images can be cached in memory instead of read from the disk over and over again.
Finally, the web server should be backed up or mirrored to ensure that it can be restored quickly when the server data is corrupted or lost because of hardware or software malfunctioning.
The current state of database security identified in chapter 3 does provide some of the mechanisms that will ensure availability. Load balancing is a mechanism unique to the web server and can introduce difficulties in securing the web server, as shown in table 5.6.
Table 5.6: Additional web server availability mechanisms
Database security service Mechanism Employed by
Availability Hardware redundancy DB WS Backup DB WS Recovery DB WS Replication DB Contingency plan DB WS Load balancing WS Extended configuration WS
Product review – availability
There are various software and hardware approaches to enhancing availability. For example, the Microsoft Application Center 2000 [JOHN00] provides software-based clustering and load balancing. Caching products like those offered by CacheFlow [CACH01] can be used as a means of getting pages to their visitors faster. Load-balancing switches, such as Cisco LocalDirector, redirects TCP/IP requests to multiple servers in a server cluster providing a highly scalable and reliable solution.
5.2.7 Manageability
Creating a secure web server is a time-consuming process. As mentioned before, ACLs are used to authorize users to resources. These ACLs have to be set on a server-by-server basis. If numerous web server instances are used, it could be an error-prone process with a large administrative overhead. The integrity of the web servers have to be maintained by applying the same patches, configuring them all in the same way and controlling vulnerable scripts in the same way for each web server. All keys used with SSL have to be maintained safely. Furthermore, individual audit logs that are produced by each web server need to be integrated. Managing all these aspects without error will not be an easy task.
Tools are available that automate the management of the web server. This is especially helpful when multiple instances of web servers are used at the same time. Response time, availability and content of URLs, as well as alerts on access conditions can be monitored. These tools address an aspect such as availability and performance, but do not address the real security issues such as admin istration of authorization and integration of audit logs for multiple web server instances. Often, more than one tool is used to aid with management of security, and are not integrated with each other. These management tools can present a further vulnerability and should be maintained in a physically secured location to protect it from misuse.
The current state of database security identified in chapter 3 provides manageability as a service. Management tools are very important, since the web server is complex to maintain and configure. Table 5.7 shows that web server security management tools should be used to aid administrators when setting security.
Table 5.7: Web server manageability mechanisms
Database security service Mechanism Employed by
Manageability
Security management tools DB WS
Product review – manageability
To aid the administrator in managing the web server, vendors provide various products. For example Microsoft Application Center 2000 [JOHN00] uses the familiar Microsoft Management Console (MMC) snap-in to manage the availability of servers in a cluster. Server data is stored in Microsoft SQL Server [MSSQ01], and a variety of reporting and analysis options are possible. iPlanet has a server manager that allows the administration of multiple web servers and allows, for instance, ACLs and logs to be viewed through this interface. [IPAD01]
5.2.8 Assurance
The administrator of the web server of ABC Bids needs to determine to what extent the security of the web server of the virtual web database environment is assured. This is a task that will involve developers, as the application logic residing on the web server can be one of the most vulnerable components of the web server in a virtual web database environment. Application logic in scripts on the web server is used mainly to create the user experience as
the user moves from page to page. ASP and CGI scripts are invoked in response to users’ requests. Because these scripts can process untrusted user input, the security risks increase. Exploitations that developers should guard against are, for example, hidden field manipulation where hidden fields such as prices can be changed on HTML forms, parameter tampering which can allow web server files to be accessed unlawfully, and cookie poisoning which can allow one user to act on behalf of another.
Many of these problems can be avoided by designing the code with security in mind, validating input and doing thorough testing. A code review process should be in place for each script put into production.
To allow the administrator to have a measure of assurance in the security of the web server, the following can also be implemented. [RYAN01] Regular reviews of policies, practices and procedures should be done to ensure that the right people are getting access to web server resources. The web server software should often be assessed with vulnerability assessment tools to detect weaknesses that may exist. An independent third party should perform a technological penetration test to hack the web server from the outside. A social engineering penetration test should be performed to ensure that training and awareness programs have been implemented successfully. Finally, thorough tests should be done to ensure that all security configurations work as expected.
The current state of database security in terms of assurance is found lacking at the web server. There is no real assurance that the web server will operate at a high degree of confidence in terms of security, since web server software is not certified. The high number of incidents that spring from web server security vulnerabilities is proof of this fact. Table 5.8 shows additional web server mechanisms that can be employed to improve the assurance of the web server.
Table 5.8: Additional web server assurance mechanisms
Database security service Mechanism Employed by
Assurance
Certification DB
Test security configuration DB WS Penetration test WS Vulnerability assessment tools WS
Product review – assurance
Various vendors provide administrators with tools that will aid them in assuring the configurations of the web server. Internet Security Systems [ISSY01] can, for instance, check all services running, SMTP, operating system and browser version and information, NetBIOS Shares, accounts, passwords, security and auditing policies.
5.2.9 Physical security
The web server of ABC Bids should be physically secured to protect it from theft, malicious attack or natural disasters. The current state of database security in terms of the physical security service defined in chapter 3 can be successfully employed at web server level, with specific reference to the web server, as shown in table 5
.9.
Table 5.9: Web server physical security mechanisms
Database security service Mechanism Employed by
Physical security
Secure buildings and equipment DB WS
5.3 Web server information security services and the threats facing the web server of ABC Bids
A web server can be exploited as a launching pad into the corporation’s entire computer system. Once the web server is subverted, an attacker may be able to gain access to data and systems connected to the server at the local site. Examples of web server threats that can allow these exploits have been identified in chapter 2. These threats will now be revisited to see if they have been addressed by the security services and mechanisms, as discussed in this chapter. Table 5.10 shows all threats as well as the services that can address them. New mechanisms identified in this chapter is shown in bold.
Table 5.10: Web server threats and services that can protect against them
5.3.1 Network threats Service
1. An attacker may try to intercept sensitive details such as passwords or credit card details as they are sent between the different servers.
Confidentiality - By enabling SSL the password or credit card will be encrypted.
2. An attacker may try to change the data in a message as it is moved between the different servers.
Integrity - By enabling SSL, this will be prevented by an integrity check.
5.3.2 Web server threats Service
1. An attacker takes complete control of the server of ABC Bids by conducting a buffer overrun attack. The cause is the Internet Printing Protocol (IPP), implemented via an ISAPI extension that is installed by default. Vulnerability results because the ISAPI extension contains an unchecked buffer in a section of code that handles input parameters.
Integrity – Applying a patch and configuring the web server can prevent this.
Accountability – Audit can later reveal what happened. Log integration and analysis tools can aid to allow an alert of this condition.
Availability can ensure that the web server can be restored as soon as possible. Load balancing can ensure that some requests are processed. Assurance – performing penetration test can prevent this attack. Vulnerability assessment tools may detect this problem
2. An attacker manages to access the password file of ABC Bids and then tries to compromise accounts by cracking passwords. He/she then tries to gain root access to the web server through a cracked root password.
Authorization will ensure that this file is not accessible to unauthorized users.
Integrity through proper configuration will ensure that this file is not kept where it is accessible. Firewall and intrusion detection might detect and stop the intruder.
Confidentiality can ensure that the passwords are unintelligible by encryption.
Accountability - Audit will reveal the actions of the intruder. Log integration and analysis tools can aid to allow an alert of this condition.
Availability will protect the web server to be restored if the attacker should launch an attack and corrupt the web server.
Manageability will ensure that the file is managed properly.
Assurance- Proper testing and a penetration test might prevent this. Vulnerability assessment tools might detect the problem.
3. An attacker tries to "sniff" passwords and credit card numbers of members from within a web page. The web server is vulnerable to a cross-site scripting vulnerability. Malicious HTML tags or script (JavaScript, VBScript, Java, etc.) is/are inadvertently included in a dynamically generated page based on input, which is not validated, from untrustworthy sources.
Identification and authentication- Difficult to break passwords should be used.
Integrity will ensure that the web server is configured properly and that such a vulnerability is patched. Firewall and intrusion detection might detect and stop the intruder.
Confidentiality- SSL can be used to encrypt the pages as to make it unreadable.
Availability will ensure that proper action is taken when it is discovered that credit card numbers are revealed.
Assurance - Code should be tested screened not to be vulnerable. Penetration test might prevent this. 4. An attacker falsely identifies himself/herself to
ABC Bids after accessing password information that is contained in the memory of the web server. There is a buffer overflow in the web server that may allow attackers to gain read access to sensitive information contained in the memory of the web server process. The information disclosed includes user IDs, passwords, cookies or authentication data belonging to members of ABC Bids.
Integrity will ensure that the vulnerability is patched. Firewall and intrusion detection might detect and stop the intruder.
Availability will protect the web server to be restored if the attacker should launch an attack and corrupt the web server.
Accountability - Audit will reveal the actions of the intruder. Log integration and analysis tools can aid to allow an alert of this condition.
5. An attacker reads a listing of files he/she is not authorized to read. There is a security vulnerability
Identification and authentication will ensure that only authorized users are given access to the web server
in the nph-test-cgi script that is designed to display information about the web server environment. It parses data requests too liberally and thus allows a person to view a listing of arbitrary files on the web server host.
within a secure session state.
Authorization will ensure that access to all scripts is controlled for authorized users.
Integrity will ensure that these scripts are not used at all. Checksums at directory level can ensure that this script is not accidentally introduced to the web server. Firewall and intrusion detection might detect and stop the intruder.
Accountability – Audit will reveal any suspect actions taken. Log integration and analysis tools can aid to allow an alert of this condition.
6. An attacker takes complete control over the ABC Bids IIS 5.0 web server after the unpatched server, with Indexing service installed, is compromised by the Code Red worm.
Integrity will ensure that the vulnerability is patched and that the web server is configured properly. Firewall and intrusion detection might detect and stop the intruder.
Availability will ensure that the web server is restored after a crash. Load balancing can ensure that some requests are processed.
7. The ABC Bids web server experiences DoS (denial of service) as a result of a denial of service vulnerability that exists because the web server is in a non-default configuration. When the web server is configured to perform URL redirection, a particular type of malformed request can cause the service to fail. As it happens, the Code Red worm generates exactly these types of requests when it tries to infect new machines.
Integrity will ensure that the vulnerability is patched. Configuring the web server properly can prevent it. Firewall and intrusion detection might detect and stop the intruder.
Availability will ensure that the web server is restored after DoS. Load balancing can ensure that some request are processed
Accountability - Log integration and analysis tools can aid to allow an alert of this condition.
5.3.3 Employees and facilities threats Service
1. The web server is stolen. Physical security can prevent this. 2. An attacker gets a password from a member by
social engineering.
Confidentiality – By training employees this can be prevented.
3. A retrenched employee uses his/her still valid password to access the web server to install a Trojan Horse that can later compromise the web server.
Authorization – By controlling employee privileges, this can be prevented.
Confidentiality – By monitoring employees this can be prevented.
By employing current state-of-the-art database security services identified in chapter 3, and adapting them to the virtual web database environment, the web server can be given more protection against the list of threats.
5.4 Conclusion
Table 5.11 shows a summary of all services and mechanisms to be provided by the web server in a virtual web database environment.
Table 5.11: All web server security services and mechanisms
Database security service Mechanism Employed by
Identification and authentication
Database authentication and password policy DB Operating system authentication DB WS Others (DCE, Kerberos, trusted client, etc.) DB WS
LDAP directories WS
Digital certificates WS
Smart cards WS
Secure cookies WS
Secure session state WS
Authorization Policies:
DAC policy ACLs, RBAC DB WS
MAC policy Bell-LaPadula, RBAC DB
RBAC policy RBAC DB
Other: Authorization implementations WS
Confidentiality
Encryption DB WS
Inference control DB WS
Employee confidentiality training DB WS
SSL (encryption) WS
Integrity
Database integrity
Use checksums DB WS
Virus and Trojan Horse protection DB WS
Patch vulnerabilities DB WS
Set proper configuration DB WS
SSL(checksum) WS
Firewalls WS
Intrusion detection tools WS Operational integrity Transaction processor DB Semantic integrity Entity integrity DB Referential integrity DB Domain integrity DB User-defined integrity DB Normalization DB
Accountability
Audit DB WS
Integrate log files WS
Log analysis tools WS
Alert when security breach detected WS Availability Hardware redundancy DB WS Backup DB WS Recovery DB WS Replication DB Contingency plan DB WS Load balancing WS Extended configuration WS Manageability
Security management tools DB WS
Assurance
Certification DB
Test security configuration DB WS
Vulnerability assessment tools WS
Penetration test WS
Physical security
Secure buildings and equipment DB WS
The user’s request has now been processed at web server level and access has been granted to the front-end of the application. The next chapter will cover the database security services that have to be dealt with as the request for complex functionality is processed at the application server.
[APAC01] Apache home page, http://www.apache.org/ABOUT_APACHE.html
[AVAY01] SSL-100, www.avaya.com
[BAHA01] Bahadur G., Shema M., Improving Apache, Information security magazine , April 2001 [BAO01] Bao W., SANS Institute, Introduction to Security of LDAP Directory Services,
http://www.sans.org/infosecFAQ/dir/LDAP.htm
[BIGG01] Biggs M., Sun tops charts with security system,
http://www.infoworld.com/articles/tc/xml/01/04/09/010409tctsolaris.xml
[CACH01] Cacheflow, http://www.cacheflow.com/
[CASS01] Cassandra, https://cassandra.cerias.purdue.edu/resource/popular.php
[CERT01] CERT coordination center, Various articles on web server security, www.cert.org [June 2001]
[ENCO98] EnCommerce, getAccess, 1998, http://www.encommerce.com/products
[FERR99] Ferraiolo D., Barkley J., Kuhn D., A RBAC model and reference implementation within a corporate intranet, ACM transactions on information systems security, Vol.1, No 2, Feb 1999
[FRAN01] Franklin I., Protecting the web server and applications , Computers and security, 20, 2001, p31-35
[GOSH01] Gosh A., Security and privacy for e-business, Wiley computer books, 2001 [HUGH01] Hughes C., Birznieks G., Serving up web server basics, webcompare.internet.com
[June 2001]
[INTE01] Microsoft IIS http://www.microsoft.com/windows2000/server/evaluation/features/web.asp [IPAD01] iPlanet Web Server, Enterprise Edition Administrator's Guide ,
http://docs.iplanet.com/docs/manuals/enterprise/50/ag/contents.htm [ISSY01] Internet Security Systems (ISS) www.iss.net
[JOHN00] Johns P., Ching A., Building a Highly Available and Scalable Web Farm, Microsoft Developer Network, msdn.Microsoft.com, December 2000
[NESI01] Netscape signing tool 1.1,
http://docs.iplanet.com/docs/manuals/signedobj/signtool/signintr.htm#1028922 [NETS01] Netscape, Introduction to SSL,
[PARK00] Park and Sandu, Secure cookies on the web, IEEEE Internet Computing, July-August 2000
[RSAS01] RSA Security, What is Fortezza, http://www.rsasecurity.com/rsalabs/faq/6-2-6.html
[RYAN01] Ryan D., Reality check, Federal Computer Week, 16 April 2001, www.fcw.com
[SANS01] Sans Institute, www.sans.org
[SNYD00] Snyder J., The New Holy Grail? Authorization policy servers make single sign-on a reality in multi-application web environments , Information Security, Oct 2000
[STEI00] Stein L., W3C The World Wide Web Security FAQ, http://www.w3.org/Security/faq/wwwsf1.html#Q3
[STEI98]
[TITT01] Tittel E., Understanding web server log files, 13 June 2001,
http://searchwebmanagement.techtarget.com/tip/1,289483,sid27_gci745626,00.html [WEBT01] Webtrends log analyzer, www.webtrends.com
