In a world of rapidly evolving security threats, ensuring robust security across various platforms — from single-page applications to multiple types of APIs — has become one of the biggest concerns for businesses worldwide. Developers, especially, are acutely aware of this mounting pressure. For years, developers have been told to adopt secure coding practices, reinforce server security, and vigilantly monitor for signs of compromised applications.
As technology advances, the focus on applying security best practices has shifted from merely relying on human vigilance to adopting more sophisticated and automated methods. These advances in security technologies have enabled developers to preempt security breaches instead of simply reacting to them. One significant advancement was the adoption of Static Application Security Testing (SAST). SAST has been instrumental in identifying potential vulnerabilities in code dependencies, enabling developers to address these issues before they reach production. However, SAST primarily scrutinizes the static aspect of the code, leaving a critical area unaddressed: runtime vulnerabilities.
This gap in security testing is precisely where Dynamic Application Security Testing (DAST) platforms like StackHawk excel in improving an organization's security posture. DAST addresses SAST's blind spots by identifying vulnerabilities that only surface when the application runs. Often overlooked in the development phase, these vulnerabilities can pose significant risks if exploited once the application hits production. In this blog, we will look at the basics of DAST and then dive deep into the inner workings of StackHawk and how it works.
What is Dynamic Application Security Testing (DAST)?
Dynamic Application Security Testing, commonly known as DAST, is an automated process that tests applications in their running state to identify security vulnerabilities. Unlike Static Application Security Testing (SAST), which analyzes the status source code of an application, DAST interacts with an application in its running state, simulating the actions of a potential attacker. With DAST tools, developers can detect issues that manifest at runtime, such as injection attacks, cross-site scripting (XSS), and other vulnerabilities that can only be exploited when an application runs.
With traditional web applications, DAST tools explore and interact with an application through the front end without requiring access to the underlying source code. This method enables them to identify security flaws from the perspective of an unauthorized or unauthenticated user. As a result, the tests executed by a DAST tool are particularly effective in uncovering network and application-layer vulnerabilities that external attackers could exploit. The process involves sending various inputs to the application, analyzing the outputs, and monitoring the application's behavior to detect potential vulnerabilities. Regarding APIs, DAST tools can look at the input and output of an endpoint to determine if a security vulnerability is present. Of course, not all DAST tools support testing all types of APIs (or APIs in general). StackHawk supports testing REST, GraphQL, SOAP, and gRPC APIs, the particulars of which we will cover later.
The strength of DAST lies in its ability to assess an application in its operational environment, which includes not just the application itself but also its interaction with other systems and databases. This real-world, black-box nature of testing with DAST makes it a crucial component of a comprehensive security strategy, particularly for web applications and APIs where user interaction is a constant factor. Once an application is running, implementing a DAST solution can ensure that applications are functionally sound and secure from external threats.
What is StackHawk?
StackHawk is a dynamic application security testing tool built to help developers find, triage, and fix security bugs in their applications. StackHawk is a modern DAST tool that focuses on enabling the “shift-left” methodology for application security aimed at moving testing into the developer's hands and earlier in the SDLC. As a DAST platform, instead of scanning static code, StackHawk finds bugs that you or your team may have written into the code by testing a running version of your application. Running StackHawk can be done in a local development environment or your CI/CD pipeline, something StackHawk is explicitly built for.
StackHawk also allows you to dig deeper than legacy DAST tools by pushing forward advanced API and Microservice testing features. Since StackHawk scans a running version of your application, it finds the vulnerabilities available to an outside attacker. Since StackHawk only reports vulnerabilities that can be actively exploited, the platform reports fewer false positives. Less unnecessary noise keeps developers focused on tackling the vulnerabilities attackers can exploit once the application hits production servers.
Why use StackHawk?
Dynamic Application Security Testing (DAST) is crucial in uncovering many security vulnerabilities within applications. StackHawk, as a modern DAST tool, excels in finding critical vulnerabilities that expose themselves at runtime. Especially with its automated integration in CI/CD pipelines. This ensures that vulnerabilities are identified and resolved before they reach production.
StackHawk's DAST capabilities extend to a broad spectrum of vulnerabilities, including but not limited to:
SQL Injection
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
And a wide range of other vulnerabilities typically found in the OWASP Top 10 list
Unlike traditional DAST solutions, StackHawk is designed for modern application architectures, enabling exhaustive testing across various API types such as REST, SOAP, GraphQL, and gRPC. This comprehensive approach ensures that your applications and APIs are thoroughly tested for vulnerabilities.
How does StackHawk work?
StackHawk contains 2 components which power the overall platform. The first is HawkScan Scanner, which scans your application paths and finds 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
To find vulnerabilities in the running application or API, HawkScan Scanner needs to run against your code in a running application. Developers can get started by using Docker or Hawk CLI to start the process. 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 finding vulnerabilities. The process determines 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.
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 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.
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 and scan the generated traffic for vulnerabilities. This feature is an excellent way for security teams to combine their favorite software testing dev tools and customize their HawkScan experience.
Scan Discovery for APIs
Regarding APIs, StackHawk and HawkScan can use a few different methods depending on your API technology. Of course, specific API routes and actions will also be picked up by the previously mentioned scan discovery methods. However, StackHawk offers a few different ways to ensure your APIs are tested entirely and accurately, no matter the technology you are using. Let’s take a look at the specifics below.
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 a pioneer for application security testing your GraphQL APIs.
This scan allows Hawkscan to perform an introspection query on a GraphQL app. This introspection query enables HawkScan to generate routes based on available operations. The scanner can be configured to enumerate all known types and input parameters for Query and Mutation together or each type separately.
gRPC Schema Reflection and File Descriptor Sets
For those utilizing gRPC, HawkScan offers specialized support to ensure comprehensive security testing. gRPC, which uses Protocol Buffers and HTTP/2, can seamlessly integrate with HawkScan for detailed security analysis. HawkScan can obtain the gRPC schema through reflection or a file descriptor set. Reflection is recommended since HawkScan can retrieve the schema directly from the running application. HawkScan can use a pre-generated file descriptor set in cases where reflection isn't enabled. Both methods allow HawkScan to create tests based on available gRPC endpoints.
SOAP Web Service WSDL Support
HawkScan extends its capabilities to support SOAP Web Services, leveraging the Web Services Description Language (WSDL). This enables HawkScan to interface accurately with SOAP-based services used in many legacy applications. By parsing the WSDL file, HawkScan can identify the operations, inputs, and outputs defined for the SOAP service. By doing this, StackHawk can ensure that vulnerabilities specific to SOAP implementations, such as XML injection or SOAP action overloading, are effectively identified and addressed.
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; 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 scan details 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
Developers can fully customize a scan by using different flags in the command used 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, introspecting and scanning 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. The scan can run faster without sacrificing effectiveness by excluding tests that do not apply to your technology stack or applications.
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. Unlike products that 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 highly important. Sometimes, this can be complex, forcing users to recreate a command or call an API that they are unfamiliar with. Even worse, they may not know how to correct the command to create the exact condition needed to expose the vulnerability in the code.
StackHawk allows users to generate a cURL command with 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 the DAST capabilities of StackHawk, some users may also want to integrate with SAST platforms, such as Snyk or GitHub. Using a SAST platform alongside StackHawk will allow findings to be linked between the SAST tool and the entry in StackHawk. Engineers can use both platforms to 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.
Using StackHawk to Secure APIs
As the use of APIs continues to explode, they are becoming a more popular attack vector that developers should be aware of and actively defend against. Users of DAST may only think of it in terms of testing a web application versus applying it to their suite of APIs. With StackHawk, APIs are front and center of the DAST experience. As mentioned in the sections above, StackHawk can quickly determine your API endpoints by uploading an Open API Specification or, if using GraphQL, an introspection endpoint, for example. On top of REST and GraphQL support, StackHawk also supports testing SOAP and gRPC APIs.
When StackHawk tests an API, the endpoint is put through its paces with a meticulous set of tests to expose any vulnerabilities it may reveal. StackHawk allows users to dial in their particular API setup so that tests can be tailored and customized on top of the platform's default set of tests. When a vulnerability is detected, users can see the result in a report which contains the request, response, and any evidence that a vulnerability exists. On top of this, developers are also supplied with fix guides to show developers how to remedy the exploit quickly.
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 API and application security a default priority in your team's development lifecycle.
