Evaluating Input Validation Checks

Failure to validate any input received from the client before using it in the application code is one of the most common security vulnerabilities found in web applications. This flaw is the source of major security issues, such as SQL injection and Cross-Site Scripting (XSS). Web penetration testers must evaluate and determine whether any input is reflected back or executed upon by the application. We’ll learn how to use Burp Suite to perform such tests.

In this chapter, we will cover the following recipes:

• Testing for reflected cross-site scripting
• Testing for stored cross-site scripting
• Testing for HTTP verb tampering
• Testing for HTTP parameter pollution
• Testing for SQL injection
• Testing for command injection

Technical requirements

To complete the recipes in this chapter, you will need the following:

• OWASP Broken Web Applications (VM)
• OWASP Mutillidae link
• Burp Suite Proxy Community or Professional (https://portswigger.net/burp/)

Testing for reflected cross-site scripting

Reflected cross-site scripting occurs when malicious JavaScript is injected into an input field, parameter, or header and, after returning from the web server, is executed within the browser. Reflected XSS occurs when the execution of JavaScript reflects in the browser only and is not a permanent part of the web page. Penetration testers need to test all client values sent to the web server to determine whether XSS is possible.

Getting ready

Using OWASP Mutillidae II, let’s determine whether the application protects against reflected XSS.

How to do it...

1. From the OWASP Mutillidae II menu, select Login by navigating to OWASP 2013 | A3 - Cross Site Scripting (XSS) | Reflected (First Order) | Pen Test Tool Lookup:

Figure 8.1 – Multillidae landing page

2. Select a tool from the drop-down listing and click the Lookup Tool button. Any value from the drop-down list will work for this...

Testing for stored cross-site scripting

Stored cross-site scripting occurs when malicious JavaScript is injected into an input field, parameter, or header and, after returning from the web server, is executed within the browser and becomes a permanent part of the page. Stored XSS occurs when the malicious JavaScript is stored in the database and is used later to populate the display of a web page. Penetration testers need to test all client values sent to the web server to determine whether XSS is possible.

Getting ready

Using OWASP Mutillidae II, let’s determine whether the application protects against stored cross-site scripting.

How to do it...

1. From the OWASP Mutillidae II menu, select Login by navigating to OWASP 2013 | A3 - Cross Site Scripting (XSS) | Persistent (First Order) | Add to your blog:

Figure 8.9 – Navigation to the stored XSS lesson

2. Place some verbiage into the text area. Before clicking the Save...

Testing for HTTP verb tampering

HTTP requests can include methods beyond GET and POST. As a penetration tester, it is important to determine which other HTTP verbs (that is, methods) the web server allows. Support for other verbs may disclose sensitive information (for example, TRACE) or allow for a dangerous invocation of application code (for example, DELETE). Let’s see how Burp Suite can help test for HTTP verb tampering.

Getting ready

Using Altoro Mutual (https://demo.testfire.net), let’s determine whether the application has a POST request we can manipulate into using a GET instead. If possible, the GET request will expose sensitive data within the query string. We will login first, then map the application to look for something interesting like a money movement transaction.

How to do it...

1. Navigate to https://demo.testfire.net. Click the Sign In button.

Figure 8.12 – Altoro Mutual landing page

You are brought...

Testing for HTTP parameter pollution

HTTP parameter pollution (HPP) is an attack in which multiple HTTP parameters are sent to the web server with the same name. The intention is to determine whether the application responds in an unanticipated manner, allowing exploitation. For example, in a GET request, additional parameters can be added to the query string—in this fashion: "&name=value"—where name is a duplicate parameter name already known by the application code. Likewise, HPP attacks can be performed on POST requests by duplicating a parameter name in the POST body data.

Getting ready

Using OWASP Mutillidae II, let’s determine whether the application allows HPP attacks.

How to do it...

1. From the OWASP Mutillidae II menu, select Login by navigating to OWASP 2013 | A1 - Injection (Other) | HTTP Parameter Pollution | Poll Question:

Figure 8.21 – Navigate to the HTTP Parameter Pollution lesson...

Testing for SQL injection

A SQL injection attack involves an attacker providing input to the database, which is received and used without any validation or sanitization. The result is divulging sensitive data, modifying data, or even bypassing authentication mechanisms.

Getting ready

Using the OWASP Mutillidae II Login page, let’s determine whether the application is vulnerable to SQL injection (SQLi) attacks.

How to do it...

1. From the OWASP Mutillidae II menu, select Login by navigating to OWASP 2013 | A1-Injection (SQL) | SQLi – Bypass Authentication | Login:

Figure 8.25 – Navigate to the SQL injection authentication bypass lesson

2. On the Login screen, place invalid credentials in the Username and Password textboxes. For example, the username is ' or 1=1-- with no password. Click the Login button.

Figure 8.26 – Login using SQLi payload

3. Switch to the Burp Suite...

Testing for command injection

Command injection involves an attacker attempting to invoke a system command, normally performed in a terminal session, within an HTTP request instead. Many web applications allow system commands through the UI for troubleshooting purposes. A web penetration tester must test whether the web page allows further commands on the system that should normally be restricted.

Getting ready

For this recipe, you will need the SecLists payload for Unix commands on a Unix- or Linux-based operating system:

https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/UnixAttacks.fuzzdb.txt

Download the SecLists payload from GitHub:

https://github.com/danielmiessler/SecLists

Using the OWASP Mutillidae II DNS Lookup page, let’s determine whether the application is vulnerable to command injection attacks.

How to do it...

1. From the OWASP Mutillidae II menu, select DNS Lookup by navigating to OWASP 2013 | A1-Injection (Other) | Command...