GraphQL Galaxy

GraphQL Galaxy 2022

Modern GraphQL API Security Testing 

What's up, GraphQL Galaxy? I'm Scott Gerlach, CSO and co-founder at StackHawk. Thanks for taking time to check out StackHawk, and I hope you're learning a ton of new things at GraphQL Galaxy 2022. Hopefully I can teach you one more. At StackHawk, we do application security testing, specifically dynamic application security testing, or DAST. Let's talk about the benefits of DAST. DAST can help you prioritize your time on what to fix in application security issues because it helps identify what's discoverable and likely exploitable because it's testing the running GraphQL API. This is the superpower of DAST. Where should I focus my time fixing API security issues? You might be thinking to yourself, but frameworks have basically prevented any of the common app sec problems from happening. And yes, many frameworks have done a good job preventing issues like SQL injection and cross-site scripting. Almost all of them have an unsafe version of all of those protection mechanisms to help you do complicated things and unfortunately make mistakes. Not to mention things like tenancy filtering and function authorization can be hard to get right. Some people don't know about DAST and those that do may have run into problems with DAST. Let's look at an example. So here we are back in the good old days of legacy DAST. And when we built server-side applications that ran the data and presentation layers, everything was fine and dandy. The legacy DAST scanner could scan and test the legacy application without many problems. You get good results and identify some serious app sec bugs. And then something changed. Then we started building JavaScript frontends. And the JavaScript frontend really trolled that legacy DAST scanner. When I say trolled the legacy DAST scanner, I meant really troll it. Like when does the page scroll end? It never does. Where are all the forms? Well it hasn't rendered yet because your mouse isn't in this exact pixel. Legacy DAST was running along its happy way, totally assuming it was getting all the info it needed to test these new applications. Results were terrible, scans took forever, false positive for days, etc. And the worst part is it never realized there was someone else in that backseat as well. Our backing APIs are in there controlling all the data and talking to datastore backends, helping to render elements on the page. And the legacy DAST scanner thinks the frontend is passing all these requests to the backend. Do we end up even testing the API here? Are we covering all of it? Are we even making simple requests to the API at all? Well because of JavaScript frontends, it sort of depends. It depends on the browser and the browser emulator that the legacy DAST tool is using and how well it's driving that browser. You can think of this like Selenium scripts, but instead of a specific set of functions, you're executing it to find all the possible user input paths by itself and hoping it's going to do a really good job. Even Google doesn't do this well. So how can we get back to better application security, API security testing? Better results, faster, more accurate scans, better coverage, especially around this data layer where all the assets that we're protecting are being stored. By driving this API directly using industry standards like GraphQL introspection, you can have direct access to the API, understand what it does and the data it's controlling to get fast, thorough, accurate API security testing results. Not to mention now you can test microservices as you're building them and find these application API security bugs before they ever get shipped to production. There's still good stuff to find by testing their frontend, cookie settings, DOM XSS, lots of different headers, but starting where the data is held is a better idea. What are some of the keys to look for in dynamic AppSec testing tool that will help you test APIs directly? This is where StackHawk comes in. StackHawk runs active security tests against your running API to ensure your application is handling user input and output in a safe manner, as well as implementing OWASP top 10 API best practices for API security. We do this against your running application on your local host in CICD 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 using open standards to inform the scanner like GraphQL introspection queries. Not only do we make run anywhere testing possible, we've also enabled real data in testing. So providing real data to drive the API, whether that's made up with faker libraries or provided directly through the configuration. Using real data is important to be able to test accurately GraphQL APIs. Running custom tests is no problem for StackHawk. Testing for things like broken access control or insecure direct object access, those are some of the top two OWASP API security issues and you can write custom tests with StackHawk. Again, build to test modern applications, including GraphQL, using GraphQL interfaces, presenting data in a GraphQL format, makes testing GraphQL, reproducing failure scenarios and fixing API security issues with StackHawk very easy. Our focus as a company is to help developers find and most importantly, fixing security issues. The StackHawk scanner and the platform were built around this simplicity model. When StackHawk finds an API security issue in your application, the platform is trying to give you the simplest version of the information needed to help you quickly understand what this problem is with simple descriptions and examples of patterns to help identify the anti-pattern. Being able to recreate issues with simple tools like curl to replay the attack, get into debug and 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 in the CI process on scan findings. This information can be used to break a build if you choose based on the severity of untriaged findings. Most of the major CI players logos are on this slide. As long as you can run Docker or a Java process in your CI system, you can run StackHawk. And here's maybe the most important part. You can run these same appsec tests locally. If you're developing an API on your local machine, you can test for API security issues while you're writing code. You can identify the problem, fix it and validate that you've fixed it before you push your code back into CICD pipeline. I hope you enjoyed my talk today and perhaps you learned something new about how StackHawk can be integrated into your GraphQL API development process. If you'd like to check out StackHawk and see how it can integrate into your development process to keep pushing the limits on software development quality, come check us out at stackhawk.com. Thanks for watching and enjoy GraphQL Galaxy 2022.


Scott Gerlach

React Summit

React Summit 2022

Automated Application Security Testing 

What's going on React people? I'm Scott Gerlach, co-founder and chief security officer over here at StackHawk. I hope you're really enjoying React Summit. Let's talk 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, server-side application and single-page applications. StackHawk was built for automation and CICD to be part of your robust testing strategy for your application development lifecycle. 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 application on your local host, in CICD 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, GraphQL, 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 this 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. 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 looks like. As you can see here, I've got a standard server side application. This one is a polls app that I want to test for security issues. So over here on my command line, I've got a simple Docker command that I ran. So Docker run StackHawk. I fed it the StackHawk YAML. We'll look at that in a second. As you can see, it did a standard crawl looking for all the interesting things on the web page that it could, and then it did an attack. So it actively attacked this application for potential security issues. When it was all done, we've got a summary of these findings. So I've actually got a SQL injection issue that I need to take care of. You can see that it's new. I also have a cross-site scripting issue that I've done something with before. I actually made a ticket out of this. So now it's in an assigned status. We've got a bunch of other things that we can look at as well, but let's take a look at those too. Down here at the bottom, we actually have a link to this scan, so we can actually take this link and paste it into a browser. By the way, output in a CICD system would look very much like this because this is the standard output. So if you did choose to break a build, you would have this same link in CICD output. So we can go over here to our web browser and jump right into the scan that we're looking at. We were just looking at this exact same scan. We've got this SQL injection issue that we can look at quickly. You can see that we've got a SQL injection issue. We're quickly describing what SQL injection is, how to remediate it, what it's about, and what risks it might pose to an application. We also have links to different language frameworks that show you the pattern of how to prevent SQL injection in Spring, Laravel, Django, and Rails, so that you can help identify the anti-pattern that we're looking for. Let's take a look at this particular issue here. So we can see that on the polls SQL path, we have a post method that has some kind of an issue. Over on our right-hand panel, we've got a request and response of what the scanner actually did and then came back with. So we can see that the scanner made a request here against the application, and it responded in some form or fashion. We can actually see that the scanner made a case when injection here. So we could replay this if we wanted to. This is all helping you understand what the scanner is trying to do and what issue it thinks it's found. But interestingly, we've got this really cool validate button up here. As I mentioned before, this validate button gives you a curl command of exactly what the scanner did to identify this particular issue. So you can copy and replay this attack against an application. Let's take a look at that StackHawk YAML. Here you can see the code that I've used to build my polls application. Inside of this repository, I've also stored the StackHawk YAML. The StackHawk YAML is how you configure the StackHawk scanner. So you can see the important information that's in here is where do I find the application I need to test? In this case, it's running on my local machine, so localhost 8020. What environment am I in? What is the application ID? That is the minimal amount of information you need to run a StackHawk scan against your application. There are other pieces of information that help tune the scanner to your application, such as authentication, how to handle cookies and CSRF tokens, as well as things you don't want the scanner to scan. If you wanted to add OpenAPI spec or GraphQL, minimal additional configuration is needed to make that happen, to point the scanner at those industry standard definitions of REST API and GraphQL. Now let's say we don't have time to fix this particular issue. We need to get this feature out for our customer, but we do want to fix it. So we can push this quickly to a Jira ticket. So I can send this to a Jira Cloud or Jira Data Center ticket right now from this particular screen. So I can push this issue straight out to Jira, and now I can prioritize that and bring it back out of the backlog when I'm ready to do it in the next sprint or in the next epoch. As you will see, this has now turned into a triaged status issue. So when we come back here to our summary of findings, you can see that our cross-site scripting has been triaged and our SQL injections have been triaged. The next time the scanner finds these things, it will remember that you have triaged them already and it will stop trying to bring your attention to it. If you've configured builds to break, this will undo the build break mechanism and your build will continue as normal. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk can be integrated into your development 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. And StackHawk is always free to use on a single application. Hey, thanks for watching everybody. I hope you really enjoy React Summit. Come see us.


TestJS Summit

TestJS Summit 2021

Automated Application Security Testing

What's up, TestJS Summit? I'm Scott Gerlach, Chief Security Officer and co-founder here at StackHawk. Thanks for taking time to check out StackHawk and I hope you're having a great conference with TestJS Summit. 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, server-side application, and single-page applications. StackHawk was built for automation and CICD to be part of your robust testing strategy for your application development lifecycle. 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 application on your local host, in CICD 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, GraphQL, 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 this 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. 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 looks like. As you can see here, I've got a standard server-side application. This one is a polls app that I want to test for security issues. So over here on my command line, I've got a simple Docker command that I ran. So Docker run StackHawk. I fed it the StackHawk YAML. We'll look at that in a second. As you can see, it did a standard crawl looking for all the interesting things on the webpage that it could, and then it did an attack. So it actively attacked this application for potential security issues. When it was all done, we've got a summary of these findings. So I've actually got a SQL injection issue that I need to take care of. You can see that it's new. I also have a cross-site scripting issue that I've done something with before. I actually made a ticket out of this. So now it's in an assigned status. We've got a bunch of other things that we can look at as well, but let's take a look at those too. Down here at the bottom, we actually have a link to this scan. So we can actually take this link and paste it into a browser. By the way, output in a CICD system would look very much like this because this is the standard output. So if you did choose to break a build, you would have this same link in CICD output. So we can go over here to our web browser and jump right into the scan that we're looking at. We were just looking at this exact same scan. We've got the SQL injection issue that we can look at quickly. You can see that we've got a SQL injection issue. We're quickly describing what SQL injection is, how to remediate it, what it's about, and what risks it might pose to an application. We also have links to different language frameworks that show you the pattern of how to prevent SQL injection in Spring, Laravel, Django, and Rails so that you can help identify the anti-pattern that we're looking for. Let's take a look at this particular issue here. So we can see that on the polls SQL path, we have a post method that has some kind of an issue. Over on our right-hand panel, we've got a request and response of what the scanner actually did and then came back with. So we can see that the scanner made a request here against the application and it responded in some form or fashion. We can actually see that the scanner made a case when injection here. So we could replay this if we wanted to. This is all helping you understand what the scanner is trying to do and what issue it thinks it's found. But interestingly, we've got this really cool validate button up here. As I mentioned before, this validate button gives you a curl command of exactly what the scanner did to identify this particular issue. So you can copy and replay this attack against an application. Let's take a look at that StackHawk YAML. Here you can see the code that I've used to build my polls application. Inside of this repository, I've also stored the StackHawk YAML. The StackHawk YAML is how you configure the StackHawk scanner. So you can see the important information that's in here is where do I find the application I need to test? In this case, it's running on my local machine, so localhost 8020. What environment am I in? What is the application ID? That is the minimal amount of information you need to run a StackHawk scan against your application. There are other pieces of information that help tune the scanner to your application, such as authentication, how to handle cookies and CSRF tokens, as well as things you don't want the scanner to scan. If you wanted to add OpenAPI spec or GraphQL, minimal additional configuration is needed to make that happen to point the scanner at those industry standard definitions of REST API and GraphQL. Now let's say we don't have time to fix this particular issue. We need to get this feature out for our customer, but we do want to fix it. So we can push this quickly to a Jira ticket. So I can send this to a Jira cloud or Jira data center ticket right now from this particular screen. So I can push this issue straight out to Jira, and now I can prioritize that and bring it back out of the backlog when I'm ready to do it in the next sprint or in the next Epic. As you will see, this has now turned into a triaged status issue. So when we come back here to our summary of findings, you can see that our cross-site scripting has been triaged and our SQL injections have been triaged. The next time the scanner finds these things, it will remember that you have triaged them already and it will stop trying to bring your attention to it. If you've configured builds to break, this will undo the build break mechanism and your build will continue as normal. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk could be integrated into your development 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. And StackHawk is always free to use on a single application. Thanks for watching and enjoy TestJS Summit.


Node Congress

Node Congress 2021

Safely Handling Dynamic Data with TypeScript

Ethan Arrowood

JSNation Live

JSNation Live 2021

Securing Node.js APIs with Decentralised Identity Tokens

Welcome to this talk, where we will learn more about securing a Node.js API using decentralized identity token. My name is Mohammad Shahbaz Alam, a developer advocate at Magic. In this talk, we will learn what is a decentralized identity token, build a Node.js API using Express and then protect that API using Magic. So what is DID token? DID token created by Magic is adapted by prior tech like JWTs and W3 DID protocol. It is encoded as a base64 string, a JSON string tuple, which is representing proof and claim. It leverages the Ethereum blockchain algorithm and elliptic curve cryptography to generate verifiable proof of authentication and authorization. These proofs are lightweight digital signatures, which is shared between client and server to manage permission, protect routes and resources and authenticate users. A typical DID consists of proof and claim. Claim is the unsigned data representing the user's data and proof is by signing that using Ethereum's personal sign algorithm and using user's private key. And then you get the DID token by calling b2a and using base64 JSON tuple string. So this is how a basic generating DID token looks like, which consists of issue.expiration, subject, DID, not before time and all sort of information over here. The issuer is the user's public key in the claim and when we are signing using sign function, we use the user's private key, which is again, we don't look those data. And then you get the, we encode the DID token so it can be easily transported over HTTP. And the easiest way to get started with Magic is using Magic's client SDK. The client SDK is where you get the DID token. So you use that, pass on the API key, which is like two type of API key. One is the publishable key and another one is the secret key. Secret key is used for server, publishable key is for client applications. You call a function called login with email and then pass on the user's email. By default, you will get a DID token of a lifespan of 15 minutes, but if you want more than that, you can call getIDtoken function to get that. The user flow or the auth flow is that a user calls the client to get, by authenticating himself or herself, they get the DID token and they trade that DID token in the authorization header to the server and server validates that token and then allows the protected route. So let's build the API. Easiest way to get started is to run npx make magic and select the template express API. So I have already done this and you would see that I ran an application. I'll just showcase what it looks like. For example, npx make magic template express API. It will ask for your application name, test API, and then you can use the publishable secret key. For example, you can get this secret key by logging into magic and signing up. It's free to do that and copy the secret key from the application folder. If you're not seeing this, you select this and select your application and then reveal the secret key. Just paste in here and then select your application. That's it. Once that is done, it will be open and it will look something like this. So your application is running on port 8080. It has multiple routes. The normal route is the basic route, which gives you an unprotected route. The other one is the secret route, which is protected by a middleware, which we have wrote, which you can always see by seeing the example. So I have already created an application called JS Nation. Just see this in this function, you would see that nothing much is happening, but this is a very basic API where we are using magic secret key from the environment variable. We are using a port variable as well. And then we are instantiating the magic here. And then this is a list of to-do, which is simulating the database, but obviously you would need a proper database. So this is an unprotected route. This is a protected route. You protect this by calling isAuthorized. So I'll show how it isAuthorized function looks like. So this is a middleware and these to-dos are like unprotected API routes. It's getRequest and getOfOneID, like getting the first to-do or the second to-do. These are unprotected. So another way of using the protected route or the middleware is to use app.use and pass on the authorization functions, what we have called isAuthorized. And then all these routes are by default protected because we are using here. So if we want to use it the older way, we would have to pass on to all of the functions over here. So let's see how the isAuthorized looks like. It accepts request, response, and next. We check first the authorization header is not defined and then extract the DID token from the header. And then we call magic.token.validate, which shows you if there's an error, they will say that there is an error. And else we would continue by calling next. And vice versa, you can find more of the details when you run NPX MakeMagic and this template. So the easiest way to see this is by getting a DID token. The easiest way to get the DID token, again, to run the NPX MakeMagic and template, use the next template, which is what I have used. And then it will run your server and it will, once you log in, it will give you a DID token. So once you do that, just pass on the secret key over here. And I have pasted this and you would see that this is asking for that, like we are allowed. And if not, we would say that this is failed. And it has update, put, delete, all sort of restful verbs, HTTP verbs. So more on that, you can find more. So easiest way to run is by getting the DID token is from the front end, by running this particular command, NPX MakeMagic and selecting a template next. By default, next won't give you much help, like in terms of DID token. So what I have called is that I have taken a DID here and then calling the get DID token and then displaying the DID token. Feel free to explore the docs at Magic. And then, yeah, this is the resources you can find and learn more about. And if you run into any trouble, just run NPSMDSPZALM, my username, and then all bunch of information would be there. Feel free to reach out to me if you have any question. So yes. Thank you again, GS Nation, for having me and for a wonderful conference. Hi. Bye-bye.


Mohammad Shahbaz Alam

#api security