Security, whether it be for a single-page application, an API, or some other type of service, has become the number one concern of many businesses around the globe. To developers, this doesn’t come as a shock. For years we have been told to practice secure coding practices, harden the servers that our code runs on, and monitor for potential anomalies which may show that our application has been compromised.
Of course, as technology has progressed we have tried to move beyond letting our tendency for human error lead to a breach or vulnerability. Many organizations adopted static code analysis many years ago to help identify any potential vulnerabilities in our dependencies. The introduction of static code analysis allowed developers to fix issues before they hit production. This covers one potential path for vulnerabilities, but what about the types of vulnerabilities we bake into the code we write? The ones that may only become apparent when the application is running? This is where DAST platforms come into the picture. These are the exact vulnerabilities that StackHawk looks to help you and your organization solve.
What is StackHawk?
StackHawk is a dynamic application security testing tool that was built to help developers find, triage, and fix security bugs in their applications. Instead of scanning static code, StackHawk finds bugs that you or your team may have written into the code by scanning a running version of your application. This can be done either in local development or in your CI/CD pipeline, something StackHawk was specifically built for.
StackHawk also allows you to dig deeper than other legacy DAST tools by pushing forward advanced features such as API and Microservice testing. Because it is scanning a running version of your application, it finds the vulnerabilities that would be available to an outside attacker of the application.
Why use Dynamic Application Security Testing?
StackHawk finds potential vulnerabilities in your code, such as:
SQL Injection,
Arbitrary Code Execution,
OS Command Injection,
Path Traversal,
Cross-Site Scripting,
Cross-Site Request Forgery,
Open Redirect
and much more
Many of these bugs are the same type that you would find with an application dependency checker like Snyk, but DAST checks for vulnerabilities that are introduced by dependencies as well as your own team’s proprietary code. This is why a DAST tool like StackHawk is a great addition to your existing security scanning practices and toolset.
How does Stackhawk work?
StackHawk contains 2 components which power the overall platform. The first is HawkScan Scanner, which works to scan your application paths and does the actual finding of the vulnerabilities. This process can run anywhere in your delivery pipeline. The second component is the StackHawkPlatform itself. The StackHawk Platform is where the results from the HawkScan Scanner are collected and analyzed. This is also where developers can communicate and track findings to ensure a resolution. Let’s dig a bit further into how each component works.
Scan Discovery
In order to actually find vulnerabilities in the running application or API, HawkScan Scanner needs to run against your code. This can be done by using docker or by using Hawk CLI to start the process.
Scan Discovery, facilitated through HawkScan, is the first step in the actual process to find vulnerabilities. The process figures out which paths and endpoints StackHawk should test by crawling your web application and API routes. To find meaningful vulnerabilities, HawkScan will try to discover parts of your site, intercepting the request & response HTTP payloads as it navigates your web application. This can be configured and fine-tuned under the hawk.spider section of the stackhawk.yml file you’ll use to configure StackHawk.
There are a few different scans which can be performed by the HawkScan scanner. Let’s go over some of the more popular options below.
Base Spider
The base spider is a basic web crawler that is used to discover application routes and will be appropriate for most traditional web applications. The spider discovers the pages of your application by finding URLs through responses containing a Content-Type of text/html. Through these URLs, the spider then does a breadth-first search on those paths until it has reached all accessible pages.
Ajax Spider
The Ajax Spider goes beyond the base spider to support more dynamic websites and Single Page Applications. This is done by leveraging Selenium to create unscripted application actions such as clicking buttons or other links that users would dynamically encounter. By using Selenium, the spider can accurately parse the entire application dynamically to ensure that all routes and actions are covered to be scanned for vulnerabilities. Although Ajax Spider is still available, we do recommend that you use an OpenAPI Spec-based scan instead.
Open API Spec
Those familiar with OpenAPI/Swagger Specifications will be happy to know that they can be used within HawkScan to deliver a faster and more conclusive scan. HawkScan will use the contents of a provided OpenAPI spec to improve the quality of a scan in two ways:
Pre-seeding the sitemap using the routes defined in the OpenAPI spec. This can be used to complement any crawled routes or can be used instead of app spidering altogether.
Using defined inputs to routes in the spec to inform how to communicate with the web application and gather clues on how to better attack endpoints.
GraphQL Introspection endpoint
HawkScan is also able to support GraphQL APIs as well. This is done through the GraphQL API’s Introspection endpoint. HawkScan is actually a pioneer for application security testing your GraphQL APIs.
This scan works by allowing Hawkscan to perform an introspection query on a GraphQL app. This introspection query will allow HawkScan to generate routes based on available operations. The scanner can be configured to enumerate all available types and input parameters for Query and Mutation together, or for each individual type separately.
Custom Scan Discovery
Another way for HawkScan to discover your web application is by using other familiar tools to provide commands or generate web traffic. For example, some popular tools to use with HawkScan are Postman, Cypress, or an HTTP Proxy. While using these tools to generate traffic, HawkScan will intercept the generated traffic and scan it for vulnerabilities. This feature is a great way for security teams to combine their favourite software testing dev tools and customize their HawkScan experience.
The Scan Itself
As the discovery process uncovers each path within the application, the scan of the application itself begins. The scan runs asynchronously and as more paths are added to the tree, scans are executed against them to check for vulnerabilities.
The scan itself is quite simple to explain, essentially HawkScan will attempt to identify vulnerabilities by probing for known vulnerabilities against your running application. Vulnerabilities that will be detected by HawkScan can include instances of SQL Injection, Cross Site Scripting, and Proxy Disclosure. HawkScan will print the details of the scan to the console as it runs. This will let users know how the scan is progressing, what HawkScan is working on, and potential vulnerabilities the scan uncovers. At the same time, the scanner also streams data to the StackHawk platform, so you can watch your scan status online in real-time.
Tuning the Scan
A scan can also be fully customized by using different flags in the command you use to initiate the scan. Using flags and config tweaks to customize the scan allows StackHawk to run even faster. much faster.
Tuning can include configuring HawkScan to authenticate to your app, introspect and scan GraphQL, reading your app’s OpenAPI specification, and other settings to help StackHawk run quickly and in a more targeted fashion.
You can also use StackHawk Technology Flags to tell HawkScan which technologies your application uses, such as Java, Javascript, and MySQL. This will ensure that StackHawk only runs the applicable tests for the specific technologies used in your application. By excluding tests that are not applicable to your technology stack or application, the scan can run faster without sacrificing effectiveness.
Reviewing Findings and Potential Fixes
Once all of the application paths are discovered and scanned for vulnerabilities, users can come to the StackHawk platform to review the findings. The StackHawk platform offers a place for users to review the scan results, and possible fixes, as well as a place to manage each of the findings. Different than products that just find vulnerabilities and leave the developer to find possible solutions, StackHawk gives meaningful insight into potential fixes and shows developers how to resolve the issue right within the platform.
Let’s take a look at a few features within the StackHawk Platform that help teams to create more secure applications and prioritize their security needs.
Findings Management
Once security defects and vulnerabilities have been found in your code, StackHawk allows you to classify each of the findings as False Positive, Risk Accepted, or Send to Jira/Assigned. This can be extremely useful since it gives flexibility to teams to decide which findings are important to fix as soon as possible and which ones can be moved to a later date or sprint.
Using curl for Easy Debugging and Fixes
Part of StackHawk’s mission is to make security more accessible to engineers. As part of this initiative, being able to recreate the bug or vulnerability in your application is of high importance. Sometimes this can be really complex, forcing users to recreate a command or call an API that they are unfamiliar with. Even worse, they may not know how to get the command correct to create the exact condition needed to expose the vulnerability in the code.
For this, StackHawk allows users to generate a curl command which will have the correct HTTP verb, headers and data fields to recreate the potential attack. By running this curl command and running the application in debug mode in your IDE, you can step through the requests to identify where the issue lies within your code. With this, developers can quickly fix the vulnerability and ensure their application is secure.
Using StackHawk with a SAST Platform
On top of DAST capabilities of StackHawk, some users may also want to integrate with a SAST platform, such as Snyk. Using a SAST platform alongside StackHawk will allow findings to be linked between the SAST tool and the entry in StackHawk. By using both platforms, engineers can ensure that their code is secure from all angles.
The SAST platform scans through the code statically looking for patterns which may denote a potential vulnerability. These findings could indicate that the code does in fact contain a security defect. The vulnerability can then also be validated with a StackHawk HawkScan. Correlating the two scan result helps to show that issues are exploitable and accessible (via StackHawk) and where the issue lies in the code (Via the SAST platform). Combining these findings helps prioritize issues for developers and enables them to confirm, reproduce, and fix them quickly and efficiently.
Try it out!
Now that you have an idea of how StackHawk works and the advantage it can bring to your application security, sign up today to try it out for yourself. Whether you’re looking to bring DAST to your Traditional Web App, Single Page Application, or even your APIs, StackHawk is the most efficient way for engineers to bring security scans directly into your organization's CI/CD pipeline. Make application security a default priority in your team's development lifecycle.
