Automated Security Testing for JS Apps & Underlying APIs

What's up, JS Nation Live? Scott Gerlach, co-founder and CSO of StackHawk here. Thanks for taking time to check out what StackHawk has to offer. Real quick, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications. That's application and API security testing. REST APIs, GraphQL, server-side HTML, and single-page apps. StackHawk was built for automation in CICD. Makes finding and fixing security vulnerabilities very, very simple. A little bit of how it works. First of all, it scans your application, and by scans your application, we mean it runs anywhere. You can run it on your local host while you're writing code, testing your application, back that up in CICD, test your application there before you push it to prod. And then again, if you want to, you can run it in prod. It's built to scan those modern applications, like I mentioned, server-side HTML, single-page apps, REST API, where you have an open API spec, and GraphQL, where you have GraphQL introspection queries turned on. All of those things help inform the scanner as to how to do a good job testing your application for security vulnerabilities. Once the test is all done, it does a really good job of showing you where those problems are found and potentially how to fix them. Finding and fixing those security issues is super simple with the StackHawk platform. The StackHawk platform presents you with the criticality of an issue, the issue type, the path, and the request-response pair that actually generated the issue. The other thing that's really awesome about the StackHawk platform is there's a curl recreation of that finding. So there's a curl command that you can copy and paste and run the same attack that the scanner did against your application. To be able to put your application in debug mode, step through that code and quickly find where you may have made a mistake. All of that is set up for CICD, and you can break your build. You can set up the StackHawk scanner to exit non-zero if it finds an issue of a severity type medium or higher, high or high or higher, low or higher. All of those things are totally configurable in the StackHawk platform. It does not do that natively. You can configure that for your own work. StackHawk integrates with your engineering stack. As you can see, I've got icons from some of the major popular players in CICD. StackHawk works with all of them. It's because it's Docker based, if your CICD system can run Docker, it can run StackHawk. Let's jump into a quick demo to see how StackHawk works. Here you can see I've got my vulnerable Django application. This is just a basic Django application, so server-side HTML, and I'm testing it with my StackHawk scanner. The way that looks is I've got a simple Docker command, docker run stackhawk hawkscan. I pointed out the configuration file, which we're going to take a look at next. What happens is the DAST scanner crawls your application, looking for interesting things to test, and then tests it. Once that's done, you get a simple summary of what's happening, what StackHawk found. Here you can see I've got a cross-site scripting issue, a SQL injection issue, and some lower issues. We'll focus on those highs for today. At the very bottom of this, I've got a link back to the StackHawk platform. This is exactly the same output you'd get in CICD. If you chose to break build in CICD, you'd have a link to be able to go triage these issues. That StackHawk configuration file we were just talking about is as simple as this. We believe in configuration as code, so DevOps principles. This particular configuration file lives with the code that it's testing. Is checked in a Git? You have Git history on who's changing what and when. Now importantly here, the things that you need to make StackHawk work are these fields right here. You've got to tell it the application ID, which is something we get out of the platform. You've got to tell it where to find that running host. In this case, my Django app is running on local host port 8020. What environment do I in? That's it. That's all you need to make a scan work. Obviously there's more that you can do to configure this file and make the scanner work better with your applications. Things like authentication, paths to ignore where you don't want it to test, where to find the rest API, open API spec or the GraphQL introspection, etc. But in this case, we're working with a server side application. Let's jump over to the platform. Here you can see the output of the scan that we just ran. So you can see my cross site scripting issue that we found, the SQL injection issue that we found. There's lots of other great information on this panel, but you can also see what plugins ran in StackHawk as well as the paths that the scanner discovered. This helps you get a good sense of what's being tested and how good that coverage is in describing your application. Let's go look at that SQL injection issue. So here you can see we've got a SQL injection issue on this polls SQL path in both the post and get methods. But over on the right hand side of our panel here, we've got request and response for both of these things. So selecting them changes the request response and you can flip in between. So you can see in this post issue here, we can see exactly what kind of post was made to our application and we can see how the application responded. Here's that validate button that I was talking about. So here's exactly the curl command that the scanner ran against your application. Now I can copy and paste that, get my application into debug mode and try to find where I've made the SQL mistake. Now you'll notice that I've already triaged these two particular issues and put them into JIRA tickets. We have a native JIRA Cloud integration to be able to push information out to JIRA Cloud. And you can see this is exactly what it looks like. So when I push this, if I can't work on it today as a developer, or I need to get it prioritized by our product team, I can push this out there as a ticket, get it prioritized. But the really important thing is once this ticket comes back around and we find out that we need to work on it, it has a link that takes you right back to this triage screen. So you can get into the context of what I need to look at and how to fix it very, very quickly. Other interesting things that happen in here, StackHawk has the ability to break down all of your applications into their microservices and test them individually. That makes scans faster, more accurate, and less false positive. So here I have all the applications that I remember testing, and I could go through this and kind of get a good overview of the security posture of those applications. Integrations that we have, as we mentioned before, lots of CICD integrations. All the major players are in here. And if they're not in here, it almost certainly works. We just haven't documented it. I've also got that Slack notification turned on in my account so that I get notifications of when scans start, when scans stop, and the summary of those scan findings. And then again, that Jira Cloud integration. If you want to check out StackHawk and see how it can help improve the quality of software that you're putting out there, reduce the amount of security bugs that you're publishing to the internet, you can always hook up a free StackHawk account and check it out for an application. I hope you have a great time at JS Nation. Thanks for checking out StackHawk.