The obvious risks to a security breach are that unauthorized individuals: 1) can gain access to restricted information and 2) may be able to escalate their privileges in order to compromise the application and the entire application environment. The areas that can be compromised include user and system administration accounts.

This chapter identifies the major classes of web application vulnerabilities, gives some examples of actual vulnerabilities found in real-life web application audits, and describes their associated level of risk. The classes are:

• authentication
• session management
• access control
• input validation
• redirects and forwards
• injection flaws
• unauthorized view of data
• error handling
• cross-site scripting
• security misconfigurations
• denial of service
• related security issues

Chapter 4 provides remediation guidance for each of the vulnerability classes and specific vulnerabilities described in this chapter. The vulnerability and remediation information also is provided in a consolidated spreadsheet that you can sort or add to is available with the downloads for this book. (See the Source Code/Downloads tab on the book’s Apress product page: www.apress.com/9781484201497.)

IT-security and web-application-security auditors including myself have seen more than our fill of real-life vulnerabilities. I am sharing some of these examples in this book to make the information as relevant as possible to the reader.

Lack of Sufficient Authentication

Risk level: HIGH

Correctly checking authentication credentials and then providing access to a web application accordingly are paramount operations for a server to perform when providing security and privacy.

Prior to accessing a web application, a server should require end users to authenticate themselves and confirm they are in fact who they purport to be.

In addition, strong authentication using valid credentials is the first security checkpoint for protecting web applications. One of the biggest web application weaknesses is the failure to provide a means of strong authentication.

The obvious risk to an authentication breach is that an unauthorized individual or computer program can gain access to restricted information and may be able to escalate their privileges in order to compromise an application and the entire application environment.

The compromised applications can, of course, include user and system-administration accounts. Additionally, the individual could gain unauthorized access to the targeted account, to another user’s account, and/or have the opportunity to view sensitive or private information.

Weak Password Controls

Risk level: HIGH

Passwords are one of the most important elements to Internet security. They must be protected and changed regularly because an attacker or malicious user can mount a password-guessing attack (e.g., through brute force or a dictionary) that can have a high probability of success. Once a password has been guessed, the attacker can then log on to the application using the “guessed” account credentials and operate on the user’s behalf (e.g., change the user’s profile, mount attacks using fields available only to authenticated users, access sensitive information).

As auditors, we often find a situation like this wherein the user policy did not require users to have a complex password (such as a combination of alphanumeric characters, use of lower- and upper-case characters, etc.). One of the auditors was able to breach this weak security and gain access to the account with a simple password (“abcde”).

Passwords Submitted Without Encryption

Risk level: HIGH

Passwords submitted over an unencrypted connection are vulnerable to capture by an attacker that is suitably positioned on the network to monitor and capture traffic. This includes any malicious party located on the user’s own network, within her ISP, within the ISP used by the application, and within the application’s hosting infrastructure, as well as networks along the communications path.

A real-life example that I’ve seen is credentials being sent in clear text on an unencrypted communications channel that was susceptible to eavesdropping. Unencrypted means the opposite of encrypted. Encryption is the conversion of data into a form that an unauthorized reader cannot easily interpret. An authorized reader then converts encrypted data back into its original form so it can be understood using a method of decryption. There are many methods for encryption/decryption that are called algorithms in the security world. An algorithm can be as simple as Morse code or as complex as those used for military purposes.

Username Harvesting

Risk level: HIGH

Usernames need to be protected and never shared, as they can be used to try to obtain unauthorized access to an account.

Like passwords, usernames are susceptible to being harvested with a brute-force method or by simply finding the e-mail address associated with them by doing research on the Internet. An attacker or a malicious user can leverage these items as a potential vulnerability with which to gather information. That person can then guess usernames in the login screen, which will return a detailed error message if the account does not exist. This information can in turn be used to devise more precise attacks (e.g., password guessing for valid accounts only, focusing on reducing the number of hacking attempts to a level that may not be detected by any automated methods).

Login screens are also configured to display detailed error messages that reveal username information, and in a worst-case scenario, this information can also be exploited to gather information.

Weak Session Management

Risk level: LOW-HIGH

Session management is something that most users are unaware of, but this is an essential security methodology for foiling hackers from attempting to break into and take control of a session. The idea is for a server to be able to regularly verify that the user conducting the interaction or conversation is the one the server thinks it is.

If an application doesn’t use transport-level encryption (SSL or TLS) to protect all sensitive communications passing between a client and a server, the communications between them is more highly susceptible to a security breach. Communications are intended to include the login mechanism and related functions where sensitive data can be accessed and where privileged actions are performed.

Secure Sockets Layer (SSL) is a standard security technology, or protocol, for establishing an encrypted link between a web server (“server”) and a web browser (“client”). SSL uses encryption technology to secure both the communications link (referred to as a tunnel) and the data being transmitted.

SSL has been superseded by a more advanced technology called Transport Layer Security (TLS). TLS relies on third-party or self-signed certificates to create keys that are used for encryption. TLS is the successor of SSL. TLS is more secure than its predecessor. However, SSL is more widely used than TLS.

We found many real-life examples where web applications are not correctly establishing session encryption. Since HTTP does not provide this capability, it is up to the web applications to provide it. HTTP is short for hypertext transfer protocol, which is the underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted and what actions web servers and browsers should take in response to various commands.

During the course of two separate audits, we could not determine the level of SSL security because we could not explicitly determine whether the SSL keys were verified by hashing or if they were simply encrypted while stored. Since interviews were not in the scope of these particular audits, there was no way for an auditor to verify the facts. If the SSL keys were simply encrypted but not hashed, then they would be susceptible to compromise if an attacker could decode the encryption. In addition, during the course of these two audits, there was no evidence of salting being used in this environment, which was another indication that hashing was not used in these environments.

Hashing is a form of one-way encryption. The idea is to protect critical information such as passwords by never having to store them, something that allows them to be compromised. By hashing them and storing the hashed value instead of storing the actual critical information, the risk to the critical information is reduced. The recipient must recreate the hashing process and compare hashed values to make sure the critical information is correct. Salting is additional protection for hashing. Salting is adding random extra information into the critical data before it is hashed. This process makes it more difficult for a person of malintent to guess critical information.

For the purposes of this book, a session is the activity carried on between a web browser and a web server from the time of logon to the time of logout. It is conducted over the HTTP or HTTPS protocols. In the bigger picture, a session is really a TCP or UDP session that deals with any protocol and doesn’t necessarily directly relate to HTTP or HTTPS, although in the context of web application security it can.

Transmission control protocol (TCP) is one of the most basic of the group of protocols that makes the Internet function. TCP allows for requests and responses, and a TCP request is simply a request for service. User datagram protocol (UDP) is a simplified version of a transmission protocol that provides for limited messaging to be exchanged between computers in a network that uses the internet protocol (IP). It does not provide as comprehensive a function as the TCP protocol.

Weak SSL Ciphers Support

Risk level: HIGH

A standard method of securing communications between a user and a web application is the use of encryption. If the method of encryption is outdated or weak, then the security is weak.

There are too many examples we have seen during the audit process where a remote service supports the use of weak SSL ciphers. An attacker could break the weak cipher’s encryption and perform a “man-in-the-middle” attack to eavesdrop on a user’s session. As previously mentioned, SSL is a standard security technology or protocol for establishing an encrypted link between a server and a client. SSL uses encryption technology to secure both the communications link (referred to as a tunnel) and the data being transmitted. The cipher for SSL is the encryption methodology that a particular version of SSL is using. SSL can utilize a variety of ciphers, some of which are more secure than others.

Information Submitted Using the GET Method

Risk level: MEDIUM

There are several methods that HTTP utilizes to make requests for information, including GET and POST. Since HTTP is unencrypted, it is important for web application programmers to consider the security weaknesses inherent in its use of the GET method, making GET a poor choice for transmitting sensitive data such as user names and passwords. Not to drill in too deeply, but it is the clear-text nature of the HTTP protocol that makes it insecure. GET displays data in clear text in the URL, and the URL can in turn be seen in server logs, in client browser histories, and in any forward or reverse proxy servers between a user and a web application server. This makes sensitive data retrievable for unauthorized persons.

URL request strings may also be displayed onscreen, bookmarked, or e-mailed around by users. They may be disclosed to third parties via the HTTP referrer header when any off-site links are followed. The HTTP referrer header is a data field, such as a hyperlink on a web site, that drives visits to another web site. Examples of HTTP referrers are other web sites, search engines, link lists, e-mails, and banner advertisements.

Here again, we see many client web applications that use the GET method to submit sensitive information, such as session ID (session token) and passwords, which are transmitted within the query string of the requested URL.

Self-Signed Certificates, Insecure Keys, and Passwords

Risk level: HIGH

Certificates, keys, and passwords are fundamental to Internet security. The most reliable certificates are managed by third-party certificate authorities. Self-signed and self-managed versions are not as trustworthy. They are good cover for an imposter posing as a valid organization, and the SSL or TLS man-in-the-middle attack often uses self-signed certificates to eavesdrop on SSL or TLS connections. A man-in-the-middle attack is done by an eavesdropper of a communication session that subsequently inserts itself into the session and tricks the parties at either end to think they are still communicating directly with each other. In fact, they are both communicating with the man in the middle. This attack succeeds when the attacker impersonates each endpoint to the satisfaction of the other.

On another note, users should be wary of the warning statements about invalid certificates, which indicate that a self-signed certificate has no outside validation.

We saw a situation where a server’s X.509 certificates were indeed self-signed, suggesting that they were not obtained from a certificate authority. If the certificates were susceptible to being viewed by an unauthorized party, then that party could create bogus certificates and attempt to hijack a session.

Username Harvesting Applied to Forgotten Password Process

Risk level: HIGH

A relatively simple way for hackers to gain unauthorized access to usernames is via a password recovery process. We have frequently seen registered users’ information being revealed. This happens through the unnecessary display of user identification in a password error message. An attacker or malicious user can leverage this vulnerability to gather information on registered users. This information will assist in devising more precise attacks (e.g., password guessing focusing on valid accounts only to reduce the number of attempts, at a level that may not be detected by automated monitoring).

Autocomplete Enabled on Password Fields

Risk level: LOW

Another relatively easy way for hackers to gain unauthorized access to usernames is to see them displayed in autocomplete as soon as the first part of the name is typed.

The web application contains HTML form fields that contain an input password when Autocomplete is not set to Off. Passwords stored on connecting client machines could expose user accounts to malicious third parties.

Most browsers have a facility to remember user credentials that are entered into HTML forms. This function can be configured by the user and also by applications that employ user credentials. If the function is enabled, credentials entered by users are stored on their local computer and retrieved by the browser on future visits to the same application.

The stored credentials can be captured by an attacker who gains access to the client computer, either locally or through a remote compromise. Further, methods exist whereby a malicious web site can retrieve the stored credentials for other applications by exploiting browser vulnerabilities or through application-level cross-domain attacks.

While storing information on a web application does not represent a risk in and of itself, it does mean that users who use the affected forms may have their credentials saved in their browsers, which could in turn lead to a loss of confidential information if a shared host is used or their machine is compromised.

Session IDs Nonrandom and Too Short

Risk level: MEDIUM

Since it is a security weakness to use unique session identifiers that are easy to guess, they should be as random and as long as possible.

A Session ID or session identifier or session token is an identification device used to identify a user to a web application. The web application creates session tokens and sends them to a user’s browser. The web browser in turn sends the token back to the web application along with any requests or information in order to identify the user.

An attacker could guess token values for authenticated users, which could lead to unauthorized access in the form of session hijacking. From the point of hijacking onward, any action performed by a malicious user will then be logged as being performed by the legitimate user.

Weak Access Control

Risk level: LOW-HIGH

Restricting or controlling access to an application, or for that matter to all important processes and files, is the most important aspect of security. A prime goal of hackers is to gain unauthorized access to applications and then increase the priority level of their access privileges.

In general, strict authentication should be enforced at both the application and server levels in order to minimize the chance of unauthorized access to confidential information. This process is prone to administrative errors particularly if it is not kept simple and implemented in a way that is easy to test.

During a particular audit, we identified that access control to a specific page was not enforced either at the application or server level, which may have allowed an attacker to impersonate an authorized user and gain access to confidential information.Specifically, the URL pointing to subsections of the application was allowed to be changed by the user without further authentication.

During the interview portion of the audit, the auditor further discovered that some of the authentication process code was written in-house as part of the client-side application in order to communicate with the third-party authentication engine. This nonunified code was hard to administer and prone to errors.

Frameable Response (Clickjacking)

Risk level: LOW

If IFrames are used in an application without any restriction on the source of the content, then a clickjacking attack can occur. An attacker can do this by embedding an IFrame on any web site and overlaying the invisible IFrame on top of legitimate content. When a user clicks a legitimate-looking button, the attacker’s button or link is actually being clicked.

By inducing users to then perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out harmful actions. This can result in a user’s computer being hijacked and confidential data getting compromised. IFrames are tools available to web site developers that allow them to divide a screen into different sections. This enables each section to get information from its own separate information source.

What makes this a very powerful way of attacking is that it is actually done within the bounds of the HTML specification, which means that the web site is working as expected. The attackers just exploit this feature for malicious attacks. Therefore, web site administrators may not know that something is wrong until complaints come in from users. It is hard to pinpoint that an attack has taken place because everything on the site looks the same and the clickjack element has been thoroughly disguised as harmless.

Cached HTTPS Response

Risk level: MEDIUM

Cached HTTPS responses are caused by sensitive information from application responses being stored in the local cache memory of a user’s workstation. This information may be viewed and retrieved by other parties who have access to the same computer simply by looking at the cache. This situation is exacerbated if a laptop is stolen or if a user accesses the web application from a public terminal.

Cache refers to copies of recently viewed web pages and associated data that are stored on a local disk. This local data improves web application access speed but it is also easy for anyone to find. For instance, Microsoft Internet Explorer cache files can be easily found in the Users File and labeled as Cache or Temporary Internet Files. In some browsers including Internet Explorer, cache content may be created by both HTTP and HTTPS.

An example of this vulnerability appeared while conducting a test during a valid user session, where a user’s browser did store content received from the web application in cache.

Sensitive Information Disclosed in HTML Comments

Risk level: LOW

Many web application programmers use HTML comments to help debug the application. While adding descriptive comments can be very useful for developers to explain things to others and to remind themselves about how program code works, they should never be able to be viewed by users, who might be potential hackers. To worsen the situation, some programmers also leave sensitive data in comments. By sensitive data, I am referring to things like file names that are related to the web application, old links or links that were not meant to be browsed by users, and old code fragments. An attacker who finds this type of data in comments can map the application’s structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application. These are stepping stones from which an attacker may develop a damaging attack against the site.

HTTP Server Type and Version Number Disclosed

Risk level: LOW

It is always good security practice to not reveal any information about the manufacturer or version of any network hardware or software since this information can be used by a hacker to further investigate vulnerabilities associated with that specific technology.

For instance, a common audit observation is that HTTP headers in HTTP responses from web servers disclose the web server type and version number. An attacker or a malicious user could exploit this information to mount attacks against the known vulnerabilities associated with the type and version of the web server. These attacks may compromise the remote system and allow the attacker to obtain administrator-level permissions on the web server, which will grant full access to the system and all the data stored on it.

The remote system can then be leveraged to execute additional attacks against internal systems in the organization.

Insufficient Session Expiration

Risk level: MEDIUM

I previously discussed the importance of secure sessions. It is also important that sessions are changed frequently to make hacking them more difficult. Insufficient session expiration may permit an attacker to reuse old session credentials or session IDs for authorization. One auditor was able to replay a single request to the web application after logging out. A session is the activity carried on between a web browser and a web server from the time of logon to the time of logout. It runs over the HTTP or HTTPS protocols.

The lack of proper session expiration may also improve the likelihood of success of certain attacks. An attacker may intercept a session ID, possibly via a network sniffer or cross-site scripting attack. In another scenario, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Insufficient session expiration could allow an attacker to use the browser’s back button to access web pages previously accessed by the victim.

HTML Does Not Specify Charset

Risk level: LOW

An easy-to-overlook security problem with creating HTML content is the developer being able to specify which character set he wants to use; it is best default practice to use the most secure one.

If a web response states that it contains HTML content but does not specify a character set, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. HTML is an Internet standard that specifies how web pages are formatted and displayed.

Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of nonstandard characters anywhere in the response may cause the browser to interpret the content using a different character set.

This can have unexpected results and can lead to cross-site scripting vulnerabilities in which nonstandard encodings like UTF-7 can be used to bypass the application’s defensive filters. In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. Always review the contents of the response and the context in which it appears to determine whether any vulnerability exists.

Session Fixation

Risk level: HIGH

Yet another issue with the security of sessions occurs when sessions are not fully terminated when the activity related to that session is ended. Many web application audits have revealed that there exists a serious cookie problem where the web application authenticates a user without first invalidating the existing session. The result is that the application continues to use the session associated with the previous user. This creates a risk of users gaining access to data that they do not have authorization to view.

Insecure Cookies

Risk level: MEDIUM

Since cookies can be part of access controls, five common security flaws related to them are aptly included here at the end of the access control section. An HTTP cookie is a short file of information sent by a web server to a web browser. The message is then sent back to the server each time the browser requests a page from it. The purpose of the use of the cookie is to enhance the user’s experience with the web application by directing the user to the information of most interest within it.

We often see that the session tokens are not properly protected where the web application environment provides a session capability; for example, when the user’s session ID is displayed in the URL. This creates a vulnerability where an attacker could hijack an active session and assume the identity of a valid user.

Even if authentication is required, it may be possible for a user to conduct it using legitimate credentials but then change the session ID in the URL line to access another user’s data without requiring reauthentication. A session token, or session identifier or session ID, is an identification device used to identify a user to a web application. The web application creates session tokens and sends them to a user’s browser. The web browser in turn sends the token back to the web application along with any requests or information in order to identify the user.

An external or even internal attacker could leverage the flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users and even to escalate their privileges.

As a general comment, developers frequently build custom authentication and session management schemes, but building these correctly is difficult. As a result, custom schemes frequently have flaws in areas such as the login/logout, password management, time-outs, Remember Me buttons, secret question, account updates, and so forth. Finding such flaws can sometimes be difficult, as each implementation is unique.

Cookies with No Secure Flag

Risk level: MEDIUM

A cookie with no secure flag is another example of when it is important to not unnecessarily reveal details even of a cookie. As a reminder, a cookie is a short file of information sent from a server to a browser and its contents should remain unavailable to potential hackers.

If the secure flag is set on a cookie, browsers will not submit the cookie in any requests that use an unencrypted HTTP connection, thereby preventing the cookie from being intercepted by an attacker monitoring network traffic. If the secure flag is not set on the cookie, the cookie will be transmitted in clear text.

Cookies Set to Expire in the Distant Future

Risk level: MEDIUM

Prolonged expiration is another example of problems that can arise with secure cookies. It is important to make sure that cookies do not last too long in order to reduce the chances of them being read by a party with malicious intent.

A user’s session can be used by anyone with knowledge of the cookie. Since cookies are not necessarily destroyed upon tabbing to a new page or to closing a window, it can be easy for anyone with physical access to the user’s computer to reuse an existing session.

We once saw a case where the configuration for cookie expiration was set for 30 years from its initial creation, where best practices suggest cookie expiration should be only as long as required for its useful life, pending any legal requirements for longevity.

Cookies with No HttpOnly Flag

Risk level: LOW

HttpOnly cookies are created by a server application and have security value. They cannot be read from or written to in JavaScript on the client side, with these possibilities only existing on the server side.

If the HttpOnly flag is not set or the cookie is created in client-side JavaScript, the cookie can be read from and written to in client-side JavaScript as well as on the server side. This is not desirable from a security perspective.

Client-side malicious code, such as a malicious JavaScript, could read the cookie content. An attacker could leverage this vulnerability and capture confidential cookies via an injected script. This confidential data can be used to build an attack.

Cookies Created on the Client Side

Risk level: LOW

The same concern as for cookies where the HttpOnly flag is not set, a party other than the trusted server can send potentially malicious data back to the server within a cookie.

Malicious client-side code could be used to manipulate a site’s cookies. This makes it possible to move the enforcement of cookie logic from the application server to the client-side application browser. It could allow an attacker to send unauthorized cookies with malicious intent.

Cookies Scoped to a Parent Domain

Risk level: LOW

Another layer of security for cookies involves restricting their access to only the applications with which they are intended to interact.

A cookie’s domain attribute determines which domains can access the cookie. Browsers will automatically submit the cookie in requests to in-scope domains, which will also be able to access the cookie. If a cookie is scoped to a parent domain, then that cookie will be accessible to the parent domain and also by any of its other subdomains.

If the cookie contains sensitive data (such as a session token) and is accessible to subdomains, then unauthorized persons could possibly gain access to the confidential information contained in the cookies. A subdomain is a child or member of a main domain. The main domain is called the root. For example, a root domain may be named abcd.com and a subdomain may be called childof.abc.com.

Weak Input Validation at the Application Level

Risk level: HIGH

Unauthorized access is the golden nugget for hackers, and strong protection against unauthorized access is strong validation of the identities of users requesting access to an application.

While it is common practice for web applications to verify access rights before making functionality visible in the user interface (UI), it should also be common practice to revalidate authentication at various important access points within an application.

If revalidation of the user ID and user requests are not verified, an attacker may be able to forge requests within an existing session in order to access unauthorized or privileged information.

For example, in a transaction-processing web application, a user may be required to first authenticate just for the privilege of gaining access to the application; a second time when she selects the transaction class she wishes to execute, such as buy, sell, trade, or look-up; and a third time to manage the movement of currency.

Lack of Validated Input Allowing Automatic Script Execution

Risk level: HIGH

All user input must be filtered to restrict any data not expected and wanted by an application. This includes any strings or groups of characters, especially control characters, which can be used to gain unauthorized privileges and control of the environment.

We have found quite the opposite to exist in real-world situations, where user input, such as messages, text, and data input into e-mail fields, was not validated or filtered before being accepted. This insecure manner of operation fails to prevent a malicious user from inserting malicious code into the input fields. An attacker could use this vulnerability to perform different attacks. These could include redirecting the user to a malicious web site where he may be tricked into inputting private information or a key logger using malicious code to steal authentication and other privileged material.

Unauthorized Access by Parameter Manipulation

Risk level: HIGH

This vulnerability involves having a potential security weakness to what is called a parameter manipulation attack. The problem is inherent in input fields, where too many choices of search parameters are given to users without sufficient controls over the parameters they may choose. This may allow a user unintended privileges in accessing parameters, such as session tokens, values stored in cookies, HTTP headers, and so on. A malicious user could exploit this vulnerability to access and gather data about other valid users. This could result in breaches to confidentiality and privacy.

A parameter manipulation attack compromises weak protection of data residing in a user’s browser, where that data should otherwise be invisible and unable to be changed by a user. The data can be session tokens, values stored in cookies, HTTP headers, or even prices in web carts.

Buffer Overflows

Risk level: HIGH

Buffer overflows are a high-risk vulnerability that are widely publicized and should be avoided.

Web applications may be vulnerable to buffer overflows, which occur when a program attempts to store more data in a static buffer than it is designed to manage. The additional data overwrites and corrupts memory, allowing an attacker to insert arbitrary instructions on the web server or crash the system. For additional clarity, a buffer overflow is an error that may occur when a program writes more data than expected to a buffer or space allocated for an expected amount of data. The excess data overruns the buffer’s boundary and overwrites adjacent memory. If this violation is allowed to occur, it can permit a hacker to inject instructions and compromise an environment.

Applications may be susceptible to the insertion of too much data, which may cause a memory overflow. This may allow dangerous instructions to be input. For example, a hacker may enter a command line executable statement such as

<! —exec%20cmd="/bin/cat%20/etc/passwd"—>

into a legitimate web site form under the guise of an HTTP request to gain access to the web server. If security configuration allows, the hacker will receive the /etc/passwd file and gain access to files and, ultimately, the usernames and passwords stored on the web server.

Forms Submitted Using the GET Method

Risk level: HIGH

This vulnerability is almost identical to the previously discussed vulnerability of submitting data using the GET method. In this case, an entire form is submitted using the GET method.

This is a common security vulnerability we see, where a number of the web forms are submitted using the GET method. The GET method is considered insecure because it visibly presents the submitted parameters and their values in the browser address bar. A malicious user can exploit this vulnerability and perform a man-in-the-middle attack, where she uses the visible information to impersonate either the browser to the web application or the web application to the browser. An attacker could also do a parameter manipulation attack by manipulating parameters within the visible URL text to gain access to unauthorized data.

Redirects and Forwards to Insecure Sites

Risk level: LOW-MEDIUM

A session being redirected to an insecure web site is even more serious than users surfing to the same dangerous page on their own, simply because there is an implied trust relationship between the user and the page doing the redirecting.

Web applications frequently redirect and forward users to other pages and web sites and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorized pages.

Maliciously installed redirects may attempt to install malware or trick victims into disclosing passwords or other sensitive information and may facilitate the bypass of access control by an attacker.

Application Susceptible to Brute-Force Attacks

Risk level: LOW

This vulnerability arises when the application code does not stop a potentially malicious user from gaining unauthorized access after a certain number of failed authentication attempts, simply by denying access for a period of time or forever.

If the attacker’s false login attempts are not restricted after several attempts, the attacker can proceed to discover a successful username and password combination and use it to impersonate the account’s legitimate user, thereby gaining unauthorized access to the application.

Client-Side Enforcement of Server-Side Security

Risk level: MEDIUM

When validation is performed on the client side, security is always affected to some extent because it allows for much less control than when it is enforced on the server side.

If a server relies on validation mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms, resulting in potentially unexpected interactions between the client and server. The consequences will vary depending on what the mechanisms are trying to protect.

Injection Flaws

Risk level: HIGH

Injection vulnerability is caused by a lack of sufficient filtering or testing of data; that is, input from a client. All data other than expected items such as size, type, and character type should be rejected by the web application immediately.

This is a class of attacks that relies on injecting data into a web application in order to facilitate the execution or interpretation of malicious data in an unexpected manner. Examples of attacks within this class include cross-site scripting (XSS), SQL injection, header injection, and many more. They result in running malicious code to steal and compromise data.

Malicious instructions are included with user data and sent as part of a command or query to an interpreter, which is a program used to convert high-level language commands into machine-readable binary language, in a line-by-line fashion, in near real time as part of a command or query. The attacker’s hostile instructions can trick the interpreter into executing unintended commands or accessing data without proper authorization.

In these attacks, the victims are web applications and the databases behind them, but can also include the users of a vulnerable web site.

Five different injection vulnerabilities follow.

SQL Injection

Risk level: HIGH

A SQL injection is one of several types of injection vulnerabilities, which allows malicious SQL statements  and queries to be submitted to a web application without the web application stripping them out.

Many web applications do not properly strip user input of unnecessary special characters, such as string literal escape characters, nor do they validate information contained in a web request before making SQL queries. SQL injection is an attack technique that takes advantage of a security vulnerability in a web application to extract or alter data within the database management system, which resides at the back end of the web application. The data may come from an input field on a client’s web browser as part of a command or request. The data is then used for doing SQL queries or executing commands in a back-end database that are never intended to occur in normal activity. If the vulnerability to this attack allows the database to respond to the malicious instructions, the database is compromised. A less direct attack injects malicious code into strings that will be kept in a table for future reference. When the stored strings are subsequently used in an SQL command, the malicious code is executed.

Such attacks can result in access to unauthorized data, bypassing of authentication, or the shutting down of a database regardless of whether the database resides on the web server or a separate server.

Blind SQL Injection

Risk level: HIGH

A blind SQL injection is another flavor of an injection vulnerability, where a web application does not filter or restrict requests for more information from the back-end database. These types of requests should be very closely filtered by developers.

Blind SQL injection differs from a normal SQL injection in the way the data is retrieved from the database. When the database does not output data to the web page and instead displays an error message about the syntax of the query, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL injection vulnerability more difficult, but still possible.

The risks are the same as for other SQL injection attacks.

Link Injection

Risk level: HIGH

This attack occurs when a malicious user is allowed to input code that contains carriage return (CR) and line feed (LF) characters into an HTTP RESPONSE header. After the characters are injected, the attacker makes space in the header to write their own malicious code. The malicious data in the HTTP header is then passed to the web application via the client’s browser.

This vulnerability facilitates a cross-site request forgery attack, which is covered later in this chapter.

HTTP Header Injection Vulnerability

Risk level: HIGH

An HTTP header injection vulnerability occurs when HTTP headers are created on the fly based upon user input. This vulnerability occurs if strict filtering is not put in place to restrict malicious characters. The vulnerability can allow for the HTTP response-splitting attack to occur. An HTTP response header includes detailed information about an HTTP sent or received message, which a typical user never sees but is quite available to view on a browser. Viewing the header information is accomplished either by using the appropriate command or getting the appropriate viewing tool for any web browser.

HTTP Response-Splitting Attack

Risk level: HIGH

The HTTP response-splitting attack compromises the HTTP header and is another member of the injection vulnerability class. It occurs when insufficient filtering allows the carriage return (CR) character and line feed (LF) character to be entered into the HTTP header if the underlying environment is vulnerable to these characters. If attackers can inject CR or LF line characters into the header, then they can also inject new HTTP headers and write arbitrary content into the application’s response.

An attacker can exploit this vulnerability to mount an attack using multiple attack vectors. This type of attack can lead to a full systems compromise and loss of confidentiality, integrity, and availability.

Any attack that can be delivered via cross-site scripting can usually also be delivered via header injection because the attacker can construct a request that causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage header injection vulnerabilities to poison the cache of any proxy server through which users access the application. Here, an attacker sends a crafted request that results in a “split” response containing arbitrary content. JavaScript is a scripting language developed by Netscape to enable web authors to design interactive sites. It shares many of the features and structures of the full Java language but it also can interact with HTML source code, enabling dynamic content to be created.

If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a “stored” attack against this URL that will compromise other users who request that URL in the future.

Unauthorized View of Data

Risk level: LOW-HIGH

This is a common vulnerability, where sensitive information about the web application environment is disclosed. This can assist a hacker in probing for more sensitive data in preparation for an attack. The vulnerability arises when an unauthorized user identifies an object such as a server or file name by a specific name. An indirect reference is done by providing an alias name to the server or file, such as a number value or a description of what the device does. This way, users only see alias names and the application environment translates between alias names and real object names. If authorization for each user is not verified prior to accessing an object, a malicious party could gain confidential information about the environment, sufficient to plan an attack.

In actual audit situations, we have seen this particular problem, with web application pages using the formal names of objects. Without an access control check or other protection, attackers can manipulate these references and guess names of other objects in order to access unauthorized data. This vulnerability can be compromised by both an authorized and unauthorized user.

Web Application Source Code Disclosure

Risk level: LOW

This is a similar vulnerability to unauthorized view of data, but in this case it is specifically related to actually revealing pieces of source code. Source code is the set of instructions written in a programming language that regulate what an application does and how it should operate. Application source code should not be accessible to web users, as it may contain sensitive application information and back-end logic. This is not an unusual occurrence, as we detected responses containing fragments of application source code during separate audits.

While such leakage does not necessarily represent a breach in security, it can give an attacker useful guidance for future exploitation. Leakage of sensitive data may carry various levels of risk and should be limited whenever possible.

Web Directories Enumerated

Risk level: LOW

This unauthorized view is specifically related to web directories and involves confidential information pertaining to names of directories and their subdirectories being made available to users. This information, in the hands of a malicious person, can be used to plan an attack.

It is often the case when we do vulnerability scans of external IP addresses that we are able to enumerate several web directories. An attacker would most likely focus on these directories (especially the ones with names that reveal the function of objects within each directory) and try to fine-tune an attack accordingly.

Active Directory Object Default Page on Server

Risk level: LOW

An Active Directory object default page contains information that should only be seen by the developers of a web application environment, but definitely not by web application users. This information can be inadvertently revealed to users as the result of incorrect parameter settings by developers.

Active Directory is a very widely used Microsoft Windows service that provides a way to view and organize all the network resources, particularly for a complex and large environment, in a digestible manner. Active Directory objects are all the bits and pieces that the service organizes, such as users, computers, groups of users, supersets of groups of users called organizational units (OU), and so on.

A malicious party could build on information details about network devices and the application to fine-tune an attack. This reduces an attacker’s workload by reducing the attack scope and risk of detection while increasing the probability of a successful attack.

Temporary Files Left in the Environment

Risk level: LOW

Here is another example of sensitive information being inadvertently made available to a potential hacker and becoming a security vulnerability. In this case, the knowledge relates to temporary files. Web application users can gain access to pages containing temporary files simply by exploring web links. Although the temporary files are required by the application, they should be accessible only to authorized users. Temporary files are files typically used during an update or editing process. Once the process is complete, the user saves the changes and the files get closed or deleted. However, if there are of unplanned activities, such as restarting a computer or turning it off during an active Windows session, the files may get left in the environment.

If the temporary files are found by a malicious party, confidential data may be revealed. Further, if any of the temporary files can be written to by an attacker, malicious code can be injected into it, and it may be vulnerable to being moved to a location that inherently gives the attacker more access privileges. Finally, the script files for a temporary file may reveal the application logic and other sensitive information such as usernames and passwords.

Internal IP Address Revealed by Web Server

Risk level: MEDIUM

This is the old story of too much information being revealed to an unintended, unauthorized individual. In this case, an IP address is the item of concern and could be used by a hacker to build an attack.

For example, if a web server is misconfigured and identifies its internal IP address in an HTTP header field, that IP address could allow unauthorized parties to learn potentially dangerous information about the corporate network.

If an attacker knows the address space of the internal network, she may be able to craft packets to get around network protection (firewall, intrusion detection systems/intrusion prevention systems) and get access to the insecure internal network.

Server Path Disclosed

Risk level: MEDIUM

Another instance of otherwise-confidential information being revealed to any unauthorized individual, in this case a literal file path is disclosed and could be used by a hacker to build an attack.

For example, an HTTP response containing a file’s absolute path (e.g., c:dirfile in Windows or /dir/file in UNIX) may be clearly visible. An unauthorized party may be able to exploit this information to access sensitive data on the directory structure of the server machine, which it could then use for further attacks against the site.

Information such as the location of files on the server as well as directory structure may be extremely beneficial for an attacker. It could allow the attacker to craft and fine-tune an attack that will have a higher probability of success while reducing the effort and elapsed time required to execute it.

Hidden Directory Detected

Risk level: LOW

Hidden directories are another type of directory information, which are intended for viewing only by developers and have no business in the hands of web application users. They are a directory (folder), such as an Active Directory or other types of directories, that file system utilities do not display by default. They are commonly used for storing user preferences and the states of various tools or utilities.

The web application exposes the presence of the hidden directory on the web application server by issuing a 403 Forbidden Response code in response to users attempting to access this directory without having access authorization.

Although the directory does not list its content, any available pieces of data could reveal sufficient information for an attacker to develop an attack against the site. For example, by knowing the directory name, an attacker could guess the content type and possibly file names that reside in it, or subdirectories under it, and try to access them.

Unencrypted VIEWSTATE

Risk level: HIGH

Here is another instance of revealing too much information, in this case unencrypted confidential data sent by a browser to its server. As a reminder, VIEWSTATE is a temporary storage that allows ASP.NET users to store all the temporary information about a web page, such as which panels are open and in use, the options that are currently chosen, the current data in each text box, and even the data for other information.

During an audit, we were able to see confidential material from the browser session being sent back to the application in an unencrypted view state. Therefore, any user can see information for which he does not have sufficient authorization.

Obsolete Web Server

Risk level: MEDIUM

Obsolete servers can be more vulnerable to attacks since they do not have the most up-to-date security protection. An attacker could exploit this vulnerability to mount an attack focused on known vulnerabilities in outdated versions of the web site platform. Such an attack has a higher likelihood of success on this version than on a more secure version.

There are just too many real-life examples of this occurring, not only for web servers but for all manner of servers.

Query Parameter in SSL Request

Risk level: MEDIUM

This is another variation of a vulnerability that can occur when developers use the GET command instead of using other commands such as POST, which presents fewer security risks. The GET method allows for requests to be stored in a browser’s history.

A vulnerability arises when the browser’s history is used to reveal the URLs containing the query parameter names and values. If these names and values are not confidential, then the confidential information is available to unauthorized parties.

During several web application vulnerability tests, we found HTTP GET requests in browser histories that contained parameters containing confidential information.

Error Handling

Risk level: HIGH

This is a variation on the theme of revealing what may appear to be innocuous information to unauthorized parties. In reality, a competent hacker may be able to leverage the information while preparing an attack.

A malicious party may intentionally submit abnormal data in order to force error messages. An attacker could use generic error messages such as “Username incorrect” and “Password incorrect” or hidden files and directories to plan an attack.

Cross-Site Scripting Attacks

Risk level: HIGH

Cross–site scripting (XSS) attacks receive a lot of news coverage, principally because of the dramatic increase in the use of scripting languages. The same-old problems creep up even in these relatively new scripting languages—insufficient filtering of input data from users and, conversely, banning all but expected types of data.

This XSS vulnerability is caused by flaws in client-side scripting languages such as JavaScript and the HTML scripting language. It can arise when web applications accept input data from users and dynamically include it in web pages without properly validating it first. XSS vulnerabilities allow an attacker to execute arbitrary commands and display arbitrary content in a user’s browser. In the victim’s browser, the malicious code appears to be a legitimate part of a web site and causes it to act as an unintentional accomplice to the attacker.

Cross-site scripting is the most prevalent web application security flaw. XSS flaws occur when an application includes user-supplied data in a page sent to the browser without properly validating or rejecting it. There are three known types of XSS flaws:

• stored
• reflected
• DOM based

The consequences of an XSS attack are the same regardless of the type of flaw, with the difference between them only in how the payload arrives at the server.

The damaging results of the XSS attack include: user sessions being hijacked to steal or to change confidential information, defacement of web sites, insertion of hostile content, redirection of users, disclosure of the end user’s session token, and the platform on which the user’s browser is running being attacked.

Reflected Cross-Site Scripting Attack

Risk level: HIGH

In a reflected XSS attack, malicious data enters a client’s browser by the browser making a request to a compromised web site. The browser becomes infected with malicious malware code. When the client then accesses its trusted web application, the malware on the browser secretly requests personal information from the web site. The web site sends or reflects the data to the compromised browser, which in turn sends the personal information to the attacker.

The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to the victim. URLs constructed in this manner constitute the core of many phishing schemes, involving an attacker convincing a victim to visit a URL that refers her to a vulnerable site. Once the victim is on the site, the attacker will cause malicious code to execute within the user’s browser.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim’s session token or login credentials, performing arbitrary actions on the victim’s behalf, and logging her keystrokes. The attacker can induce a user to issue his crafted request by:

• Requesting the transfer of private information, such as cookies that include session data, from the victim’s computer to that of the attacker, who then can hijack the session
• Sending malicious requests to a web site, which could be especially dangerous if the victim has administrator privileges
• Conducting phishing attacks that emulate trusted web sites and trick the victim into entering a password, allowing the attacker to compromise the victim’s account
• Exploiting browser vulnerabilities that enable the attacker to take over the victim’s computer (drive-by hacking)

Stored Cross-Site Scripting Attack

Risk level: HIGH

In this attack, the malicious code is stored permanently on the compromised web application, such as in the back-end database. In a compromise situation, when a client’s browser retrieves information from the compromised web site, it also retrieves malware. In this case, there are two sets of victims: the compromised web site and the visitors to the compromised web site. The order of the attack sequence is:

1. The attacker inserts malicious code into a web application.
2. The victim, who is a client of the web site, requests a page from the web site.
3. The compromised web site unwittingly sends the malicious code to its client’s browser.
4. The compromised client’s browser sends confidential information back to the attacker’s server.

Cross-Site Request Forgery Attack

Risk level: HIGH

Cross-site request forgery (CSRF) is yet another vulnerability caused by insufficient filtering of data input into a web application. This complex attack dupes a browser into being an unwitting participant in an attack against an otherwise-trusted web site. This type of attack sounds like the XSS attack just defined. However, it differs from XSS in that here the attacker uses the victim’s browser as a conduit through which to send malicious instructions to a web application currently authenticating the victim. In this case, there are two concurrent victims:

• the client whose browser is being remotely controlled by the attacker, who is an unwitting participant in the attack
• the trusted web site to which the client browser is authenticated, which is the ultimate victim of the attack

The CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, which includes the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. The attacker forces the victim’s browser to generate seemingly legitimate requests and send them to the vulnerable application. In the security world, a cookie is used as a messenger to carry session identification data related to a specific session. The session identification is called a session cookie or session token or session identifier.

CSRF takes advantage of the fact that most web apps allow potential attackers to predict all the details of a particular action. Since browsers send credentials like session cookies automatically, attackers can create malicious web pages that generate forged requests indistinguishable from the legitimate ones.

Security Misconfigurations and Use of Known Vulnerable Components

Risk level: MEDIUM

It is imperative for operations teams dealing with web applications to ensure their configurations of hardware and software are free of known vulnerabilities. However, we have commonly seen misconfigurations that expose web applications to threats. This issue is exacerbated because there is a huge volume of documented security vulnerabilities, primarily published in good faith for the benefit of protecting applications and networks but also serving as guidance for hackers. Off-the-shelf and widely available software components such as libraries, frameworks, and other software modules can have security weaknesses that are able to be exploited by parties with malicious intent. The problem is exacerbated if these components run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. This is a common problem, as few development teams focus on ensuring that their components/libraries are up to date.

The full range of weaknesses is therefore possible, including injection, broken access control, cross-site scripting, and so forth. The impact could range from minimal to complete host takeover and data compromise.

Denial-of-Service Attack

Risk level: HIGH

Many web applications are vulnerable to denial-of-service (DoS) attacks that can dramatically curtail access or even result in a total shutdown of the affected network. Attackers can use various mechanisms to launch a DOS attack, such as sending many TCP requests and using an Internet control message protocol (ICMP) to flood a device with ping requests. ICMP is a fundamental Internet protocol; in this case, it is used by devices on a network to send error and control messages back and forth to each other. ICMP flooding is malicious use of the ICMP protocol to deluge a target device with so many messages as to overwhelm its ability to respond or to therefore properly function.

Excessive numbers of TCP and ICMP ping requests, which are simply various flavors of Internet traffic, are very high generators of unnecessary traffic. When used as designed, these protocols work well; misused, they are tools for DoS attacks. DoS attacks may be simple, such as repeated requests for a single URL from a single source, or more complex, such as a coordinated effort from multiple machines or botnets to barrage the URL.

Related Security Issues

Risk level: HIGH

There are several security issues that can be sources of the previous vulnerabilities of which users should be aware.

Storage of Data at Rest

Risk level: HIGH

People are very concerned about data in motion, such as data and web sites, being compromised during transactions. However, there is also an entire class of vulnerabilities associated with data at rest, such as the security used to store data associated with web applications.

Many web application logs contain sensitive information, such as passwords, session IDs, web server requests, and statistics, and by default many applications provide logs that detail the product’s installation data. These logs and other sensitive files may be stored on the web server or back-end database and hackers can retrieve them to perform unauthorized functions, view their content, or compromise the resource.

Storage of Account Lists

Risk level: HIGH

Hackers can also use account information to plan an attack. Identifying usernames by their accounts is a strong tool to leverage if this opportunity presents itself.

Here are several real-life examples of vulnerabilities associated with account information we obtained during the course of one audit:

• an account list stored in a file with minimum security controls
• an account list containing many stale accounts, including previous employees and contractors no longer providing services for the company
• the event log for an account file indicating several failed attempts by existing employees at logging into stale accounts

Password Storage

Risk level: HIGH

Gaining valid credentials for an application is bread and butter for a hacker. The ability to gain even hints about how passwords are built and stored is valuable for a hacker who is building an attack.

Most applications have a password recovery system that is activated by clicking on the password reminder link. This identifies the fact that passwords are stored or encrypted as plain text. This unsecure form of storage may allow an attacker to gain access to passwords, which, in combination with a valid username, could provide unauthorized access to confidential corporate information including a client’s personal and sensitive data.

Since this type of application is also susceptible to SQL injection, the password list is definitely at risk. A successful SQL injection attack would make the plain text or encrypted passwords vulnerable to exposure.

Insufficient Patch Management

Risk level: HIGH

One of the most common and high-risk activities an operations team can commit is to not install security-related patches in a timely manner. Since descriptions of vulnerabilities and their associated patches or corrections are widely published to assist with security, the same information is just as available to potential hackers.

During the network-vulnerability portion of our audit, we identified out-of-date revision levels in several third-party software platforms associated with the web application environment.

This may be indicative of an insufficient patch-management process. Since insufficient/insecure patches result in a very large percentage of web application vulnerabilities, this section needs to be included as part of a web application vulnerability list.

Summary

There are many well-known and clearly documented classes of web application vulnerabilities. Each class of vulnerability contains well-documented members of its class.

There will undoubtedly be more classes and class members that evolve right along with changes in web application infrastructure and the progression of creative cyberattacks. The cyberattackers will in turn create threats to compromise these vulnerabilities, thereby creating new risk.

The documented remediations for all these classes and class members are the subject of Chapter 4.