Finding Security Gaps in Your Application with OWASP ZAP Tool

Recently, we had a great opportunity to implement the OWASP security standards for the applications we have been developing for our client – a fleet management and driver mobility company.

The requirement was to secure the applications according to Levels 1 and 2 of the Application Security Verification Standard (ASVS).

ASVS defines security verification levels, with each level increasing in depth. ASVS Level 1 is meant for any software. ASVS Level 2 concerns applications that contain sensitive data which require protection.

Level 1: Opportunistic

An application achieves ASVS Level 1 if it is adequately defended against application security vulnerabilities, which are easy to discover, and included in the OWASP Top 10, such as Injection, Broken Authentication and Session Management, Cross-Site Scripting (XXS), or Cross-Site Request.

Level 2: Standard

Level 2 ensures that security controls are in place. Level 2 is typically appropriate for applications, which handle significant business-to-business transactions, including those that process healthcare information or process sensitive assets.

Source: Application Security Verification Standard 3.0

SQL Injection

According to the official list of the TOP 10 Most Critical Web Application Security Risks of 2013, Injections such as SQL, OS and LDAP are at the top of the list. Injections pose the greatest risk and are also highly used by attackers to pull out the most sensitive and valuable data from the application.

SQL Injections can destroy an application’s database. An SQL injection is a technique in which malicious attackers can inject SQL commands into an SQL statement via web page input. Injected SQL commands can alter SQL statements and compromise the security of a web application.

Simple Example

The original purpose of the code was to create an SQL statement to receive a user with a specified ID.

If there is nothing to prevent the user from entering undesirable input, an attacker can enter dangerous input in the application, as below:

UserId:
105 or 1=1

On the server side, it will result in the following statement:

SELECT * FROM Users WHERE UserId = 105 OR 1=1

The example of the SQL is valid. It will return all rows from the table ‘Users’ with the condition WHERE 1=1 is true.
Does it seem dangerous? What if the table ‘Users’, contained users’ names and passwords?

Just as well, the statement could be the following:

SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1

OWASP ZAP

If you think about a situation in which, as a tester, you need to check all the fields of the application where a user can introduce data and run a statement to the database, it seems a huge task.

Fortunately, a tool called OWASP ZAP can be used for testing whether applications possess security gaps and whether security checks have been implemented efficiently. It enables you to improve the speed and effectiveness of testing.

OWASP ZAP (also OWASP Zed Attack Proxy) is one of the world’s most popular free security testing tools. It can help to automatically find security vulnerabilities in web applications.

You can download OWASP ZAP for free here.

Among the dozens of functionalities, which OWASP ZAP provides to test the security of an application, there is one which is used for testing against SQL Injections.

Setting up OWASP ZAP for browser

Before testing can start, it is necessary to set up the application and configure your browser:

1. Install and open the application.
2. Select Tools ➝ Options ➝ Dynamic SSL Certificates and click the ‘Generate’ button.
3. Accept the ‘Overwrite existing certificate?’ pop-up.
4. Click the Save button and save the file in a location you will remember.
5. Now, you need to import the certificate to your browser (Firefox recommended).
6. Select Preferences ➝ Advanced ➝ Certificates in your browser.
7. Select View Certificates ➝ Import and select the certificate you had previously generated.
8. Mark all the checkboxes and click OK.
9. When the certificate has been imported, you have to set ZAP as the proxy which will be used to pass all the traffic going through the browser.
10. Select Preferences ➝ Advanced ➝ Network tab ➝ Settings.
11. Choose the ‘Manual proxy configuration:’ radio button in the Connection Settings popup.
12. Insert the HTTP Proxy data: localhost / Port: 8080
13. Mark the ‘Use this proxy server for all protocols’ check box and click OK.
14. Your browser should now be correctly configured.
15. When you go to OWASP ZAP, you will notice a ‘Sites’ button in the upper left corner.
16. Go back to your Browser and open any webpage.
17. Go back to OWASP ZAP and you will notice a number of websites showing up under ‘Sites’.
18. At this point, you are able to see all the websites and resources that have been requested as well as the responses.

Fuzzing for SQL Injection Flaws with OWASP ZAP

When your browser is configured and the proxy is correctly set, you are ready to use the OWASP ZAP tool:

1. In your application, find the field where you can send the POST request.
2. After sending the POST request in your web application, go back to OWASP ZAP.
3. In the History tab, you will see your POST request and, above it, the value which has been entered in the POST request; in this case ‘name=Rake’.
   

   OWASP ZAP POST request

4. Mark the content ‘Rake’, Right-click on it and click ‘Fuzz…’.
   
5. A new window will be displayed. Again, mark ‘Rake’ and click ‘Add…’.
   
6. The ‘Payloads’ window will be displayed, in which you need to click the ‘Add…’ button again.
7. Choose ‘File Fuzzers’ from the ‘Type:’ dropdown in the ‘Add payload’ window.
8. Expand the ‘jbrofuzz’ list and mark the two checkboxes labelled ‘Injection’ and ‘SQL Injection’ from the expanded list. Click on the ‘Add’ button.
   
9. In the ‘Payloads’ window click the “OK” button.
10. In the ‘Fuzzer’ window click the ‘Start Fuzzer’ button.
11. In the ‘Fuzzer’ tab, you can see that the field, in which the POST request has been executed, is now being attacked by dozens of SQL requests that may be potentially dangerous for your application.
    Requests with the ‘Reflected’ status in the ‘State’ column are safe for the application – the rest, however, may be not.
    

To be 100% sure that your application is protected against SQL injections, it would be perfect to attack the application with all potentially dangerous requests and see how it reacts.

Thanks to OWASP ZAP, you will be able to discover the vulnerabilities of your application, which leads to a higher level of safety after creating the appropriate securities.