Testing SSRF using OWASP ZAP OAST add-on

Intro

In one of my previous blogs I wrote about SSRF and how I tested it (you can find it here). During this time, I was looking for alternative way for testing SSRF and I have found one, a few months ago, when OWASP ZAP released an add-on called ‘OAST Support’.

What is it OAST?

OAST stands for Out-Of-Band-Vulnerabilities. An OAST vulnerability allows an attacker to gain access to sensitive information outside of the normal communication channel. A good example of an OAST scenario is the XSS vulnerability (Cross-site Scripting). In this situation, an attacker injects malicious code into a website. When a user visits the compromised website, the injected code executes without the user’s knowledge. Subsequently, the attacker can steal their credentials, personal data, or any payment method details.

What is it SSRF?

SSRF stands for Server Site Request Forgery. SSRF is a security vulnerability that allows an attacker to send a request to an internal service through a public service. Without this vulnerability, an attacker cannot send requests to the internal service.

The danger with SSRF, therefore, is that it can easily lead to unauthorized actions such as: Access to data, ability to execute arbitrary commands on a company’s backend systems, connection to third party systems and more.

How OWASP ZAP can help?

OWASP ZAP is an open-source web application security scanner with the capabilities to assist you in testing web applications and identifying security issues. As mentioned in the introduction, OWASP has an add-on called OAST that can communicate with services like BOAST, TukTuk, and interactsh. These services provide you with the ability to determine if an SSRF attempt you made successfully reached its target. For some of you, this concept may sound familiar if you have worked with the Burp Suite collaborator before.

How to use?

First, install OWASP ZAP if you still haven’t done it. Then, open ‘Manage Add-ons’:

Make sure that the add on is installed and it updated to the latest version. Pay attention that currently it’s status is Beta:

By clicking on the ‘Green plus sign’ on the bottom you can enable OAST tab:

Clicking on the gear icon will open the OAST settings page:

In this page you can select which service you want to work with. BOAST or Interactsh. These services were built to detect and report out of band activity and in this case they will act as in internal service to get the requests in case you succeed to discover SSRF:

I am selecting the BOAST service (Without any particular reason). Click on Register to obtain a Payload that you will use in your attacks. The default Polling Frequency is set to 60 seconds, meaning that the registered BOAST will be polled every minute.

This is how your OAST settings window should look:

*Pay attention that the Server URI is changed to https://odiss.eu:2096/events

Now that we have configured the OAST settings, let’s proceed to a demo.

To demonstrate how it can be used, I found an example on GitHub of how to create a flask application using Python that will be vulnerable for SSRF.

In 5 minutes I had my application up and running.

Back to ZAP tool, we can open a browser by clicking on the Firefox icon:

From the Quick Start tab, you can configure which browser you want to work with. For the purposes of this demonstration, we are using ZAP’s built-in browser because it’s already configured to display all the network communication within ZAP.

In the browser that I opened from ZAP tool I set the URL of the demo app that I created: http://localhost:5000/fetch?url=http://target-url.com :

Now we will go back to OAST settings window and will copy that payload that was created after we clicked on Register, for me it was: fdmszgiwzrxxq3h6dsswouxkue.odiss.eu . Now, replace the url query string parameter field value to http://fdmszgiwzrxxq3h6dsswouxkue.odiss.eu and will click on Enter:

Now I can see this request on ZAP tool under OAST tab by clicking on Poll’ now’ or wait 1 minute.

This is what we should see:

In our vulnerable demo app there isn’t any validation on the ‘url’ value that a user set, and as you can see in line 23, it sends the request as is:

And in line 24 it sends the response back to the user as is.

This behavior can lead to SSRF!

In this blog post, I demonstrated a new testing approach that I took using the OWASP ZAP OAST add-on. The post guides readers through the installation, activation, and configuration of the OAST add-on, showcasing its effectiveness with a Flask application demo.

Thank you for reading, I suggest you to explore SSRF testing with OWASP ZAP OAST and share your thoughts or questions in the comments!

If you like this blog post I invite you to follow me at Medium platform.