How to Make GraphQL Security Easier with StackHawk

What's up GraphQL Galaxy? It's your boy, Scott Gerlach, CSO and co-founder of StackHawk. That seemed weird, I shouldn't have done that. I'm too old for that. Thanks for taking time to check out StackHawk. I hope you're having a great conference at GraphQL Galaxy learning a ton.

Today I wanted to talk to you a little bit about StackHawk. Quickly, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications and API endpoints for security bugs and keep them from becoming vulnerable. You can use StackHawk to run active security tests on your running REST API, GraphQL API, SOAP API, oversight application and single-page applications. StackHawk was built for automation in CI CD to be part of your robust testing strategy for your application development life cycle. It also makes finding, understanding and fixing security bugs easy.

How does StackHawk work you ask? Great question. StackHawk runs active security tests against your running applications to ensure that your application is handling user input and output in a safe manner, as well as implementing OWASP Top 10 best practices for application security. We can do this against your running applications on your local host, in CI CD workflows and against applications that have yet to be published on the Internet. We also made dynamic testing fast. By placing the scanner as close to the application as possible, and by using open standards to inform the scanner, open API spec, graph QL, introspection queries, SOAP WSDL in addition to the scanner tuning we've made, most StackHawk customer applications scan average around or under 10 minutes.

Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around the simplicity model. The scanner is configured via YAML that lives with the code for the application that you're testing. When StackHawk findings are triaged, the platform is trying to give you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify the anti-pattern, be able to recreate the issue with tools like simple curl command to replay the attack, and get you into debug mode, stepping through code as fast as possible to help you fix issues and get back to your regular job of creating value for your customers.

All of this is CICD enabled. Again, you can integrate this into your CI process and importantly, get feedback into the CI process on scan findings. This information can be used to break a build if you choose based on severity of untriaged findings. Most of the major CI player logos are shown here on this slide and even if your particular one isn't, chances are pretty good Stackhawk will work in your platform as long as it can run a Docker container. If you can run Docker, you can run Stackhawk. You can also see here Stackhawk integrates with your workflow and information tools. We can notify you of your scan results in a Slack channel, publish that information to Datadog or send you a simple webhook message that you can then use to process and do with the data what you choose.

Let's take a look at what running the Stackhawk scanner against a GraphQL application looks like. So you can see I've got my simple GraphQL application.

It's the basics of a service that would run a blog, and we're testing it today with Stackhawk. So you can see it has some posts and some post ideas, some content, and we want to be able to test that with Stackhawk scanner to see if it has any security vulnerabilities.

So we're going to do that with a simple Docker run command. You can see that I just kicked off the scan right before we started talking today, and I've got a simple Docker runs scan here that is docker run stackhawk hackscan, and I'm feeding it a Stackhawk.yml file. We're going to look at that yml file in just a second.

What you can see here is that it says we've turned on our GraphQL engine and we've got the information for what this host is. So you can see that the host is running on my local host on port 3000, and then you can also see the scanner found eleven different GraphQL routes in the application. Now this is important because it actually knows this from the GraphQL introspection endpoint. It's not guessing what's available in this GraphQL application. It's well documented in the introspection endpoint and the scanner's using that to test against it.

I just ran a scan right before this, so let's jump over to the platform and see what kind of output we have. So here you can see our scan that's already running, but the one I ran right before this is right here. So you can see I've got a couple of different issues. There's some interesting stuff in here that we can look at. What kind of tests ran against this application? What kind of findings do we have? Let's dig into one of these issues, shall we? So I've got two high issues, high criticality issues. And there are a SQL injection and a remote OS command injection.

Let's dig into that remote OS command injection really quickly. By clicking on that finding, it takes us to a simple description of what remote OS command injection is, as well as how an attacker might leverage that remote OS command injection and ways to remediate this problem. So you can see actually we have on our mutation here, our super secret private mutation. We have some kind of a problem. So over here on the request response side of the panel, you can see that during a mutation with this variable, we have now caused some kind of an output that looks like, looks like the output of Etsy passwd file to me. So we're quickly kind of getting into the context of what is this problem? How can I recreate it so I can go fix it? There's a couple of things that are really handy here. One, we've formatted all of these GraphQL requests in a GraphQL type of a fashion. So you can see that the operation and the variables make a lot of sense relative to GraphQL. The other thing that we've done is create this validate button up at the top. So if you wanted to, you could just copy and paste this curl request and replay this against the app. But the thing that I really like about GraphQL is because this is so well formatted and I've already got GraphiQL up, as we looked at before, I can kind of copy and paste our request out, paste that back into our app, and then I can copy our variables out and paste that into the app as well. So now I can replay exactly what the scanner did in my app, in GraphiQL, without too much hassle. So I can see what happened here was, the scanner tried to do a cat of slash etsy slash passwd, which on Linux boxes is where all the user information is stored, not the passwords, the users. And what came out of that was actually the content of that file. So that's bad. We want to be able to get into the application, start debugging and fixing how that actually works. This is really good at setting you up for success on how do I get back into my app, debug, fix this problem and get on with the business of creating value for my customers as a developer.

I hope you enjoyed my talk today and perhaps learn something new about how StackHawk can be integrated into your development workflow. If you like to check out StackHawk and see how you can integrate it into your development process, to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. StackHawk is free to use on a single application. Thanks for watching and joining me with the StackHawk demo. I hope you continue to enjoy GraphQL Galaxy.