How to Abuse Session Management with OWASP ZAP

It's always a good idea to know how an attack works at the very basic level. Manual techniques for exploitation often find holes that even the most sophisticated tool cannot. Sometimes, though, using one of these tools can make things so much easier, especially if one has a solid foundation of how it works. One such tool can help us perform a cross-site request forgery with minimal difficulty.

Previously: How to Manipulate User Credentials with a CSRF Attack

Introduction to OWASP ZAP

The OWASP Zed Attack Proxy (ZAP) is a popular open-source web application security scanner maintained by the OWASP project. It is a Java-based tool that provides a handy GUI and is included by default on Kali Linux. In addition to its powerful scanner that can automatically detect many vulnerabilities, it also contains many useful features for manual testing such as spidering, fuzzing, and proxying.

How to Abuse Session Management with OWASP ZAP

The right-hand section of ZAP contains the scanner functionality, where all one has to do is enter a valid URL and click "Attack." This section is also where the details of individual requests and responses can be viewed.

The left-hand section features the layout of a website once it has been scanned or spidered; This is useful for separating individual pages and getting a broad overview of a site's content. Finally, the bottom section of ZAP contains request history, search, and any alerts that might pop up during a scan.

Don't Miss: How to Use OWASP ZAP to Find Vulnerabilities in Web Apps

In this tutorial, we will be using ZAP as a proxy to intercept traffic. Once our browser is set to the manual proxy configuration, ZAP will automatically start acting as a proxy; This makes it easy to view and modify any requests that are coming from the application we are testing.

Step 1: Configure the Environment

For this demonstration, we will be using the vulnerable web application Mutillidae, which is included as part of the Metasploitable 2 virtual machine. OWASP ZAP will be used to intercept any requests and modify them to perform CSRF.

To replicate this attack, we will need to set up two different users. Create a new account for each of the two users by browsing to the following page, using the appropriate IP address:

http://172.16.1.102/mutillidae/index.php?page=register.php

Here we can register user1 with the password password:

And similarly, user2 with the password hunter2:

Now we can sign in as user1 by visiting the login page:

Before we launch ZAP, we will need to make sure that our browser is configured correctly to intercept traffic. In Firefox, go to "Preferences," click on "Advanced," followed by "Network," and finally "Settings." Set the proxy configuration to manual and use 127.0.0.1 (localhost) on port 80. Check "Use this proxy server for all protocols" and ensure that there is nothing listed under "No proxy for." Now hit "OK," and we're ready to open ZAP.

Step 2: Open Up ZAP

When we fire up ZAP, we're met with a few persistence options. For now, we can just accept the default which does not persist the session:

Now, back in our web app, browse to the following URL to add a blog entry for user1:

http://172.16.1.102/mutillidae/index.php?page=add-to-your-blog.php

Type in whatever you wish here, and click "Save Blog Entry" to add the blog:

Since ZAP is already listening as a proxy, we can see that this request shows up near the bottom of the window:

This contains information such as the URL, server response code, size of the request, and method used to communicate with the server. Looking in the upper right-hand corner of ZAP, we can view the request by clicking on the "Request" tab:

This gives us a little more information including any cookies or tokens in use as well as the text that we submitted to the blog.

Step 3: Launch the CSRF Attack

In the previous tutorial, we learned how to modify HTML to create a new file used to trick unsuspecting users into submitting malicious data on our behalf. ZAP is useful as it pertains to CSRF in that it has a feature that will essentially take care of this for us automatically.

Please note that this feature generates a demo form for us to use. A more realistic approach would be to modify the demo form to submit automatically when it is loaded, as we did in the previous article; Essentially, these are two methods to accomplish the same goal.

Back towards the bottom of ZAP, right-click on the request and select "Generate anti CSRF test FORM," which will open up in a new tab:

This contains the parameters and values of the POST request and can be modified by an attacker. To carry out this attack, JavaScript can be used to make this form submit automatically when it is loaded:

<html>
<head>

<script language="javascript">
function autoSubmit() {
        document.getElementById("f1").submit();
}
</script>

</head>
<body onload="autoSubmit()">

<h3>http://172.16.1.102/mutillidae/index.php?page=add-to-your-blog.php</h3><form id="f1" method="POST" action="http://172.16.1.102/mutillidae/index.php?page=add-to-your-blog.php">
<table>
<tr><td>
add-to-your-blog-php-submit-button<td><input name="add-to-your-blog-php-submit-button" value="Save Blog Entry" size="100"></tr>
<tr><td>
blog_entry<td><input name="blog_entry" value="This is my first blog entry!" size="100"></tr>
<tr><td>
csrf-token<td><input name="csrf-token" value="SecurityIsDisabled" size="100"></tr>
</table>
<input id="submit" type="submit" value="Submit"/>
</form>

</body>
</html>

This example is merely a simple blog entry, but a more malicious attack could target banking information or other private information.

Next, we can return to the login page and sign in as user2, who will simulate the victim of this attack. In reality, this would be a random other user, but for demonstration purposes, we will need to sign in and play the victim. Once the form is loaded and the request goes through, we can see that user1's blog entry shows up under user2's current entries:

Again, nothing malicious here, but improper session handling has been abused to forge a cross-site request. If this application contained more sensitive data, an attacker could quickly take advantage of this vulnerability for personal or financial gain.

Closing Remarks

OWASP ZAP is a powerful tool used for testing web applications for common vulnerabilities. In this guide, we learned how to take advantage of one of its many features used for manual testing in order to intercept traffic and perform a CSRF attack. While this example was trivial since we only exploited a simple blog entry, real-world scenarios can be much more devastating, especially when personal or financial data is involved.

In the 2017 edition of the OWASP Top 10, CSRF was omitted as one of the most critical web application security risks. In large part, this is due to the shift in many applications being developed using frameworks which automatically include protection against CSRF attacks. But even though it was dropped from the top ten list, CSRF still remains a legitimate security concern to this day. There are just so many websites out there that don't keep basic security in mind, and sooner or later you are bound to cross paths with this vulnerability.