DEV Community: StackHawk

Announcing GraphQL Application Security Testing

Ryan Severns — Wed, 10 Jun 2020 21:17:52 +0000

In 5 short years, GraphQL has solidified its footprint as the API backing of many applications, and it shows no sign of slowing. More and more companies are choosing GraphQL for its simplicity, ability to fetch the right amount of data, and the way it can traverse a graph of relational data.

Securing GraphQL applications, however, has been a challenge. Sure, there are common best practices and rules in place. But reliance on training or the rudimentary automated checks that currently exist only gets you so far. Eventually security bugs will be deployed and your app will be at risk.

…until now.

GraphQL Security from StackHawk

We’re excited to announce that HawkScan, StackHawk’s scanning engine, now supports GraphQL applications. StackHawk is the only product on the market that can scan a running GraphQL application, simulating an attack by fuzzing the various query parameters, and surfacing potential security bugs to engineering teams.

With StackHawk, teams using GraphQL for their API layer can now confidently catch potential vulnerabilities before security bugs hit production. With CI/CD automation, you can ensure that potential bugs are caught early in the development lifecycle and fixed by the developers who have the context and expertise of the code base they just merged to.

How it Works

StackHawk is a dynamic application security testing tool. That means it runs security testing against your running application, whether that be on your local machine, in CI environments, or against your application in production.

GraphQL testing is done by exposing the introspection endpoint to the scanner via the StackHawk.yml file. The scanner runs introspection and identifies all of the potential query and mutation operations of the endpoint, and then gets to work finding potential security bugs. As a dynamic security test, the scanner sends requests to all endpoints, effectively fuzzing the whole GraphQL tree, simulating the ways the application could be attacked. The scanner logs all tested endpoints and any security bugs found, with the associated request and response payload. From there, developers can triage bugs, fixing high priority issues and using Findings Management to quiet noise for accepted risk or assigned items. Then, GraphQL scanning can be automated in the pipeline to ensure that no build hits production with unaccepted security risk.

Getting Started

Getting started with GraphQL security in StackHawk is incredibly easy, simply requiring the addition of the schema path to the stackhawk.yml file.

App:
  ...
  graphQL: true
  graphQLSchemaPath: /graphql

Visit our docs for more information on configuration for GraphQL, as well as other configuration options such as authenticated scanning. As always, our team is available to assist as you begin using StackHawk. Reach out to support@stackhawk.com and we will be happy to help.

Fixing Security Bugs Faster with curl Validation

Nick Teets — Mon, 01 Jun 2020 17:18:22 +0000

Learn how to leverage the Validate Finding feature of StackHawk to find and fix security bugs faster.

As a front end developer, I’ve scoured countless pages of documentation and StackOverflow replies seeking the answer to a problem I’m trying to solve. When the issue stems from a network request or other type of data transfer, these resources have suggested using curl to execute your request. When fixing security vulnerabilities, executing a request via curl allows you to more quickly find the part of the codebase that needs to be fixed. At StackHawk, our new Validate Finding feature allows you to find and fix your security bugs faster.

Overview of curl

curl allows for the transfer data using HTTP protocol from the command line. Passing along flags give you the ability to specify your request verb (GET, POST, DELETE, etc), data output format and headers. Data can be passed along in various ways, with JSON being a common choice. This should sound familiar if you’ve used the JavaScript client Axios, Fetch web API or the GUI platform Postman for interacting with an API – curl acts similarly as a ubiquitous command line interface.

Nearly everyone with access to a command line interface can use curl, regardless of operating system (if you’re a Windows developer, many workflow tools, like Git for Windows, will have curl built in). This makes it an excellent broadly applicable tool to help developers regardless of language, framework, or type of application they are supporting.

Finding Security Bugs with StackHawk

Given the widespread use and power of curl commands, we can use the data provided from StackHawk to recreate a potential attack on our application. StackHawk is an application security testing tool, scanning your application to find security bugs. One of the easiest ways attackers will exploit your application is through a client-side input – cross site scripting (the injection of JavaScript into an input field to gain control of your app) and SQL injection (the execution malicious queries on your database) are two of the most common ways attackers will exploit unsafe input fields. StackHawk can find these security bugs and more.

Fixing Security Bugs with curl + StackHawk

After a StackHawk scan is complete, you can jump into the web application to take a look at the list of findings. The UI gives details of the request and response payloads for a particular finding. When you have a security bug, the newly released Validate button helps you fix the problem faster.

Clicking on the Validate button will generate the curl command used to identify the bug. This curl command will have the correct HTTP verb, headers and data fields to recreate the potential attack. By running this curl command in debug mode in your IDE, you can step through the requests to identify where the bug lives in code. With this, you can quickly fix the vulnerability and get back to building software.

At StackHawk, we aim to empower developers to own their application security through knowledge and tooling, like the ability to recreate a curl attack from within our platform. Using this knowledge, you can protect your input fields, write tests against malicious data requests and have the peace of mind knowing how your web application can be attacked.

Application Security is Broken. Here is How We Intend to Fix It.

Ryan Severns — Wed, 20 May 2020 20:54:58 +0000

Application security as we know it today is broken.

You commit your code and push features into production, only to get a high priority Jira ticket from security months later with little context. At this point, a security bug has been in production for months and you are pulled into an inefficient fix process.

There is a better way.

tl;dr

Modern AppSec is Broken. Agile, Cloud, DevOps, CI/CD, and open source have changed everything for engineers, but security processes struggle to keep up.
AppSec’s Future is in Engineering Teams. Traditional IT Operations was replaced by DevOps; shouldn’t engineering own the security of the code they write?
A New Breed of Security Tools are Coming. We are part of a small but powerful group of security tools that are built for the developers who do the actual fixing of security bugs.

Application Security is Broken

Applications are being pushed into the world faster than ever before. Cloud deployments, DevOps teams, and CI/CD have enabled engineering teams to produce high quality software with incredible efficiency. As these applications are pushed to production, often multiple times per week or day, the current security model can’t keep up.

Below are some of the ways that AppSec is no longer working for modern software teams:

Doesn’t Match Modern Workflows. Development has shifted to continuous delivery, with endless tools to support you in your work. You deploy software quickly and count on test suites to catch bugs. Your application security tools, however, are built for a waterfall era and exist in isolation from the rest of your workflow.
Not Built for Automation. Security bug testing should be automated throughout the delivery pipeline, starting as close to local dev as possible. Solutions that center on testing once an app hits production just don’t cut it in this day and age.
Finding > Fixing. Existing application security tools (and, in some cases, teams) engage in a contest of finding the most things and you get an ever increasing backlog. Fixing easily exploitable, easily fixed bugs should be prioritized over finding the most obscure vulnerability.
Built for InfoSec. It only takes a few minutes on the RSA trade show floor to know that the security products of old are built for the suit-wearing Fortune 500 CISOs. Built for Developers is a marketing tagline, not a product reality. Jump into any of the market leading security tools and it is quickly apparent that they are not, in fact, built for developers.
Training > Tooling. Security teams invest time and effort training developers on how to write secure code. While a noble pursuit, the reality is that you are pushed toward feature delivery and don’t retain enough of their secure coding workshops. Good tooling will always win out over another training day.

Engineers Will Own the AppSec of the Future

The tide is beginning to shift, with engineers taking hold of the security of their applications. Modern engineering teams know that to ship secure apps, they need to own it themselves. We are in the early days of that shift, with a day soon on the horizon where inefficient InfoSec models for application security will become a relic of the past.

As we talk to the developers who are on the cutting edge of this shift, we are seeing the following trends:

Finding Security Bugs is Shifting Left. As with any bug, it is best to find and fix earlier in the development process. Finding a bug in local dev and hammering away on a quick fix is easy. When a bug breaks a build or is found in production, that is a different story. The best engineering teams are adding application security checks at commit and merge and equipping their developers with the tools to troubleshoot quickly when a bug is found.
Triage and Fix Lives with Those Best Equipped. If you wrote the code, you are typically the best equipped to make a call on the security risk of a particular bug and to instrument a fix. Even better is when the fix is so simple that it erases the cognitive load of defining the risk, but the bug can be found and fixed while still in local dev.
Fixing While in Context Drives Speed. No more getting alerted on security bugs for code you wrote months ago. Fixing a bug while you have the context of the part of the code base you are working on drives simplicity and efficiency.
Security == Quality, and Engineering knows Quality. Your engineering team knows how to ship high quality applications with speed and efficiency. In the same way that teams would not push UI bugs into production, security bugs can be fixed before the latest release goes live. Secure code is quality code.

The New Breed of Security Tooling

The application security shift has already begun. There has been incredible progress on what makes a best-in-class engineering program over the past two decades. Engineers own the end to end building, delivery, operation, and quality of their applications, and the time has arrived for you to own the security as well.

This shift, however, requires a new breed of security tooling. The tools that aim to serve the CISO first, to the detriment of engineers, will no longer cut it. The products that carry outrageous price tags but have not kept up with the shift in how software is created and delivered will have to be phased out. Here at StackHawk, we say, “This is not security for security people.” As long as application security tools are built for InfoSec teams, they will lack the features that are needed to truly serve you, the modern software engineer.

We created StackHawk to simplify the process of building and delivering secure code. We are dead set on creating the best security focused dev tool out there, ensuring that the same people who write the code are equipped to ensure it is secure. We are excited about what we have built already and we are just getting started.