Pieces of the Web Application Puzzle

In a web application several components exist, each of which serves a specific function. Each has its own vulnerabilities as well.

Login This component is what is presented to users in order for them to provide a username and password for the authentication process.

Web Server This is the foundation for the whole system as it is the combination of hardware and software used to host the web application itself. What capabilities the server has depends on the type and configuration of the given server.

Session Tracking This component allows the web application to store information about a client pertaining to their current visit or future visits to the web application.

Permissions Based on who they authenticate as and if the authentication is successful, permissions determine what level of access the user has to resources on the server.

Application Content This is the information that the user is interacting with by providing requests to the server.

Data Access Web pages in a web application are attached to a library that provides data access.

Data Store This component is where the valuable information for the web application is contained. By design this may or may not be stored on the same system.

Logic This component is responsible for interacting with the user and providing the means for the correct information to be extracted from the database.

Logout This may be a separate function and is used by users to shut down their connection to the web application.

Flawed Web Design

One common way to exploit a web application or site is in the code itself. Comments and hidden tags that are embedded into a web page by the designer can yield information to an attacker. Although these types of tags and information are not intended to be displayed in a web browser, they can be viewed and analyzed using the View Code or Source capability present in most browsers.

The source code of a page could reveal something like the following:

<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.termina.com/received.htm">
<input type=hidden name="servername" value="https://payments.termina.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.termina.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-->

The code contains information that is useful to an attacker. Although the information may not be completely actionable, it does give you something. Notice the e-mail addresses and even what appears to be a payment processing server (payments.termina.com). This is information that an attacker can 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 application designer has used 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.

Buffer Overflow

A common vulnerability in web servers, and all software, is 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. 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. 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.

Denial-of-Service Attack

An attack that can wreak havoc with a web server is the venerable denial-of-service (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 that server can be rapidly consumed, slowing down its performance. A DoS attack is mostly considered an annoyance because it is easy to defeat.

Distributed Denial-of-Service Attack

While 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: it consumes the resources on a server and prevents it from being used by legitimate users. The difference between a DDoS and a DoS is 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 are:

Ping Flooding Attack A computer sends a ping to another system with the intention of uncovering information about the system. This attack can be scaled up so that the packets being sent to a target force it to go offline or suffer slowdowns.

Smurf Attack Similar to the ping flood attack, but with a twist to the process. In a Smurf attack, a ping command is sent to an intermediate network where it is amplified and forwarded to the victim. This single ping now becomes a virtual tsunami of traffic.

SYN Flooding The equivalent of sending a letter that requires a return receipt; however, the return address is bogus. If a return receipt is required and the return address is bogus, the receipt will go nowhere, and a system waiting for confirmation will be left in limbo for some period of time. An attacker that sends enough SYN requests to a system can use all the connections on a system so that nothing else can get through.

IP Fragmentation/Fragmentation Attack Requires an attacker to use advanced knowledge of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite to break packets up into fragments that can bypass most intrusion-detection systems. In extreme cases, this type of attack can cause hangs, lockups, reboots, blue screens, and other mischief.

Banner Information

As you learned in the footprinting phase, you can gather information from a server by performing a banner grab. This process is no different than earlier; you can use tools such as telnet or PuTTY to extract banner information and investigate the internals of the service.

The following code illustrates what may be 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

Error Messages

Error messages can reveal a lot of information about a server and a web application. Careless reveals of error messages can provide information that may be used for an attack or at least the fine-tuning of an attack. Messages such as the common 404 can inform a visitor that content is not available or located on the server. However, there are plenty of other error messages that reveal different types of information, from the very detailed to the very obscure.

Fortunately in many servers and applications error messages can be configured or suppressed as necessary. Typically these messages should not be too descriptive—if seen at all—outside a development or test environment.

Vandalizing Web Servers

Web servers are the targets of numerous types of attacks, but one of the most common attacks is the act of vandalism known as defacement. Defacing a website can be aggressive or subtle, depending on the goals of the attacker, but in either case the goals are the same: to embarrass the company, make a statement, or just be a nuisance. To deface a website, it is possible to use a number of methods, depending on the attacker’s own skill level, capabilities, and opportunities available.

Input Validation

Input validation is a mechanism used to verify information as it is entered into an application. Essentially, a user entering data into a form or website will have few if any restrictions placed on them when they enter data. When data is accepted without restriction, mistakes both intentional and unintentional are entered into the system and can lead to problems later on. However, with a mechanism for validating input in place it is possible to thwart these problems, which include:

• Database manipulation
• Database corruption
• Buffer overflows
• Inconsistent data

A good example of input validation, or rather the lack of it, is a box on a form where a zip code is to be entered, but in reality it will accept any data. 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.

Cross-Site Scripting (XSS)

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 an 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 information on the browser, to elevated access, to content in the browser.

The following steps reveal XSS in action:

1. The attacker discovers that a website suffers from an XSS scripting defect.
2. An attacker sends an e-mail stating that the victim has just been awarded a prize and should collect it by clicking a link in the e-mail:

   The link in the email goes to http://www.badsite.com/default.asp?name= <script>badgoal()</script>.

3. When the link is clicked, the website displays the message “Welcome Back!” with a prompt to enter the name.

   The website has read the name from your browser via the link in the e-mail. When the link was clicked in the e-mail the website was told your name is <script>evilScript ()</script>.

4. The web server reports the name and returns it to the victim’s browser.
5. The browser correctly interprets this as script and runs the script.
6. This script instructs the browser to send a cookie containing some information to the attacker’s system, which it does.

Insecure Logon Systems

Many web applications require some sort of authentication or login process prior to their use. Due to the importance of the logon process it is essential that it be handled safely and securely. Care must be taken that the incorrect or improper entry of information does not reveal information that an attacker can use to gain additional information about a system.

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:

• Entry of an invalid user ID with a valid password
• Entry of an valid user ID with an invalid password
• Entry of an invalid user ID and password

Applications should be designed to return generic information that does not reveal information such as correct usernames. Web apps that return a message such as “username invalid” or “password invalid” can give an attacker a target to focus on—such as a correct password (see Exercise 13.1).

Scripting Errors

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. Vulnerabilities such as a lack of input validation scripts can be a liability. A savvy attacker can use a number of methods to cause grief to the administrator of a web application, including the following:

Upload Bombing Upload bombing uploads masses of files to a server with the goal of filling up the hard drive on the server. Once the hard drive of the server is filled, the application will cease to function and will crash.

Poison Null Byte Attack A poison null byte attack passes special characters that the scripts may not be designed to handle properly. When this is done, the script may grant access where it should not otherwise be given.

Default Scripts Default scripts are uploaded to servers by web designers who do not know what they do at a fundamental level. In such cases, an attacker can analyze or exploit configuration issues with the scripts and gain unauthorized access to a system.

Sample Scripts Web applications may include sample content and scripts that are regularly left in place on servers. In such situations, these scripts may be used by an attacker to carry out mischief.

Poorly Written or Questionable Scripts Some scripts have appeared that include information such as usernames and passwords, potentially letting an attacker view the contents of the script and read these credentials.

Session Management Issues

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 a client and a 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:

Long-Lived Sessions Sessions between a client and a server should remain valid only for the time they are needed and then discarded. Sessions that remain valid for periods longer than they are needed allow intruders using attacks such as XSS to retrieve session identifiers and reuse a session.

Logout Features Applications should provide a logout feature that allows a visitor to log out and close a session without closing the browser.

Insecure or Weak Session Identifiers Session IDs that are easily predicted or guessed—so they can be used by an attacker to retrieve or use sessions that should be closed—can be exploited. Some flaws in web applications can lead to the reuse of session IDs. Exploitation of session IDs can also fall into the category of session hijacking.

Granting of Session IDs to Unauthorized Users Sometimes applications grant session IDs to unauthenticated users and redirect them to a logout page. This can give the attacker the ability to request valid URLs.

Poor or No Password Change Controls An improperly implemented or insecure password change system, in which the old password is not required, allows a hacker to change passwords of other users.

Inclusion of Unprotected Information in Cookies Cookies may contain unprotected information such as the internal IP address of a server that can be used by a hacker to learn more about the nature of the web application.

Encryption Weaknesses

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. When considering encryption and its impact on the application, focus on these areas of concern:

Weak Ciphers Weak ciphers or encoding algorithms are those that use short keys or are poorly designed and implemented. Use of such weak ciphers can allow an attacker to decrypt data easily and gain unauthorized access to the information.

Vulnerable Software Some software implementations that encrypt the transmission of data, such as Secure Sockets Layer (SSL), may suffer from poor programming and thus become vulnerable to attacks such as buffer overflows.

Some tools and resources are available to help in assessing the security of web applications and their associated encryption strategies:

• OpenSSL, an open source toolkit used to implement the SSLv3 and TLS v1 protocols: www.openssl.org
• The OWASP guide to common cryptographic flaws: www.owasp.org
• Nessus Vulnerability Scanner, which can list the ciphers in use by a web server: www.nessus.org
• WinSSLMiM, which can be used to perform an HTTPS man-in-the-middle attack: www.securiteinfo.com/outils/WinSSLMiM.shtml
• Stunnel, a program that allows the encryption of non-SSL-aware protocols: www.stunnel.org

Directory Traversal Attacks

Another type of attack is the directory traversal attack, which allows an attacker to move outside of the web server directory and into other parts of the host system. Once outside this directory, the attacker may then be able to bypass permissions and other security controls and execute commands on the system.

To execute this attack, an intruder takes advantage of errors or weaknesses in one of two areas

• Access control lists (ACLs), which are used to indicate which users and groups are allowed to access files and directories on a server as well as what level of interaction is allowed.
• Root directory, which is the directory on the server to which users are specifically restricted. Typically this is the highest-level folder they are allowed to access. The root directory acts as the top directory in the website and prevents users from gaining access to sensitive files on the server.

To perform a directory traversal attack, surprisingly little is needed—just some knowledge and a web browser. With these tools and patience, it is possible to blindly find default files and directories on a system.

The success of the attack depends largely on the configuration of the website and server, but there are some common threads. Typically the attackers rely on taking over or spoofing themselves as a user and gaining access to anything the user has access to.

In web applications with dynamic pages (such as ASP or ASP.NET), input is usually received from browsers through GET or POST request methods. Here is an example of a GET HTTP request URL:

http://beta.canadiens.com/show.asp?view=history.html

With this URL, the browser requests the dynamic page show.asp from the server and with it also sends the parameter view with the value history.html. When this request is executed on the web server, show.asp retrieves the file history.html from the server’s filesystem and returns it to the requesting party. Through some analysis an attacker can assume that the page show.asp can retrieve files from the filesystem and craft a custom URL:

http://beta.canadiens.com/show.asp?view=../../../../../Windows/system.ini

This will cause the dynamic page to retrieve the file system.ini from the filesystem and display it to the user. The expression ../instructs the system to go one directory up, which is commonly used as an operating system directive. The attacker has to guess how many directories to go up to find the Windows folder on the system, but this is easily done by trial and error.

Of course, you don’t need to use code to attack the server; you can use just the browser alone. A web server may be completely open to a directory traversal attack and only waiting for an ambitious attacker to track down and use sample files and scripts against it.

For example, a URL request that makes use of the scripts directory of IIS to traverse directories and execute a command can look like this:

http://server.com/scripts/..%5c../Windows/System32/cmd.exe?/c+dir+c:

The request returns a list of all files in the C: directory by executing the cmd.exe command shell file and running the command dir c: in the shell. The %5c expression that is in the URL request is a web server escape code used to represent normal characters. In this case %5c represents the character .

Directory Traversal Attack Countermeasures

A handful of methods can be used to thwart directory traversal attacks, such as:

• Running modern web server software or ensuring that up-to-date patches are installed.
• Enabling filtering of user input to the web server. It is common for modern web servers to include the ability to filter out nonstandard requests or codes.