The World Wide Web is a client-server based application originally developed to distribute documentation.
Researchers at various locations, notably the National Center for Supercomputer Applications at the University of Illinois, extended the original design to include the distribution of a wide variety of media including
Helper applications are standalone programs that the browser runs to display content in formats not supported by the browser itself or a plug-in.
A typical helper is Real’s RealPlayer audio and video player.
When a user clicks on a link to a RealPlayer video clip, the browser starts the player and passes along the URL or downloads the video clip and passes the filename of the clip to the player depending on how the clip is specified on the page.
The system administrator needs to be aware of the media types his users will need to view.
Macromedia’s Flash animation player plug-in and Real’s RealPlayer audio and video player are two typical additions to the base web browser that are widely used to display content found on many web sites.
Some sites offer less common media types such as VRML or other 3D images, Window’s media player audio or video, Quicktime video, and others.
Web browsers present several security problems revolving around the issues raised by “active content”.
Active content is a program or script that is downloaded as part of a web page and used to provide active features such as animated menus, special page rendering effects, error checking in forms and other features.
Additionally, most browsers include a Java interpreter either built-in or as a plug-in.
Some plug-ins such as the Macromedia Flash player interpret active content and can be considered similar to a scripting language in terms of their programmability.
Internet Explorer on Windows systems adds the capability of both Windows scripting and executable applets known as ActiveX .
The range of mischief an executable applet or script could potentially cause is large.
Turning these off will disable certain interactive features of some web pages.
The desirability of turning these features off to gain additional security must be weighed against the requirements of the applications the user has and the web pages they need to view.
Bugs in the browser itself constitute another common problem.
Browsers are complex, often including their own Java virtual machine as well as internal versions of ftp and other network tools.
System managers at sites concerned about security should continually monitor the browser vendor Web pages for updates that address security problems.
WARNING: There are numerous security vulnerabilities associated with downloaded applets and scripts on Microsoft Windows platforms that can affect the security of other systems on a network. These include the unintended installation of malicious software that may examine or disrupt network traffic or adversely effect the operation of servers and other networked systems. Security conscious sites need to consider not only the security of their servers, but also the risks involved in their choice of client platforms and software.
Installing and configuring a Web server is a much more involved process than configuring a web browser.
A Web server is a very complex daemon with numerous features that are controlled by several configuration files.
Web servers not only access files containing web pages, graphics and other media types for distribution to clients, they can also assemble pages from more than one file, run CGI applications, and negotiate secure communications.
Security and performance issues are near the top of the list when choosing, installing and configuring any web server.
Availability – Some web servers are available for only one operating system platform.
Some CGI programs, database interconnections and other data sources are available for only selected platforms.
A careful inventory of the desired CGI programs and data sources is helpful in reducing the range of choices to those where the needed software is available.
Viewed another way, if a specific platform has already been selected, a review of the web servers, CGI programs, etc. that are available for the selected platform can help guide the development of the web site.
WARNING: Based on a long string of security problems, culminating in the infamous Code Red and Nimda worms, many organizations have moved away from Microsoft’s Internet Information Server (IIS) web server. Moving away from IIS is also the recommendation of the Gartner Group.
Application Servers – Tools such as Zope and php provide templates for building web pages.
These templates form an entry point into a scripting language and access to databases easing the development of dynamically created web pages.
Modules – Analogous to web browser plug-ins, modules extend the web server by directly adding functions.
Like web browser plug-ins, modules are specific to a particular web server and match that web server’s API.
Status reporting, performance enhancements such as a built-in Perl interpreter, encryption utilities, and even URL spelling correction are some of the modules that are available for the Apache web server.
Apache is built using the “configure and make” procedure common for many open source packages.
Like other packages that use the configure utility, typing “configure --help” will produce a list of all of the available option flags.
Additional modules not found in the base Apache distribution may require additional work.
For example, adding mod_ssl, to provide secure web connections requires that the OpenSSL package be installed first and that an environment variable, SSL_BASE, containing the path to OpenSSL be set when Apache is configured.
The ssl module has 22 directives and provides fine control over the security of the connection.
The effort required to obtain a certificate and configure secure web connections is well worth it.
Secure web connections form the basis of many other applications.
Two examples are web-based e-mail and web based remote system management.
The end-to-end encryption supplied by SSL is especially important when remote users are utilizing potentially insecure networks such as wireless networks, or network connections offered at conferences or hotels.
By default a web server listens on port 80 for plaintext requests and port 443 for SSL connections.
These are well-known ports and will be examined by attackers.
The port a web server listens on can be changed via the server configuration file, however this will cause web browsers to be unable to connect to the server unless the port number is included in the URL specification.
For example, if the web server on www.astro.com were set to listen on port 8000, the URL for the server’s default page would be : http://www.astro.com:8000
WARNING: Changing the port a web server listens for requests on does not improve the security of the server . An attacker can locate the web server by scanning all of the ports open on the system.
In addition to the access controls found in the web server configuration files, many web servers provide access control for individual user directories by means of control files found in those directories.
Apache uses a file called “.htaccess” which contains directives specifying access.
For example, one could restrict access to a particular directory to a specific domain by placing this in the .htaccess file in the directory to be protected.
deny from all
allow from .bio.purdue.edu
In a .htaccess file, the options are assumed to apply to the directory the .htaccess resides in and explicit <Directory> directives like those used in the httpd.conf file are not needed.
The access directives can include IP address ranges and references to password databases if desired.
CGI programs are among the biggest potential dangers to Web server security.
These programs are run based on a URL passed to the Web server by a client.
In normal operations this URL comes from a form or page. However, the URL provided to a CGI program can be given to the Web server by other means and can be carefully constructed to exercise bugs in the CGI program itself.
For example, one of the most common attacks against a web server is via the phf CGI program.
The phf program is not included with recent versions of Apache, but was present in earlier versions.
Due to poor design, phf could be easily subverted.
To disable this CGI program, remove it from the cgi-bin directory specified in the web server configuration file.
WARNING: The mod_perl module for the Apache web server does not provide any security advantages over a standalone CGI program written in Perl. While it does offer a substantial performance improvement, CGI programs making use of mod_perl need to be as carefully audited as standalone CGI programs.
Similarly, the sysadmin should disallow user executable CGI programs.
Like the executable server side includes mentioned earlier, user executable CGI opens a Pandora’s box of possible vulnerabilities.
Limit CGI programs to a controlled directory and carefully audit any CGI programs for security vulnerabilities.
If it is necessary to run a CGI under the UID of a user other than the web server, a wrapper such as suexec or CGIWrap can be used.
The wrapper limits the damage an attacker can cause by exploiting a poorly written CGI program.
Wrappers are often needed when a CGI program makes use of data that is accessible only to a particular UID.
Some alternative approaches to standalone CGI programs are application servers such as PHP, and ZOPE.
These tools provide a standardized CGI interface designed specifically to avoid problems found in input from web pages.
These tools also provide for rapid development of dynamic pages used in a growing number of web applications.
PHP is also available as an Apache module giving better performance than that of a standalone CGI program.
WARNING: While providing a more standardized way of using CGI, tools like ph and zope are not without problems. Application servers can contain bugs that make vulnerable to attack like any other CGI program or module.
For example, all versions of PHP prior to version 4.1.2 were found to have a buffer overflow that can be exploited to gain elevated privileges.
A privilege elevation problem was also found in ZOPE versions prior to version 2.2.1 beta 1
A common error in deploying web servers is to place the web server behind the firewall and allow requests to the web server to pass through the firewall.
While this seems like a good way to protect the web server it in fact more often leads to the web server becoming a conduit for attackers to pass through the firewall and gain access to the secured network behind it.
A better approach is to place the web server outside the firewall.
In this configuration, the web server is dedicated to web serving only, all other services except for a secure communications facility such as ssh are removed from the system.
Placing the web server outside the firewall acts to prevent a compromise on the web server from proceeding on to the systems protected by the firewall.
Of principal interest from a security standpoint are error_log, agent_log, and access_log.
These logs should be reviewed periodically for purposes of identifying CGI program problems and attempts to access files not intended for distribution.
Another aspect of web server log files is the wealth of information they hold regarding the usage of the web site.
Log analysis tools such as http-analyze can provide the web site administrator with a variety of useful statistics on the usage of the web site
WARNING: A web server’s log files can provide a wealth of information for an attacker. Be certain that the location of the log files is not accessible by the web server. See the discussion in the section on file access control for a description of how to limit the parts of the file tree the web server is allowed to serve.
For a local network with a slow connection to the Internet, a proxy web cache can be used to improve performance and conserve bandwidth on the slow speed link.
A proxy web cache acts as a local reference for all web requests.
The proxy cache holds copies of web page elements for a time period defined by the content provider or by the proxy cache configuration.
Web browsers on the local network are configured to use the proxy cache and the proxy cache in turn makes requests for web pages not in its cache or simply replies with the page elements already in the cache.
An extension of the idea of using a web cache as a “front end” to a web server is to use a set of distributed web servers or web caches to provide more web service. There are several approaches to this.
Round Robin DNS - This is a special DNS configuration that treats a series of web servers as a single DNS entry.
When a request is made for this special entry, the DNS server replies with one of the IP addresses in the series.
It replies with the next address in the series for the next request and so on.
This spreads the web service load over the machines in the series.
3DNS Appliances - These systems provide an enhanced version of DNS that is tied to database.
They can not only spread load between a group of servers as the round robin DNS method does, but also assign requests to servers that are physically close of to the system making the request via data on the topology of the Internet stored in their database.
Load Balancing Routers - These systems perform a similar round robin load sharing function but work at the packet level, routing incoming packets destined for a web server to a series of web servers each in turn.
Commercial Service Providers - Companies such as Akamai provide globally distributed web caching services aimed at large high volume web sites.