Automated Security Testing for JS Apps

Hey, Test.js Summit. How are you? I'm Scott Gerlach, CSO and co-founder here at StackHawk. Thanks for taking time to check out StackHawk. I hope you're learning a ton of new things at Test.js Summit, and hopefully I can teach you one more.

At StackHawk, we do application security testing, specifically dynamic application security testing. Let's talk about the benefits of DAST. DAST can help you identify and prioritize your time on what to fix because it helps identify what's discoverable and likely exploitable in your running application. If you're awash in a deluge of NPM audit tasks, and it's a good idea to go after those. But often the list is long and not everything is a straight version upgrade. But also, how do you know the code that you wrote is safe? And where should you be spending your time if the upgrade path on NPM audit isn't straightforward? This is the superpower of DAST.

DAST can help you find app set bugs that are discoverable, likely exploitable in your running code. You might be thinking to yourself, but frameworks have basically prevented any of the apps that problems from happening. And yes, many frameworks have done a good job of preventing issues like SQL injections and cross-site scripting. But most all of them have the unsafe version of that to help you do your complicated things and unfortunately make mistakes. But some people don't know about DAST and those that do may have run into the problem with DAST.

Let's look at an example. Back in the old days when we built server side applications that ran the data layer and the presentation layer, everything was fine and dandy. The legacy DAST scanner could scan and test the legacy application without many problems. You get good results, identify some serious AppSec bugs and everything was hunky dory. But then something changed. Then we started building JavaScript front ends and the JavaScript front end trolled the legacy DAST scanner and I mean, trolled it. For instance, hey, when does page scrolling end? It doesn't. Where are all the forms? It depends. Legacy DAST was running along, it was happy, totally assuming it was getting all the info it needed to test these new applications. The results were terrible. Scans took forever, false positives for days, et cetera. And the worst part, there was someone else in that back seat as well. Our backing APIs are in there controlling all the data, talking to the data store backends, helping to render elements on the page and the legacy DAST scanner thinks the front end is passing all these requests to the backend. Do we end up testing the API here? No. Are we covering the API, the whole API? Probably not.

Are we even making simple requests to the API? Good old JavaScript front end. It depends. It depends on the browser or browser emulator the legacy DAST tool is using and how well it's driving. What elements it can see, what it can render. If you've built support into your JavaScript application front end for specific versions of specific browsers. Now you can think of this sort of like Selenium scripts. And in Selenium scripts, you write a specific test. I wanna go to this page and then I wanna click on this button and then this should show up, right? That kind of Selenium test.

DAST is like that, except for you're expecting it to find all of the possible user input paths by itself and do a good job. It's just not gonna happen. It doesn't work well. So how can we get back to better testing, better results, faster, more accurate scans, uncovering these application security bugs that are built into our JavaScript apps now? The key here is driving the API directly. Using industry standards like postman collections, OpenAPI spec, GraphQL, introspection queries, you can have direct access to the API, understand what it does and the data it's controlling and get fast, thorough tests. Nevermind if you're building an API that doesn't have a front-end at all. Mind blown. There's still good things to find in testing the front end in cookie settings and DOM XSS. Protecting all the data that you could end up potentially putting at risk is a better place to start.

What are some of the keys to look for in a dynamic app set testing tool that will help you test APIs directly? First of all, run anywhere. Should run in your CICD, should be able to run against production, but really importantly, should be able to run your local host as you're developing. Should be able to provide real test data, so in the screenshots that we've got over here, we've got the Faker library turned on so that Faker is providing data. We've actually typed in data for some values. Lots of different options to be able to say, hey, API, here's what real data looks like. Also use that with your security tests. Run custom tests for broken access control and insecure direct object access. These are two of the top 10 OWASP API security things, and they're hard to test for without knowledge about how the API works. As you're developing the API, you can write things like tenancy checks, can customer A see customer B's data. Look for stuff like, can a regular user get into the admin functions? Those are some of the really hard things to test for. Now you can write that test once and keep running it over and over and over again to make sure that the API stays secure. Like I said, you should be looking for something that's built to scan modern applications, including server side applications, single page apps, REST APIs, GraphQL APIs and SOAP APIs. All of this leads to faster AppSec testing, faster time to fix and faster getting back to your regular work of building value in the application they're building.

How does StackHawk work? 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 this simplicity model. When a StackHawk findings are triaged, the platform is giving 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 anti-pattern.

Be able to recreate the issue with tools like simple curl commands to replay the attack, and then get into debug mode in your IDE and help, start stepping through the code as fast as possible to help you fix those issues and get back to your regular job. All of this is CI CD enabled. Again, you can integrate this in your CI process and importantly, get feedback in the CI process and the scan findings. This information can be used to break a build if you choose based on the severity of those untriaged findings. Most of the major CI players are integrated with StackHawk. Documentation's out on docs.stackhawk.com if you're interested. If your particular version of CI isn't listed, it's a good chance that StackHawk works with it as long as you can run Docker or a Java process.

Here's maybe the most important part. I mentioned this before, but you can run these same AppSec tests locally that you can in CI. So you can identify a problem, fix it, and validate that you fixed it locally before you push your code back into the CI CD pipeline, cross your fingers, and hope that I got it this time. I hope you've enjoyed my talk today and perhaps learn something new about StackHawk and how StackHawk can be integrated into your API development and testing workflow. If you'd 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. Thanks for watching and enjoy the rest of TestJS Summit.