New & Improved Qualys WAS Burp Extension Now Available

Last year we released the initial version of the Qualys WAS Burp extension to positive reviews.  Customers welcomed the ability to send Burp-identified issues into Qualys Web Application Scanning (WAS) for centralized viewing and reporting of automated scanner findings plus manual pen-test issues from Burp.

Now we are pleased to announce the release of version 2 of the Qualys WAS Burp extension.  In addition to the previous functionality, this version allows you to import a WAS finding directly into Burp Repeater to manually validate the vulnerability.  Even better is that this new capability works with both Burp Suite Professional and Burp Suite Community Edition.

Qualys WAS Burp Extension v2

As a reminder, the Qualys WAS extension is available in Burp’s BApp Store under the Extender tab:

Qualys WAS extension in the BApp Store

Once installed you’ll see a “Qualys WAS” tab in Burp.  From there select the correct Qualys platform for your subscription and enter credentials to ensure proper connectivity to the Qualys WAS API.  Access to the Qualys API is required to use this extension.  Having trouble?  Review the Logs section on the Qualys WAS tab to see all the API calls being made.

The purpose of the new functionality is to help customers to manually validate scanner findings.  This is something many WAS customers want to do, but the process can be somewhat cumbersome.  The new extension makes validating a scanner finding easy. Simply go to the Repeater tab and right-click in the Request section.  You will see a new option called “Import Qualys WAS Finding.”

There are a couple of ways to import a WAS finding into Repeater.  First, if you know the ID of the finding, simply choose “Enter Finding ID”, enter the ID, and click Fetch.  It’s best here to enter the unique UUID of the finding, but the findings’s numerical ID will work in most cases too.

On the other hand, if you don’t know the finding ID, choose “Select from a Web App’s Open Findings” to look up a particular finding from the web app’s name in WAS.

If you chose this second method, you will see a list of web apps from WAS.  Select the appropriate web app and the open vulnerabilities for that app will be loaded into the Findings list.  Select the finding you want to validate.

If multiple request payloads are present for the finding, you will also need to choose one of the payloads.  Click “Import Request” and the HTTP request for the finding will be loaded into Repeater.

You may need to manually change the session cookie or other authentication token in the request.  This is typically required when the vulnerable URL is accessible only after authenticating to the web app.  While the session cookie and/or other tokens loaded into Repeater were valid at the time of the scan, they have likely expired since then.

Click “Send” and inspect the response to validate the finding.  The specific steps to validate the finding depend on the type of vulnerability.  For example, if the vulnerability is a missing HttpOnly cookie attribute, you would need to view the “Set-Cookie” response header and check for the presence of HttpOnly.  If the vulnerability is reflected XSS, you would need to inspect the body of the response to see if the request payload was properly encoded or not (example below).

Final Notes

  1. Informational findings from WAS are not eligible for importing into Repeater.  This is because WAS stores the full HTTP requests only for vulnerabilities, not informational items.
  2. If the WAS finding you’re trying to import is old (detected prior to WAS Engine 7.0), some of the request headers may be missing and the request format may need to be tweaked manually for the request to be valid.

Leave a Reply