How to prevent most false positives with an OAST server

False positives are commonly occurring in automated scanners. We all hate them because they give us false hope and make us excited for nothing.

Luckily, there are multiple ways to get rid of them or at least reduce them to an acceptable level. In this article, I will be sharing one of the exact methods we used over at BLACKBIRD for our penetration testing tools.

Validation of discovered vulnerabilities is essential because it 1) allows us to gather evidence that the reported vulnerability actually exists and isn't a fluke and 2) enables us to build a clear and working proof of concept that can be used in our report writing.

What is an OAST server?

An Out-of-Band Application Security Testing (OAST) server is a server that's specifically set up to listen for incoming invocations (such as DNS queries or HTTP requests) and log them.

A common use case for an OAST server is for the validation of a blind server-side request forgery (SSRF) vulnerability. However, OAST servers can also be deployed for blind cross-site scripting (XSS) or any other out-of-band (OOB) security vulnerability.

What are false positives

When a security vulnerability scanner reports a discovery without providing any evidence, it is likely a false positive result. The root cause is often traced back to lack of issue validation by the vulnerability scanner.

The most common example (especially in web security), are cross-site scripting (XSS) scanners that try to send payloads and analyze the HTTP server with regex patterns. This approach is somewhat incomplete as no browser validation is taken into account (response content type, content security policy, any client-side processing or filtering, etc.). Therefore, it's quite prevalent in these types of poorly developed scanners to report back XSS vulnerabilities that do not exist.

This particular case is easily solvable simply by deploying a headless browser (the same approach we took with XSSCANNER). However, when we are dealing with server-side vulnerabilities (SQLi, SSRF, RFI, ...), a more appropriate approach will be necessary.

Validation with an OAST server

Early on in the development, we knew we had to deploy an OAST server to make it possible for our scanners to validate the vulnerabilities that our clients come across. Instead of making our customers deploy their own one (and deal with the hassle of maintaining yet another server), we set up a private OAST server for them. This also provided us with the ability to include payloads for them, which can come in handy for any type of OOB vulnerability.

Thanks to @zseano's recommendation, we were able to get hold of a 4-character domain name which proved to be quite useful especially when dealing with Web Application Firewalls (WAFs) and other security filters that reject longer payloads.

Now that the server is set up and is capable of logging DNS & HTTP requests, we can easily construct our payloads so that they transmit a simple DNS query. Once sent, we can easily match it with the incoming invocations, our evidence that the vulnerability exists.

In practice, this would work as the following. Suppose we've got a query parameter that's potentially vulnerable to an SQL injection. Instead of injecting a time-based or boolean-based payload, we could make use of built-in database functions that make a DNS query.

OPENROWSET is one of them in Microsoft SQL Server:

SELECT * FROM OPENROWSET('SQLOLEDB', '//{YOUR_OAST_SERVER}', 'SELECT 1')

Take a look at the following diagram to better understand how this would work in real-world scenarios:

We can use the same approach to validate other vulnerabilities such as:

• Server-side request forgeries (SSRF)
• XML external entity (XXE) injections
• Server-side template injections (SSTI)
• OS command injections
• Remote file inclusions (RFI)
• Cross-site scripting (specifically blind XSS)
• Open URL redirects (only server-side redirects!)

Why this approach works so well

Even though this does not apply to all security vulnerabilities, this validation technique can significantly reduce the number of reported false positives.

This approach is also much more accurate than analyzing HTTP responses with regex patterns. Furthermore, a DNS or HTTP invocation can also serve as strong evidence that you can include in your pentest report.

Validation for client-side vulnerabilities (such as XSS, DOM-based open URL redirects, CORS misconfigurations, etc.) using an OAST server is also a possibility, however, this will require you to set up a headless web browser.