Developers of web applications have traditionally been somewhat sloppy regarding the type of input they will accept. In most cases, users entering data into a form on a 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—will be entered into the system and can lead to problems later, such as the following:

• System crashes

• Database manipulation

• Database corruption

• Buffer overflows

• Inconsistent data

A good example of input validation, or rather the lack of it, is an input box on a form where a phone number is to be entered but 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 an XSS attack uses scripting methods to execute a Trojan horse with a target’s web browser; this would be made possible using scripting languages, such as JavaScript or PHP. By careful analysis, an attacker can look for ways to inject malicious code into web pages to gain information from session information on the browser or to gain elevated access.

Following are the steps of an XSS attack:

1. The attacker discovers that the HYRULE website suffers from an XSS scripting defect.

2. An attacker sends an email stating that the victim has just been awarded a prize and should collect it by clicking a link in the email.

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

4. When the user clicks the link, the website displays the message “Welcome Back!” with a prompt to enter the name.

5. The website has the name from your browser via the link in the email. When the link was clicked in the email, the HYRULE website was told your name is <script>evilScript () </script>.

6. The web server reports the “name” and returns it to the victim’s browser.

7. The browser correctly interprets this as script and runs it.

8. This script instructs the browser to send a cookie containing some information to the attacker’s system, which it does.

Most modern web browsers contain protection against XSS, but this does not mean the user is entirely safe.

Web applications have become wildly popular, with companies deploying more of this class of software application. Applications such as Microsoft SharePoint and Moodle 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 HTTP to exchange information between the client and server.

Exploitative behaviors include the following:

• Theft of information, such as credit cards or other sensitive data

• The ability to update application and site content

• Server-side scripting exploits

• Buffer overflows

• Domain Name System (DNS) attacks

• Destruction of data

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:

• Authentication issues

• Authorization configuration

• Session management issues

• Input validation

• Encryption strength and implementation

• Environment-specific problems

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 they are 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 a valid user ID with an invalid password

• Entry of an invalid user ID and password

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

One tool designed to uncover and crack passwords for web applications and websites is a utility known as Brutus. 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 not a new tool, but it does demonstrate one weapon that the attacker has to uncover passwords for websites and applications. Brutus is a password cracker that is designed to decode different password types present in web applications.

Brutus is a fairly straightforward tool to use. The attack or cracking process using Brutus proceeds as follows:

1. Enter the IP address into the Target field in Brutus. This is the IP address of the server on which the password is intended to be broken.

2. Select the type of password crack to perform in the type field. Brutus has the ability to crack passwords in HTTP, FTP, Post Office Protocol (POP3), Telnet, and Server Message Block (SMB).

3. Enter the port over which to crack the password.

4. Configure the Authentication Options for the system. If the system does not require a username or uses only a password or personal identification number, choose the Use Username option. For known usernames, the Single User option may be used, and the username entered in the box below it.

5. Set the Pass Mode and Pass File options. Brutus has the option to run the password crack against a dictionary word list.

6. At this point, the password-cracking process can begin; once Brutus has cracked the password, the Positive Authentication field will display it.

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

Web applications, programs, and code, such as Common Gateway Interface (CGI), ASP.NET, PHP, Ruby, Perl, 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 several 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 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.

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:

• Long-lived sessions—Sessions between client and server should remain valid only for the length they are needed and then discarded. Sessions that remain valid for periods longer than they are needed allow attackers 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 can be used by an attacker to retrieve or use sessions that should be closed. Some flaws in web applications can lead to the reuse of session IDs.

• Granting 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.

• Absent or inadequate 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—Information such as the internal IP address of a server can be used by a hacker to ascertain more about the nature of the web application.

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 sensitive 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 effect on the application, the following are 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 because of this become vulnerable to attacks, such as buffer overflows.

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

• OpenSSL, an open-source toolkit used to implement the SSLv3 and Transport Layer Security (TLSv1) protocols (www.openssl.org)

• The Open Web Application Security Project (OWASP) Guide to Cryptography (www.owasp.org/index.php/Guide_to_Cryptography)

• Nessus security scanner, which can list the ciphers in use by a web server (www.tenable.com/products/nessus-vulnerability-scanner)

• Stunnel, a program that allows the encryption of non-SSL–aware protocols (www.stunnel.org)