Risks inherent with Web servers can typically be broken into three categories, each of which will be examined in more detail. Each of the categories of risk can be matched to the environments in which each of the users operates:

Web servers have a lot of the same vulnerabilities as any other servers—plus all the vulnerabilities associated with hosting content. Web servers can be the only face of companies that have no traditional locations (for example, Amazon and eBay). So you must have a thorough understanding of the vulnerabilities that are present in this medium.

A potentially dangerous vulnerability seen in Web site design is what you aren't supposed to see. Specifically, the comments and hidden tags that are placed in a Web page by the Web designer. These items aren't designed to be displayed in the browser, but a savvy attacker can observe these items by viewing the source code of the page:

<form method="post" action="../../cgi-bin/formMail.pl">

<!--Regular FormMail options---->

<input type=hidden name="recipient" value="[email protected]">
<input type=hidden name="subject" value="Message from website visitor">
<input type=hidden name="required" value="Name,Email,Address1,City,State,Zip,Phone1">
<input type=hidden name="redirect" value="http://www.someplace.com/received.htm">
<input type=hidden name="servername" value="https://payments.someplace.com">
<input type=hidden name="env_report" value="REMOTE_HOST, HTTP_USER_AGENT">
<input type=hidden name="title" value="Form Results">
<input type=hidden name="return_link_url" value="http://www.someplace.com/main.html">
<input type=hidden name="return_link_title" value="Back to Main Page">
<input type=hidden name="missing_fields_redirect" value="http://www.someplace.com/
error.html">
<input type=hidden name="orderconfirmation" value="[email protected]">
<input type=hidden name="cc" value="[email protected]">
<input type=hidden name="bcc" value="[email protected]">

<!--Courtesy Reply Options-->

When looking at the code, there is some information that is useful to an attacker. While the information may not be completely actionable as far as something that can be attacked it does give us something. In the code notice the presence of e-mail addresses and even the presence of what appears to be a payment processing server (https:// payments.someplace.com). This is information that an attacker may use to target an attack.

The following is another example of a vulnerability in code that can be exploited:

<FORM ACTION =http://111.111.111.111/cgi-bin/order.pl" method="post"

<input type=hidden name="price" value="6000.00">

<input type=hidden name="prd_id" value="X190">

QUANTITY: <input type=text name="quant" size=3 maxlength=3 value=1>

In this example, the Web designer has decided to use hidden fields to hold the price of an item. Unscrupulous attackers could change the price of the item from $6,000.00 to $60.00 and make their own discount.

A common vulnerability in Web servers, and all software, is the buffer overflow. A buffer overflow occurs when an application, process, or program attempts to put more data in a buffer than it was designed to hold. In practice, buffers should hold only a specific amount of data and no more. In the case of a buffer overflow, a programmer, either through lazy coding or other practices, creates a buffer in code, but does not put restrictions on it. Much like too much water poured into an ice cube tray, the data must go someplace, which in this case means adjacent buffers. When data spills or overflows into the buffers it was not intended for, the result can be corrupted or overwritten data. In practice if this act occurs, the result can be that data loses its integrity. In extreme cases, buffer overwriting can lead to anything from a loss of system integrity to the disclosure of information to unauthorized parties.

An attack that can wreak havoc with a Web server is the venerable DoS attack. As a fixed asset, a Web server is vulnerable to this attack much as any other server-based asset would be. When carried out against a Web server, all the resources on a Web server can be rapidly consumed, slowing down the performance of a server. A DoS is mostly considered an annoyance due to the ease at which it can be defeated.

Where a DoS attack is mostly an annoyance, the distributed denial of service (DDoS) attack is much more of a problem. A DDoS accomplishes the same goal as a DoS: to consume all the resources on a server and prevent it from being used by legitimate users. The different between a DDoS and a DoS is scale, using the concept of economy of scale. In a DDoS, many more systems are used to attack a target, crushing it under the weight of multiple requests at once. In some cases, the attack can be launched from thousands of servers at once against a target.

Some of the more common DDoS attacks include:

A banner can reveal a wealth of information about a Web server for those who know how to retrieve it. Using a piece of software such as Telnet or PuTTY, it is possible to retrieve this information about a server.

What's in a banner? The following code illustrates what is returned from a banner:

HTTP/1.1 200 OK

Server: <web server name and version>

Content-Location: http://192.168.100.100/index.htm

Date: Wed, 12 May 2010 14:03:52 GMT

Content-Type: text/html

Accept-Ranges: bytes

Last-Modified: Wed, 12 May 2010 18:56:06 GMT

ETag: "067d136a639be1:15b6"

Content-Length: 4325

This header, which is easy to obtain, reveals information about the server that is being targeted. Web servers can have this information sanitized, but the webmaster must actually make the effort to do so.

This information can be returned quite easily from a Web server using the following command:

telnet www.<servername>.com 80

Permissions control access to the server and the content on it, but the problem is they can easily be incorrectly configured. Incorrectly assigned permissions have the potential to allow access to locations on the Web server that should not be accessible.

While they might not seem like a problem, error messages can be a potential vulnerability as well giving vital information to an attacker. Error messages like 404 for example, tell a visitor that content is not available or located on the server. However there are plenty of other error messages that can be given each given different types of information from the very detailed to the very obscure.

Table 9-1 displays error messages that may be displayed in a Web browser or Web application when a connection is attempted to a Web server or service.

The messages in Table 9-1 come directly from Microsoft's development database.

Servers should be purpose-built to the role they will fill in the organization; anything not essential to this role should be eliminated. This process, known as hardening, will get rid of the features, services, and applications that are not necessary for the system to do its appointed job.

Most operating systems come preconfigured with a number of user accounts and groups already in place. These accounts can easily be discovered through a little research on an attacker's part. These accounts can be used to gain access to the system in ways that can be used for no good.

Structured Query Language (SQL) injections are designed to exploit applications that solicit the client to supply data that is processed in the form of SQL statements. An attacker forces the SQL engine into executing commands unintended by the creator by supplying specially crafted input. These commands force the application to reveal information that is restricted.

Developers of Web applications have traditionally been less than careful regarding the type of input they will accept. In most cases, a user entering data into a form or Web site will have few if any restrictions placed up on them when he or she enters data. When data is accepted without restriction, mistakes both intentional and unintentional will be entered into the system and can lead to problems later on, such as the following:

A good example of input validation, or rather the lack of it, is a box on a form where a phone number is to be entered, but actually any form of data will be accepted. In some cases, taking the wrong data will simply mean that the information may be unusable to the owner of the site, but it could cause the site to crash or mishandle the information to reveal information onscreen.

Another type of attack against a Web server is the cross-site scripting (XSS) attack. It relies on a variation of the input validation attack, but the target is different because the goal is to go after a user instead of the application or data. An example of a XSS uses scripting methods to execute a Trojan with a target's Web browser; this would be made possible through the use of scripting languages such as JavaScript or VBScript. By careful analysis, an attacker can look for ways to inject malicious code into Web pages in order to gain information from session info on the browser, to elevated access, to content in the browser.

Web applications have become more popular in recent years, with companies deploying more of this class of software application. Applications such as Microsoft SharePoint, Moodle, and others have been deployed for all sorts of reasons, ranging from organization of data to simplified customer access. Applications in this category are typically designed to be accessed from a Web browser or similar client application that uses the HTTP protocol to exchange information between the client and server.

Software in this category can be written in any number of development languages, including Java or ActiveX. Web applications can be constructed with a variety of application platforms, such as BEA Weblogic, ColdFusion, IBM WebSphere, Microsoft .NET, and Sun JAVA technologies.

Exploitative behaviors:

Making Web applications even more of a concern to the security professional is the fact that many Web applications are dependent on a database. Web applications will hold information such as configuration information, business rules and logic, and customer data. Using attacks such as SQL injections, an attacker can compromise a Web application and then reveal or manipulate data in ways that an owner may not have envisioned, much less intended.

Common vulnerabilities with Web applications tend to be somewhat specific to the environment, including factors such as operating system, application, and user base. With all these factors in mind, it can be said that Web application vulnerabilities can be roughly confined to the following categories:

If a Web application requires a user to log on prior to gaining access to the information in an application, this logon must be handled securely. An application that handles logons must be designed to properly handle invalid logons and passwords. Care must be taken that the incorrect or improper entry of information does not reveal information that an attacker could use to gain additional information about a system. An example of this situation is shown in Figure 9-1.

Applications can track information relating to improper or incorrect logons by users if so enabled. Typically, this information comes in log form with entries listing items such as:

Applications should be designed to return very generic information that does not reveal information such as correct usernames. Web apps that return message such as "username invalid" or "password invalid" can give an attacker a target to focus on— such as a correct password.

Figure 9-1. Revealing error message.

One tool designed to uncover and crack passwords for Web applications and Web sites is a utility known as Brutus. Brutus is not a new tool, but it does demonstrate one weapon that the attacker has to uncover passwords for Web site and applications. Brutus is a password cracker that is designed to decode different password types present in Web applications. The utility is designed for use by the security professional for testing and evaluation purposes, but an attacker can use it as well.

Brutus is as simple to use as are most tools in this category. The attack or cracking process using Brutus proceeds as follows:

Again Brutus is not the newest password cracker in this category, but it is well known and effective. Other crackers in this category include THC Hydra.

Web applications, programs, and code such as Common Gateway Interface (CGI), ASP.NET, and JavaServer Pages (JSP) are commonly in use in Web applications and present their own issues. Using methods such as SQL injections and lack of input validation scripts can be a liability if not managed or created correctly. A savvy attacker can use a number of methods to cause grief to the administrator of a Web application, including the following:

A session represents the connection that a client has with the server application. The session information that is maintained between client and server is important and can give an attacker access to confidential information if compromised.

Ideally a session will have a unique identifier, encryption, and other parameters assigned every time a new connection between client and server is created. After the session is exited, closed, or not needed, the information is discarded and not used again (or at least not used for an extended period of time), but this is not always the case.

Some vulnerabilities of this type include:

In Web applications, encryption plays a vital role because sensitive information is frequently exchanged between client and server in the form of logons or other types of information.

When working on securing Web applications you must consider the safety of information at two stages, when it is being stored and when it is transmitted. Both stages are potential areas for attack and must be considered thoroughly by the security professional. When considering encryption and its impact on the application, the following are areas of concern:

Some tools and resources are available that can help in assessing the security of Web applications and their associated encryption strategies:

For all its power and complexities, a database can be boiled down into a very simple concept: It is a hierarchical, structured format for storing information for later retrieval, modification, management, and other purposes. The types of information that can be stored within this format vary wildly, but the concept is still the same: storage and retrieval.

In the database world databases are typically categorized based on how they store their data, these organizational types are

Within a database there are several structures designed to organize and structure information. Each structure allows the data to be easily managed, queried, and retrieved:

In order to work with the data in a database, a special language is used. Structure Query Language (SQL) is a standard language for making interactive queries from and updating a database such as IBM DB2; Microsoft Access; and database products from Oracle, Sybase, and Computer Associates.

Databases have a broad range of applications for everything from storing simple customer data to storing payment and customer information. For example, in an e-commerce application when customers place an order their payment and address information will be stored within a database that resides on a server.

While the function of databases may sound mundane, databases really come into their own when linked into a Web application. A database linked as part of a Web application can make a Web site and its content much easier to maintain and manage. For example, if you use a technology such as ASP.NET, you can modify a Web site's content simply by editing a record in a database. With this linkage, simply changing a record in a database will trigger a change in any associated pages or other areas.

Another very common use of databases, and one of the higher-profile targets, is in membership or member registration sites. In these types of sites, information about visitors who register with the site is stored within a database. This can be used for a discussion forum, chat room, or many other applications. With potentially large amounts of personal information being stored, an attacker would find this setup ideal for obtaining valuable information.

In essence, a database hosted on a Web server behaves as a database resident on a computer. It is used to store, organize, and transmit data.

Databases can have a myriad of vulnerabilities that leave them susceptible to attack. These vulnerabilities are as varied as the environments the technologies are deployed into. Vulnerabilities include misconfiguration, lack of training, buffer overflows, forgotten options, and other details lurking in the wings waiting for an attacker.

Before you can uncover the vulnerabilities in databases it is necessary to know what type and where your databases reside. Databases can be easily missed because they may be installed as part of another application or just not reported by the application owner. For example, a product manufactured by Microsoft known as SQL Server Express is a small, free piece of software that is part of various applications that a typical user may install. As such, this database may go unreported by users who are unaware of the security issues involved.

A tool that is very effective at locating these "rogue" or unknown installations is a tool known as SQLPing 3.0. The description of this tool from the vendor's Web site describes the product:

A screenshot from SQLPing 3.0 is shown in Figure 9-2.

Figure 9-2. SQLPing 3.0 interface.

A cousin of SQLPing is a product known as SQLRecon. This product is very similar to SQLPing, but also employs additional techniques to discover SQL Server installations that may be hidden:

Running a scan with either of these tools will give you information about where you may have SQL Server installations that you are unaware of.

After a database has been located, the next step an attacker can choose to take is to see whether the password can be broken. A feature that is included in SQLPing3.0 is a password-cracking capability that can be used to target a database server and break its passwords. The password-cracking capabilities included with the product include the ability to use dictionary-based cracking methods to bust the passwords.

Every database is prone to its own types of vulnerabilities, but there are some common ones that can be exploited using the right tools. Some common vulnerabilities include:

Having knowledge of the database that you are using can go a long way toward thwarting these problems, but other there are some other methods that can be used. One effective method for uncovering problems is to consider the security problem from both an insider and outsider's perspective. Use tools and methods that an attacker that has no knowledge of the system might use.

Two pieces of software that are useful for perform audits on databases are known as NGSSquirrel and AppDetective.

NGSSquirrel from NGS Software is a tool used to audit databases to uncover vulnerabilities. In NGS Software's own words from its Web site:

The other software mentioned is AppDetective. In the vendor's own words:

Protecting databases can be as simple as making sure their existence is not so obvious. Keeping a database hidden from casual and even some aggressive scans by attackers is not a difficult task because the tools are quite often at your fingertips. Most Web servers, Web applications, and the databases hosted in the environment include some security features that can make a huge difference in protecting the database from would-be attackers: