Building an AppSec Program with Qualys WAS
Qualys Security Blog
Part I – Introduction and Configuring a Web Application or API: Basic Information
Welcome to our introductory series of blogs where we will take you step-by-step through your application security journey with Qualys Web Application Scanning (WAS) to build and deploy secure web applications and APIs and ensure they remain safe against new and emerging threats. Qualys WAS is the leading Dynamic Application Security Testing (DAST) solution in the industry, with a proven history going back over a decade as one of the critical components of the Qualys Cloud Platform.
Some of the topics we will cover in this series include:
Setting up applications and APIs in WAS
Automation for both scans and reporting
Understanding how the scanning engine works
Getting the most out of a scan report to reduce TTR (Time to remediation)
Integrating into CI/CD tools and ticketing systems
…and much more
To kick things off and get you running scans in no time, our first set of articles in this series will be a deep dive into setting up web applications and APIs in WAS and how best to configure them for your unique environments. While WAS will work great out of the box with default settings, you can dramatically improve the efficiency of your App Sec program by optimizing configurations for your web applications and APIs. Along the way, we will also point out the “Best Practice Tips” we recommend for getting the most out of WAS.
Now, it is time to dive in!
Creating a New Web Application or API in Qualys WAS
There are several ways to add a web application or API to WAS. These include:
A step-by-step wizard for configuring both required settings as well as optional settings for web applications and APIs. This can be selected from the WEB APPLICATION screen under the drop-down list for “New Web App” and selecting “Add New”.
Upload a CSV file to easily import dozens, hundreds, or thousands of web applications all at once. This is the “Import Web App” option listed under the drop-down list for “New Web App.”
WAS Catalog – The WAS Catalog collects potential web applications and subdomains discovered by WAS scans, as well as through imports from VMDR (Vulnerability Management, Detection and Response), that can be quickly added to your subscription for scanning. This can be found under the “Catalog” tab in the WEB APPLICATION screen.
Programmatically through the Qualys WAS API. This will be covered in a later series of articles, but details can be found here.
Today we will start with manually configuring a web application or API. From the “WEB APPLICATION” screen, select “New Web App.” From the drop-down list, select “Add New.”
This will launch a wizard for adding new web applications or APIs and take you step-by-step through all the different configurations. There are a couple of things to note in this wizard.
In the left-hand pane, you can see that there are 5 different steps to set up a web application or API. At any time, you can see exactly what step you are on by referencing this pane.
Additionally, you can navigate forward or backwards through the buttons at the bottom. Here we can see “Cancel” and “Next.” Once you pass the first step, options to go backwards will also be available.
Some of the fields are mandatory. Some are optional. The wizard will not let you progress from one step to another unless you have provided all the required and necessary information.
Naming Your Web App
The first required field is Name, where you are asked to provide a unique name for the application or API you want to scan. This name must be unique across your entire Qualys subscription. For example, you cannot give two web apps, two APIs, or a combination of web apps and APIs the same name.
Web Application URL or Swagger file URL
In this field you will define the starting point of an application or API for scanning.
For scanning web applications – You need to add the starting URL of the application you want to scan. This can be either an IP address or a FQDN. You can also identify a specific port to scan if it is not a standard port (e.g., 80/443). In addition, you specify more than a FQDN or IP address and add a path to a specific directory or resource. This can be useful if you want to limit your scans to a unique branch or path within the application. All of these are valid web application URLs for use by WAS:
For scanning APIs – If you are using an online OpenAPI or Swagger File for your APIs, you can provide the direct URL of this file for WAS to retrieve and start scanning. By doing so, any WAS scan will start by first requesting the OpenAPI or Swagger file to parse out endpoints and operation methods to fully test APIs for dynamic runtime vulnerabilities. If you do not have OpenAPI or Swagger files accessible over the internet, you will have an option to upload OpenAPI, Swagger, and Postman Collections under the “Additional Configurations” step that will be covered in a later blog. In that scenario, you can simply provide the first URL for your API following the same convention as listed above for web applications.
Please note there is a button to “lock in” scans over HTTPS. The default setting of “http://” means WAS will start the scan over port 80 and will follow any redirects to a secure version of the site or API that may be present. You can override this behavior to start with the secure version of the site or API over HTTPS if desired. However, in this case, WAS will not interact with or scan any insecure versions of the site or API unless it is redirected to a version on port 80. Modern web applications and APIs are typically not configured this way – they redirect from insecure (port 80) to secure (port 443) and not the other way around. Keep this in mind if you have a site or API that is available on both HTTP and HTTPS and not just redirected from HTTP to HTTPS.
Best Practice Tip! Leave “http://” unlocked and allow WAS to follow any redirects present to ensure full coverage unless your site.
A purely optional setting, custom attributes allow you to define details about the web application or API in name/value pairs. You can then search for this attribute as needed. For example, you could create custom attributes to document operating systems for web servers (OS:Fedora) or webserver technologies (WebServer:Apache) or other application– specific information.
This is another optional setting, but one you should really consider implementing. Tags are a powerful feature built into the Qualys platform to organize assets (in this case a web application or API) according to function, location, or any other criteria you want. Furthermore, Qualys can leverage the tags to select assets automatically. A powerful use of tags will come into play when we discuss scheduling multi-site scans. With multi-site scans, you can specify targets individually by name, or with tags. Tags will allow you to dynamically add new web applications and APIs to a scheduled scan by simply adding the appropriate tag to the web application or API itself. Additionally, to dynamically remove assets from a scan you can simply remove the tag the scan uses to identify its targets. Tags are not limited to scans either, and their use is spread across the Qualys Cloud Platform for not only searching, scanning, and reporting, but also for scope limitations to Role Based Access Control (RBAC).
You can add existing tags to your web application or API, or create new tags on-demand, right from the Tags section of the web application wizard.
Best Practice Tip! Implement tags early in your App Sec program to fully leverage all the built- in automation WAS has to offer.
At this point, you can click “Next” to be taken to Step 2 in manually configuring your web application and APIs – Crawl Settings. Please join us next week for our next article where we will cover Crawl Settings in detail and provide additional best practices for getting the most out of Qualys WAS.