Software development has changed - Frequent deployments, APIs, GraphQL, Cloud Architecture and CI/CD Automation are the norm. So why is security testing the same way it was a decade ago?
Leading teams are realizing that periodical penetration testing and security audits is not enough when code is being shipped daily. Instead, these teams are using developer-centric tools to run automated security testing in a CI/CD pipeline. Join Zachary Conger as he walks through how to automate application JS security testing using GitHub actions.
Transcription
Welcome test JS workshop invitees and attendees. It's great to see everybody on here. I wanted to welcome you to our little show that we've got. What we're going to do. Today is automate web app security testing using GitHub actions. And this is really fun interactive Workshop. All you really need to attend is a web browser. It helps to have a Discord the Discord app. We're going to be doing a lot of chatting in Discord and I'll tell you about that in a minute. But what we're gonna do basically is we're gonna we're gonna Fork a repo for a sample application a node.js application. And we're going to subject that to an automated build and test routine using GitHub actions, which is github's ci/cd system that's built in to GitHub and it's free for use for for anybody. Um for up to like 2,000 minutes a month something like that. So we're gonna build that application and then we're going to subject it to a bunch of testing a variety of different security tests. And again, all you really need is a web browser because everything we're going to be doing is through the GitHub web interface so we can create files for repo create file the files that we need run the tests that we need using GitHub actions and so forth. What you need for this really the the primary thing that you need to join us is to join our Discord. and to join the October 2022 web app security testing channel in Discord. So I'm going to post that link here for everybody. So if you can go to the first link that I provide the discord.gg xnmb bubble blah, click that link and you should join our Discord server. And then from there in the general Channel just give a thumbs up to our welcome message not allow you to see the rest of the channels then once you're there join that October 2022 web app security testing Channel. And then when you get into that web app security testing Channel, give us a thumbs up there too so that we know that you're in there. We already have a question. This is awesome. So it seems that I cannot check out the repos. Don't worry about that. You can just look at the read bow through our website. We're just following along in the readme that's in that file in there. So I'll show you what that looks like when you get to this Workshop GitHub actions GitHub repo all you really need from there. Is this readme and you can click on links to get to stuff in there. The first thing we'll be doing when we when we create the app is we're going to Fork another repo. All right. Looks like we've got. We've got folks joining in on the Discord server. GitHub Link in the discussion panel window. I think you're I think we mean this window. So let me give you this link. So here's the workbook or the guidebook or the workshop that we'll be going through. If any of this stuff is not working. You should still be able to follow along again. Really. All you need is a web browser and an accent access to GitHub. So a GitHub account. I'm going to go ahead and begin. Feel free to drop questions and and help each other out in the Discord chat. And and Mimi if you can help folks along who are running into trouble, that would be awesome. I'll just begin with the Sunday. Thank you. All right. So here we go. We love questions, please drop us a chat in the Discord. We love to help out. My name is Zachary Conger. I'm a Solutions architect for stackhawk. I have some Hobbies. I really like devsecops and this whole Workshop is about Dev set secops routines and practices. It's a really fun Workshop. You can take everything that you learn from here. It's should be really useful in your work life as well as your own home personal projects for working on your own applications securing them building them automatically that sort of thing. So I want to tell you a little bit about the company that I work for stack Hawk. It is one of the tools that will be using at the end of this workshop. And what we do is we've got a security scanning tool. It's called a dashed utility. That's the class of security scanning tool that it is which means that it's a dynamic application security tester, which means that it runs against you running application. It actually probes your running application for vulnerabilities by sending in malicious requests and looking at the responses. And that class of utility dashed has been one of the hard ones to automate in cicd, and we believe that we've cracked that that difficulty. A couple things about us. We're closer to the code. We're developer oriented tool easy to automate in cicd. I've got great coverage for web applications as well as apis. And we've got a really simple configuration that just requires a yaml config and we'll talk more about that later in the workshop. Our agenda today is going to be to use GitHub actions to automatically build a node application. Then we're going to add a bunch of tests to that build process that we're going to set up. So first one is going to be a tool called dependabot. It's another GitHub tool that can be used to scan your dependencies and look for vulnerabilities in those dependencies. Then step three is going to be we're going to add code ql which is another GitHub utility and that's going to scan your code base and look for vulnerable patterns in in the actual code of the application and flag anything that looks like it might be dangerous. And then the final step is we're going to add stack our that's our desk scanner and it's a dynamic scanner. We'll use that to scan an instance of the running application in the pipeline. So this build pipeline at the end of it is going to build your application test it with for dependencies for dependency vulnerabilities test it for code vulnerabilities, and then finally test it for runtime vulnerabilities. All right. So the first step is going to be to set up our GitHub actions. So GitHub actions if you haven't heard about it, it is a cicd system that is built into GitHub. Everybody has it available. As long as you've got a GitHub account. It's free. So in your free GitHub account you can use this for your own code bases. it uses a simple yaml configuration language and it's got a huge Marketplace place of what they call actions and actions are like Jenkins plugins if you've ever used Jenkins They're basically a little packages of functionality that make it really easy to put together a build pipeline that does really interesting things. You can use it to build Java applications or node applications. You can use it to run all kinds of various tests and so forth. It's event-driven. So you can really put together very complicated and sophisticated pipelines using it. You can hit it via API. It's got built-in Secrets management, which is really important for security testing and for security in general because there are some things that you want to be. Pulled into your ci/cd pipeline sometimes like maybe passwords or API keys, but you don't want to put that in your GitHub repository because that can be a security vulnerability in itself for other for other people. It might it might come into contact with people who you don't want to know what those secrets are. And finally, it is free so you can use it for you get 2,000 minutes of build Time free per month, which is really quite generous. So to begin, let's just go ahead and do that. So if you should be logged into GitHub and we are going to what we're going to do is we are going to Fork this application called vulnote Express in the car repository and we will provide a link to that Mimi is dropping a link into the Discord and we should probably drop it into the zoom chat as well. Just to be sure. So when you get here. What we're going to do is just Fork this application. So from this main page from the volnote express code repository, you'll see of course all the files in there. But this button up here that says Fork just click on that. And you're going to Fork this application over to your own Repository. Or your own organization. So my my organizations called e Conger you might have a couple or your own personal one just make sure you're pointing at your own repository and hit create Fork. So again from this repo I hit the fork button. And then I entered the name of the repository that that I want to copy over. We'll hit create Fork. And in just a couple of seconds, you should have a fork in your own organization. So now I've copied it from caca to my own org e-conger. It's called Full note Express and it tells me that this was Fork from cacao. volnote Express And Mimi, let me know if there's any questions if you need me to back up or anything and go over something. Totally I think we're all good so far. I'm answering a couple questions in the chat and everyone. If you could give a thumbs up to each step in the Discord along the way when you've completed it just so that we know you're good. And so that we can custom the pace to know we need to slow down or clarify anything for you along the way. cool All right. So from here what we're going to do is I'm going to refer back to this guidebook. So we've already forked the ball note Express app now we're going to go into the code section and we're going to create this new file. The file is called it's in the dot GitHub directory slash workflows slash build and test.yaml. We're going to copy the contents of this file and just drop it in there. So I am actually just going to copy and paste from here. First thing I'm going to do is create this file. To do that from the volnote express Fork that I created go to add file create new file. And paste in the name of that file and it should fill it in for you. So dot GitHub, so remember the the dot at the beginning of that slash workflows slash build and test. This directory structured by the way is special to GitHub GitHub puts. Puts a lot of different files that it may look for in the process of GitHub operations. And this special directory dot github/workflows any file that that GitHub finds in there. It's going to regard as a GitHub actions workflow. And it'll try and run it. So when it sees this file that I'm about to copy the copy the contents of Can just hit copy there and drop that in there. So when it sees this file, it's going to try and determine if it is actually a workflow and if it is it's going to try and honor it and do what the workflow says it should do. And let me describe exactly what the workflow says. It's going to do. So the workflow is called build and test it's GitHub actions workflow. And this build and test workflow is going to be triggered anytime. We have a push to the main branch or any pull request at all. So if we do pull requests to main or any other Branch this whole workflow should kick off. What is this workflow do it's got one job and you could have multiple jobs, but this one's just got a single job called building test. And it runs on an Ubuntu 20.04 instance. This is a full VM. It's got about seven gigs of memory. It's got some additional disk. And it has a ton of different tools. So generally it's a very well well populated server that's got a lot of different tools that you might find Handy for building and testing code. Then we're going to go through a number of tests steps and these steps use actions and actions again are like these plugins these packets of functionality that GitHub provides first one is called checkout V3. And so anything that starts with actions if it's a if it's a GitHub action. This is actually a GitHub created action. So it's one of their standard actions and all it does is check out your code base and it figures out the right right place to check out your code base. I have a question. Can I repeat how to find the path to that file you're showing right now? this file so if you're from the reading it's under step one and and it's called dot github/workflows build and test. And so you're just going to create that file. From the GitHub UI and I'll go back and step through it and in a minute. So thanks for that question. Anyway, so we check out the code and then we're going to install node.js 14x so that we can build our node.js application. And again, we're using a GitHub official action called setup node. And it just goes through all of the difficulty of getting the right version of node installed, which can be a hassle getting the right version of npm install. Then we're going to install dependencies and this is going to go through npm install just like it says and then we're going to run unit tests if there are any and spoiler. We don't actually have any unit tests. But if we did that's what this step would do. So now if I scroll to the bottom and hit commit new file. We will have created that file under dot github/workflows the build and test file is now there. and now you should be able to go over to actions. And see that that workflow is running. This would be a good checkpoint. If you can let us know if you are seeing your own workflow running. should be called create build and test this is the This is the the commit message that we made and if I jump in here. You can see that the one job that it has called build and test is running and you can click in there and see more details about what it's doing. So it's set up the job it checked out some code spinning out a bunch of garbage and installed no JS and npm and it started running through that npm install. Step. So it's installing dependencies. And that really is all that it's going to do and then it will run unit tests, but we don't have any so that step should go pretty quickly. So I'm going to step back and just walk through that process that I just did one more time. So we've got the workshop guidebook and I'm just copying and pasting from it. So from your forked repo. Should be your organization name. Whatever your name is in GitHub. I'll note Express adding a file. That file name is Dot github/workflows. / build and test Dot yaml And then once you do that and start filling it in. with the content from here then you can hit commit new file to create it and just just by having committed that you will have fulfilled. one of the You will actually run that workflow because once you commit something to to the main branch. This workflow says that GitHub actions should run this workflow. So it'll read this file in it'll see that it's got a job that it needs to do it'll read through the steps and it will run them and GitHub actions. So by now if you've gone through all of that, you know usually takes a couple of minutes, but you should have a complete job should have completed successfully and you'll have a green check mark again to see your actions running you go over to this this actions tab, you can see all of the the workflows that you've set up for this repo and you can see Individual run so as we run more jobs in here. You're gonna see this list fill in with more and more commits that kick off more and more builds. All right. How's everybody doing? It's alive. Excellent. cool Is it alive or everyone else Give us a thumbs up. awesome Does it appear twice? That's interesting? So if you if you did to commits, I think you might have done to commits, which is okay. Every time you do a commit to the main branch. You'll see another action run doesn't doesn't matter how small the changes you can do. Even you can even do empty commits. And those will cause the workflow to run. Is great. It's great to see everybody playing along here. It's always awesome when there's participation. All right, so that's GitHub actions. So we've got a simple workflow now, we're going to add some security testing to all of this. So now I want to step back for just a moment and talk about these types of security testing that we're going to do and the characteristic of each one of them and what problems there to design to solve and what what the pros and cons of each approach are and basically what I'm going to conclude is that it's really good to have all of these tools in play if you can but some are better than others that giving you really actionable and and information that you can really use to prioritize where you want to focus your efforts, especially in a team setting. So the first type of security testing that we're going to do is the easiest possible one and that software composition and Analysis. And the way software composition analysis works also known in the industry as SCA is that it really just looks at your dependencies. So there's a bunch of different tools out there that do this and they can operate from your artifactory repository like npm. The npm cloud service has a feature like this built into it Jay frog artifactory has featured built into it. There's also tools that run in in your code base and can check out your dependency file and look very deeply into it and figure out if you're pulling in any dependencies that have known vulnerabilities, basically So when these utilities run they're generally really fast and they're really easy to act on and in fact, a lot of these utilities will provide remediation for you. The one that we're going to use is called dependabot. It's built in to GitHub and when it finds the vulnerabilities in your dependencies, it will generally open a PR to your code base and say hey, I have a fix for this. All you have to do is accept this PR And when it opens that PR in our case since we've set up GitHub actions to rebuild the app. It's actually going to go through the build and test phase and make sure that the change that it's going to that it's trying to make is okay and doesn't break your code. So that's dependent about that's SCA. The next form of testing is called Static application security testing or sased SAS team. And this is a more sophisticated form of code analysis that actually looks at your static code. So to look at your entire code base. So it's language dependent. It needs to understand your code base. And the one that we're going to be using today is called codeql. It's this little icon here. And coql does understand node.js as well as Java typescript and understand c-sharp and understands a lot of languages. And what it'll do is it'll try and compile it and sort of index it in a searchable form and it's going to analyze that code base for patterns that look like they could be vulnerabilities. So for instance, it might look for user inputed variables. And if it sees a user input at variable and you use that it and put it valid value to create a SQL query. then it's going to make sure it's going to look and make sure that you've sanitized that variable before using it in the query so that the user can't inject malicious characters that could be used to do bad things to your SQL database. The cool thing about tools like this about sased Utilities in general is that they can give you really specific information about where the problem is in your code. So you can point to the exact file and the exact lines of code where the problem is and it finds your bugs that you have written not just bugs in your dependencies. The problem with it is that it has a lot of high false positive. It's kind of a hard thing to do to test for these things and when it does findings, even if they are accurate findings. What they're sharing your potential vulnerabilities, they can't really prove that these potential vulnerabilities really exist in the runtime application. So Pros, you can get to the file in line where the problem is and that's a lot of really useful information to developers cons. They might not be real bugs. So it's hard to prioritize fixes based on results that you get from fast. Finally Dynamic application security testing or dashed is the kind of tool that stackhawk provides. There's a bunch of examples of it out there in the wild oasp. Zap is an open source type of utility that's completely free for use. There's another one called burp Suite that you may have heard of it's sort of the big is the big old desk utility that most people in this space know about In the way, this utility works is or these types of utilities Works. They run on that they operate on the running code. So you actually have to stand up your application. And then run the scanner against that application and it will send in inputs and it'll look for outputs and what it's trying to do is prove that it can exploit for instance for instance a sequel injection attack. So it will try and do a SQL injection attack and gather evidence that that attack was successful and then if it thinks that it's found vulnerabilities it will tell you what vulnerabilities have found and it will show you those input and output details so that you can recreate the problem and hopefully fix it and be able to verify that you fixed it. Again, it finds your bugs. It tends to have very low false positives and when it finds problems it is generally it is confirmed vulnerabilities. It is actually tried to exploit those vulnerabilities and shown that it could exploit those vulnerabilities. So those are the things that we're going to test and we're going to start with that CA and I'm gonna pause for a moment and see if there's any questions. We do have one question. It's the Discord link. So let me give you that. So I'm I'm copying the Discord link to the zoom chat. So join there give us a thumbs up on the general page. and then please join our October 2022 web app security testing. Channel there you go. Okay, cool. Moving on our next step is dependabot. So this one's going to be really easy to set up. Let's go back into. Actually, let me tell you just briefly about dependabot. So dependabot is a free service for all GitHub repositories. It is enabled by default on any public repository. So if you just create a public repo, it should be enabled by default. It's also easy to add to private repos and that's what we're going to do now because we forked it. It didn't enable it on it by default. It wants you to enable it explicitly. So we'll do that. And that's exactly the same process you'd use for private repo. It's also free on private repos. You can use this on any of your code. As we mentioned it finds libraries with vulnerabilities and it automatically issues PRS for any fixes that it thinks that it can do and those PRS of course will run through any automation that you have. So those PRS will kick off the GitHub action workflow that we already set up. does have some false positives in practice you should definitely always follow its advice if you can and stay up to date but sometimes it's false positives just in the sense that you you may not be your code base may not use enough of the library to expose the vulnerability that is that is known to be present in the Vulnerabilities that it finds for the libraries that it knows our vulnerable. Okay. Let's move on. So what we're going to do is go over to the you see how I describe it in here because there's a couple different ways to get into this. We'll go to the settings section of the repo. We're going to find the code security and Analysis section. And then we're going to enable the dependency graph dependency alerts dependabot security updates. So from your cloned repo or your fork repo go over to the settings tab and then find the code security and Analysis section. We're going to turn on the dependency graph. So this is the feature that's going to allow GitHub to look for and find your dependencies file. And in this case, it's the what is it called? The package.json file and the package lock.json file so they can understand what dependencies we're trying to pull in. Then we're going to turn on depend about alerts so it can let let us know when it finds vulnerabilities. And then we're going to turn on depending about security updates. So this is what's going to allow GitHub to open PR as for any vulnerabilities that it finds. If you want, you can also turn on version updates. So not only is it going to look for vulnerable libraries? It's just going to look for. Hey, is there a new version of any of these libraries that you've pulled in? I don't turn that on myself, but you're welcome to it'll find a lot more stuff in that case. Let's skip code scanning for now. We'll come back to we'll come back to that in a minute. So if you have done this and again the path to get here is go to settings. And then code security and Analysis. And then turn on the dependency graph. Depend about alerts and dependabot security updates. And if you have done that, then you should already see some security updates because it's so fast. It was already able to determine that. I've got a bunch of bunch of libraries that are problematic. So come over to your security tab where you should have a badge says 18. Or so in my case, it's 18 and then we're going to go into the dependabot. Section over here and we can see what those problems are. And there's really quite a few. critical and high security issues I'm going to stop for a moment and see where folks are at. I've got a couple chats in the zoom. No, it looks like we're good. Awesome. Looks like a bunch of people are catching up here. This is great. Okay, so a couple things to to notice from this page first, we've got like alerts for issues that we're finding. So we've got prototype pollution and Minimus. So I've got a library called minimist. It's an npm package. There is a critical vulnerability in that. Over here you see this pull request indication. So it's already open to pull request for that issue and I'll pop over there in a second to show you what that looks like. And we're not going to merge those pull requests right now. But later on after the workshop, feel free to try merging in some of those pull requests. I walked through this Workshop just yesterday and found that all those pull requests were pretty safe to to apply. But I'll show you what that looks like in just a sec. So you can you can drop into these and they'll give you even more detail typically and Link out to other information for these these issues and obviously you should definitely address any critical issues in your own code and high issues as well. Moderate and lows, you know also good to keep up on but not quite as important. So I'm going to click on one of these. So this is showing me what PR this opened up to try and fix this vulnerability. And you can see it. It actually created a pull request and I've got a bunch of pull requests now and it's tried to it's tried to merge this into the code base and then it ran and you tests that were applicable so you can show all checks and this this is our workflow that we set up in our first step and it ran through it and found that there were no problems. Nothing broke all the tests succeeded so you could just merge this in I won't but if you do it will kick off that workflow again and try and run all of those tests. Um backing up into the whole pull requests section. You can see that there are a bunch of pull requests. They all have this tag dependency. They were all opened by dependabot. And just to round out you know, what what we're seeing here. If I go over to actions, you can see all of these new actions workflow runs each one of these has tried, you know, updating the code based on the pr changes and then it ran through the workflow again built out built out our node express application tried running all the unit tests. That's basically all there is to it as you can see it's really super easy to work with. So now I want to move on. Unless we've got any blockers out there that we need to address. I'm sure Mimi will let me know if there's anything critical I need to back up and repeat. Yeah, looks like no questions at the moment. So I think we can keep going nice. Okay? Next Step codul. So again, this is the SAS utility. It's a code analysis engine. And what it's going to do is it's going to compile our code really in our case since it's JavaScript. It doesn't even need to compile it. And it's going to try and run through the code and look for vulnerable patterns. We'll see if it finds anything. A couple things about code ql it is free for use for public repositories and our repository is public since we've forked it from a public repo. So we're going to be able to turn this on for free and use it. If you want to use it on private repos, you do need to use the GitHub security license and that does cost extra. But if you've got any public repos your own personal projects, you can use it as much as you like. It will use GitHub actions. It's going to add a GitHub actions workflow to go through its own testing. So you do use minutes on GitHub actions. But again, they bake in a lot of minutes per month for free. So it's pretty cheap to operate on public repos. Okay, so let's do it. So again, we're going to go to the actually this time we're going to go to the security section of our repo. We're going to click on a button called setup code scanning. And then there should be a big green button that we can use to configure code ql alerts and I think this this path has changed just slightly, but we'll work through it together. It's going to create this new workflow in the same directory as our old workflow called coach, UL analysis. And then it's going to run it as soon as we commit that to the repo. So from your fork repo, well note Express. head over to the security section and then go into the code scanning section. And configure scanning tool. When I do that it used to be that the default was to just do code 2lm analysis, but they're trying to show that there's really a bunch of security tools that are available here from other companies from the open source community and so forth. We even have one in here that you can use. I think we're down here. somewhere Anyway, we're in there somewhere. But today we're going to just use code2l code ql analysis. So hit configure here on the codeql analysis card. And that'll take you over to this new codeql.yeml workflow file. So this is another just standard GitHub actions workflow. And what this is going to do is it's going to operate anytime. We try and push to the main branch or open a pull request to the main branch. And here's another kind of cool feature of GitHub actions. It's also going to run this job on a schedule. So once a week, it's gonna run this whole code ql analysis. Those are the triggers and then the job that it's got is just a single job called analyze. And then it's going to use some more advanced features of GitHub actions. So it's going to use a matrix strategy and this comes in handy if you've got multiple code bases, but it only found one language in our code base JavaScript and so it's just going to run that but if you found it, but if we found like some JavaScript and some Java and some go it would create this Matrix and run all of the analyzes for all of those in parallel in a sort of Matrix run configuration. Just kind of a standard ci/cd concept, but they do it in a really nice simple way. So anyway, it's just gonna run against our JavaScript code. It's going to check out the repository. It's going to initialize code ql again through this Matrix of languages. It's only going to find JavaScript. It's going to try and build that it's got an auto build routine that tries to discover and understand how to build our app in our case. It's going to be really easy. Then it is going to run the analysis and finally let us know again through the security tab if it's found in any problems. So I'm going to hit commit. And once that file is committed again, and don't worry. You don't need to do any changes. Once that's committed we should be running the action for it. So over in the actions tab, you should see you got two new jobs running. One of them is our build and test job and the other is the codeql job or the codeql workflow. So we could click into the codeql workflow specifically and see how that's coming. So we've gotten the part where we've initialized code ql we ran Auto build and now we're running the analysis at least in my case. And this can take a couple of minutes. It's a bit more complex and compute intensive than SCA checking. So just watch your action and let's see how long it takes to finish and then at the end of it, it should have a couple of results for us and we can go check on those. Hopefully it won't take too long. Do I should have some nice hold music now? So once we see results with they should show up in this code scanning section of the security tab. Still run that code ql workflow on my side. All right, in my case, it's done in your case. It might still be working on it. So I'm going to show what I got. And you know loop back around and see if anybody else got the same same results. So again go to the security tab code scanning section and in here, you should see one finding database query built from user control sources. And what it tells us is that it found. In our service/search.js file on line 6. This line and this exact section of code. That it doesn't like very much. So what we've done here is we are creating a SQL query that we're going to submit to our database back end. And as part of that query we're dropping in some search text that the user inputted. And that search text is built from a user provided variable. And and the code analysis has determined that all we did was accept that text from the user put it in the variable and then use it in this SQL search. We didn't do anything. It didn't find any other instance of that variable where we were checking for problematic characters like percent quote. Which is an escape character that can be used to inject another SQL command into the the query and so it's possible for users to use that to inject other potentially malicious my SQL queries. And we'll see later on that. This is a real bug that coach you all turned up. This is really is something that you should pay attention to but the other cool thing to notice is that it's telling you exactly what you need to do. If database queries such as SQL or nosql query is built from a user provided data without sufficious sufficient sanitization. A malicious user may be able to run malicious database queries, and that is totally true and you can with this application. All right, I will stop for just a quick moment and see if there's any other questions or see if folks have caught up. It's like we're doing good. nice awesome. People are seeing the same thing I am. super cool All right. Let's go on then to the next step. And of course pull me back. If there's anything I need to go back up and show. It's the final step is stackhawk and Again stackhawk is the company that Mimi and I will work for we think it's a great tool. Obviously, we're biased but it really is a unique tool in this space because gas is kind of one of the old standard types of security tests. It's often considered to be a gold standard style of testing because it operates against your running code and it actually tries to exploit vulnerabilities and gathers evidence that it was able to exploit those vulnerabilities. So when you find vulnerabilities with a dash utility, you know that they are worth prioritizing because they're for real and if you run this and if you run these applications in public, you're going to get people trying to attack and exploit those vulnerabilities. So it's a really useful tool for prioritizing what you're going to work on in a team setting in terms of security bugs. but it in the past, you know with the older utilities it's kind of hard to work with they tend to be these big applications that are time-consuming to to configure and operate and they generally have been run manually. So the same kind of tool that penetration testers will use when they do a penetration testing engagement. And so they they tend to run on the same sort of frequency. People will use them once a month or maybe once a quarter and the problem with that is that it's very infrequent when they find vulnerabilities then it's hard to go. See it's hard to go find where those vulnerabilities are. Stackhawks approach is to create this portable scanner that's really easy to run and easy to run in Automation. And that's what we're trying to get to is. Just like those other tests are tests that can run on every PR. We want dashed to be a test that you can run it on PR as well because if you can catch a new vulnerability on PR, you know that a PR generally tends to be just a small amount of code change. So if you run a desk scan and see hey, I've got a new vulnerability on this 20 30 lines of code that I just wrote then you've got really you're in the best position to find and eliminate that vulnerability and retest and see if you actually got rid of it. So to that end stackhawk it's a portable scanner it's based on the open source tool owasp zap, but we've added an online SAS platform so that you can track all of your scan results scan after scan really makes it more usable especially in a team setting It's got a simple yaml configuration as opposed to zaps generally gui-driven configuration. And it's really easy to integrate into cicd. We also have a bunch of other Integrations and one of the big ones is a jira integration. So that as you find vulnerabilities, if you can't fix them in real time, at least you can create tickets out of them so that you can prioritize them and have other people work on them. Later. We've also got a bunch of deep API and graph graphql testing capabilities that we've added to this which we think is pretty unique so you can do really interesting API buzzing things and inject your own data or inject really realistic fake data into your API scans. And we've got a free developer account for one app. So let's just jump into it. So what we're going to do is we will go over to app.stackcock.com and sign up for an account and this is going to be a free account. But all you have to do is go to app.stackcock.com. And meet me Mimi is typing in that that address so you can follow along. And you can set up a new account and you could use your GitHub credentials. Or your Google credentials, which I'll use today or you can set up just a we can set it up with your email address. If you set it up with your email address. It's going to ask you to provide like create a new password and then it's gonna send you a verification email. So you need to go check your email and verify. I recommend Google or GitHub just for ease of use. All right, and I'm going to use my personal account and when you set up your account and GitHub the first thing that you're going to see hang on, let me check the chat. cool Okay. So the first thing you'll see is this if you've used Google or GitHub, so it just says hey, here's what I know about you. Here's your organization name. I'm going to call it my workshop org. To keep it distinct from I have a couple of accounts. And then just hit continue here. Next Step choose your adventure. Let's go with the default scan my application because we're going to just scan the application that we've already been testing. You can you know. You can go with Google firing range that just injects a bunch of sample data. So that you can start looking at scan results without actually having to run a skin. But we will pick our stack scan my application and hit continue. And then now you should see this. So this first step in this Setup Wizard is basically telling you how to install the stackhawk CLI. If you want to we don't need to worry about this today, and we've got documentation on how to do this. So you don't have to worry about this step. But you do need this API key because again, we're just going to run this in in cicd. We're gonna add a step to our GitHub actions workflow that will just run this for us. But we do need this API key, so grab a copy of that. Stash it locally so that you can come back to it. And what we want to do is we're going to set this API key up. Thank you, staccounter. You know, by the way that chat bubble actually does go to people. Behind the scenes who can help you out if you have any trouble. Um, okay, so I'm going to I'm going to grab a copy of this API key. And then let's go back to your Repository. And go into settings and we're going to stash that API key as a secret. So under settings way down at the bottom under secrets, you should find an actions section. And we are going to add an actions secret and I'll step through this one more time. So we'll create a new repository Secret. Please call it Hawk all uppercase Hawk API key Hawk underscore API key and paste your value in there. And that's just because our canned configuration is going to refer to this secret to inject to use this API key in the future. So I'll add that secret. And again the path to get there was from your fork repo go to settings. secrets and actions and then hit new repository Secret. Give us a thumbs up if you 've caught up. And now I will go back to the stackhawk application and continue. We'll hit next. Let's give it a name. I'm just going to call it the same thing as my repo bone node Express. And I'm gonna call it the development environment. And the point of this environment name is really you can scan a single app across multiple environments and we just bucket scary results by environment. You may have different characteristics in different environments. That would give you skin different scan results and that's why we do that. This application is going to be running on the Local Host Port 3000 in the build pipeline that we're going to set up. So just enter HTTP Local Host 3000. I'm going to paste this in. That's the name of your host that you should be entering in the host section here. Important thing to note, it's HTTP not https. The scannel fail if you do https, because when we bring up the application, it's just going to be listening on clear text. I'll hit next and then the application type you can actually just say skip for now or don't know. The other options will sort of ask more questions. Like if it's an API, we can pull in various information to know more about that API or if it's graphql we can you know, we can ask you if you've got a schema file or if you can point to an introspection endpoint and so forth. We'll just skip it for now. We're going to do a very basic scan. Hit next. And then in the final step, you should have this sample stackhawk.ml configuration file and really it's just these. Basically, three line or four lines of code that are important for that configuration file. There's the main app section and in it, we've got the application ID, which is the ID of this application in the stackhawk system the environment development and then the host that we're going to scan so that just tells the scanner everything it needs to know about the scan that it's about to run. Will copy that. And we're going to paste that into a stackhawk.ml. Configuration file in our project and again, we're just going to go through the web browser and GitHub and go set this file up. So go back to the code section. I'm going to add a file create new file. File is called stackhawk dot yell. Yml, not yaml, although I think I actually both will work. And then just copy the contents of that file in in years should look pretty much like this. App application ID environment and host and then when I hit we'll commit this file. And that'll kick off our workflow, but it's not scanning quite yet. We need to add something to our workflow file for this to work. I'm just going to finish this out just so we've made sure that the application exists in the system and we're ready to scan. So again, I just created a new file called stackhawk.yaml. Pasted those contents in and committed this file. And now to get that to run as an action and to get it to actually scan the application in the pipeline. We need to go in to GitHub workflows. and add a step to our build and tests configuration file before we move on to that Zach. It looks like we're still waiting for people to finish the setup of the stackhawk account. So we'll give you guys a couple more seconds and please drop any questions or give a thumbs up. Oh the thumbs up are rolling in now nice. Yeah, I'm just gonna race through that one more time in case anybody missed a step so that configuration wizard. It's going to look pretty much exactly like what I'm about to do now if I hit add an app, I just called it the volume. node Express in the development environment against host http local Post 3,000 then I called it skip for now don't know. And copied and paste that into a new configuration file stackhawk.mel in your code repo. I'm going to remove this new application though. I don't leave it. I don't want to attempt to fate. Don't want to tempt the demo gods. Okay. So it we got a question in the chat about statoc accounts. It says the website says free trial is 14 days and you had mentioned it's free for one app. Can you provide a little Clarity on that Sac? Yeah, absolutely. So when you set up your new account, it is set to a 14-day free trial of the Enterprise feature set which provides a whole bunch of additional functionality. So there's there's things like SSO login so you can hook it up to if you use OCTA or off zero for SSO something like that. You can use that it opens up API access so you can grab information about scans and applications in the system via our API if you want to program against our platform The Enterprise account also supports webhooks so you can send scan data as webhooks to a web hook endpoint. It's just a bunch of advanced features, but after your 14 day trial you still have access to one app and you can continue to work with it indefinitely run as many scans as you want. Okay. so in the dynamic app scanning with stock stackhawks section of the of the workbook We're going to add these lines to our existing the first actions workflow that we set up. So I'm just going to copy these these lines and add them to the end of the file that we created in our first step. So again, that's dot github/workflows slash film and test. Navigate to that file hit this little pencil button to edit the file. And then add these new lines in at the end. Just like that. And this is yaml. You're probably all familiar with how finicky yaml can be with formatting. So just make sure these steps line up exactly with the steps before it. so we're adding these two new steps the first is to demonize the node API service So this this app that we built we're going to actually fire it up in the pipeline and run it in the background. So we say npm Run start to Fire up the web app and then this Ampersand sign in order to put it in the background so we can move on to the next step. So it's up and running and then the next step is to run Hawk scan using our our own GitHub can action. So you run stackhawk slash hot scan action. It's going to pull in that API key that we stash in this Secret store. And then it's going to start running that scan and post results back to the platform. So we'll be able to go see them in the UI. commit this change and once you do that You should be you should have a new action running. And you'll actually have two so make sure you're looking at the build and test workflow. And you can watch this as it. trundles along and it's going to run through the install dependencies step. That's probably going to take a minute minute and a half. Um run unit tests that will take no time damonized the service will take no time. Then it'll start running Hawk scan. And that's the most interesting bit that we want to focus in on. While that's running in the background, excuse me. Let me just show you around the application a little bit. So this first section is the apps page and this shows you a list of all the apps that you've set up in stackhawk. Including any environments that you're running in so you'd get it one of these cards for each environment. And these cards just show you at a glance. Hey here your latest scan results at a very high level summary in the development environment. So how many highs mediums and low severity issues did we find in and also what issues have been triaged either assigned to somebody or marked as an acceptable risk or marked as a false positive if we think that the the test is in error? Then understands as you run scams, you'll start to see this list fill out, you know just see scan by scan all of the scans that are in the system recorded in the system. And we'll go take a look at that in a little bit. This section is about continuous and well about all of our Integrations. So we've got continuous integration Integrations. Basically though we run on an eci/cd platform in the world. All you really need for it to work in cicd is either a jdk because the scanner is a Java application or a Docker runtime so you can run it as a Docker container. We also have deeper Integrations with GitHub that we are working with we may get into today if we can get through this fast enough. We've got a an integration really on many levels with GitHub. So part of what we provide with that is the ability to register stack Hawk as an official PR test. So it'll show up under the list of tests. We can also post. PR Commons back to an open PR to show a summary of the scan results And finally, we've got a GitHub actions integration so we can and we're actually using that currently. That's how we set up the scanner step. We also integrate with sneak code. That's another really great SAS utility that provides really really deep analysis of your code. We've got a great integration with that and hopefully we'll we'll show you a little bit of what that looks like with our GitHub codeql integration. You can send scan results to slack or Microsoft teams or to data dog. If you want to track your scan data there and you're a cloud so you can create tissue tickets from issues that you find. All right. Hopefully I have killed enough time for this to finish. Yes. Good. So if you if you are seeing that your action is complete, too. zoom in on the Run Hawk scan step And it'll create a lot of output but sort of the key information that it provides is. at first it will give you a little summary of the scan that it's going to run and this is sort of a PreFlight check that it's doing so it's just making sure that it's got a valid configuration file. it'll go through a bunch of other validation steps like If you've pulled in if you've set up authentication, so you authenticate to the app that you're scanning. It'll try that and let you know if that worked. If you set up some API Discovery methods like an open API config or Postman Postman collection that you fed into it. It'll try that and see if it worked and it'll fail fast if if any of those steps fails. Once all that is complete. It'll start the scan engine. And it will start crawling and discovering the application give you a little summary of what it found and then it just starts hitting all of the endpoints that it found with every probe that it's got. Once it is scanned completed the scan it will give you a quick summary of results. So at a high level we found too high as 10 mediums and 13 loans and then it'll list out the specific vulnerabilities that it found in this case SQL injection cross-site scripting and a couple of others. But those are really just a summary for your benefit and this is really useful especially when you're running local scans. If you're running it from your IDE, for instance, but the real results are going to be back out on the platform and you can click this link to follow and find it. But if you can't find that link, you can just drop into the scan section and now you should see it listed. Click in there and see at you know in detail what you've got. Now I'm going to pause and make sure everybody else is seeing similar things. Make sure we don't have any. Blockers out there. I'll check the chats. cool Looks like folks are falling along. nice nice It's good crew out there. You guys are keeping up. So this this should be like one of the hardest parts you can get through that that section getting the API key and secrets and getting the workflow updated and everything. This is really this is really great. Okay, so now you should should see your scan details and this page is showing you, you know, a lot of the same things that that the other tools have shown us so far. What are the findings that we found? What is the criticality of those findings? These ones up top Highs are definitely ones you should address. And again since this is a dash utility and we you know, basically collected receipts on the problems. We found you know that you should prioritize these so let's take a look at the SQL injection attack as an example. Actually, let's take a look at Cross site scripting. Because it's a little bit easier to sort of grock. What is going on here? the first thing to notice is that when you click into the findings details, we give you a nice long description or a concise description, but we're we're trying to educate users who come across this so because not all developers are going to understand all of these security issues. We just want to try and explain what it is and how to address the problem. And so we provide this little summary. We've also got a bunch of cheat sheets that you can go to and these are basically showing examples of what this type of problem looks like in different languages and Frameworks. um, and also what the fixes look like in those languages and Frameworks and we also show you what paths we found these on so as we probe to the application. This vulnerability was found on the slash search path in the app. We provide another right side. We've got requests and response data. So this is the request that the scanner sent in including this malicious text that we sent into the search text and then the response we got back in this case. If you if you if you decode this, here's the evidence. This is what we tried to inject into the search field. a little script tag and the response that we got back was that script tag and so in Old bad browsers that don't have Security checks themselves. This would actually pop back a an alert a JavaScript alert tag. So basically what we're doing is what we're saying is we're able to inject scripts into the web app, which is terrible that is that is a problem. That is a high severity issue that you should address. and We've also created this curl command. So this validate button if you click on it, we'll feed you back a curl command. And so if you were running locally running the same app locally and you can try this at home later on if you want to you could actually recreate the attack and see the same response data that the scanner found and this is a great way to sort of validate that you have fixed the problem once you once you try and fix the problem. The idea here is that we're trying to surface this information to developers. If you can do this in every PR and let a developer know anytime. They've created a new vulnerability. It is amazing. They they generally are going to be able to fix that right away. And if they can't they can triage the issue in some way. So you might assign it and if you have the Jura integration lit up, it would create a jira ticket or you could Market as false positive or risk accepted. cool Well, hopefully everybody has gotten a lot out of this and I'd like to show one more thing since we're doing so good on time. And that is the code ql integration. Also want to open it up to questions. I get this point if anybody's got questions around how any of this stuff works we can back up and talk about all of that stuff. But for now, I would like to try and set up the codeql integration so we can start to see SAS results. And let me tell you a little bit about this this integration before I go there. so what we've done at stackhawk and this really is pretty unique to to our utility is we've created a couple of SAS Integrations. And I mentioned that there's trade-offs with all of these different approaches to testing with dashed. We've collected the receipts on every vulnerability that we find. So, you know that it is a real vulnerability in your runtime application. And that means you should really prioritize fixing that. But the evidence that we show is a little bit limited we can show you the request data that we sent in and the response data that we got back and we can help you validate that. But it would be really handy if you could take a look at the code and understand where in the code base. The problem is we can't really do that from this outside in approach to testing. Conversely sast has the exact opposite set of trade-offs. So SAS can look at your code and it can find vulnerable patterns and it can point you to exactly lines and files where the problem might lie, but it's less accurate. It can't actually tell you if it's a real vulnerability that's really expressed in in the runtime application. So the nature of this integration is to try and surface both in from both bits of information at the same time. So you can prioritize it based on dash results, but get that extra bit of evidence that really helps developers find the exact line of code that they need to look at to fix the problem. So we get that dasst accuracy plus detailed sass evidence. So, let's see if we can set that up. head back into the stackhawk application and go to this. Checker box section our integration section And go to the GitHub integration. And click on that. And then just hit the enable GitHub button. And point to your organization where you want to install the GitHub app. And then you could you could light it up for all repos if you want to or you could just narrow it down to the repo that we're working on today. Which is what I'm going to do. So I'll find it's called Vol node Express. And I'll hook it up there. And so it's going to give us it's gonna give the get or the stack Hawk app access to the code and metadata and security events and give give read and write access to commit statuses and pull requests. So if you went further with this, you can set up the integration that allows it to be an official test in PRS and also that allows it to post scan results back to the pr messages or to PR comments. We're not going to do that today. We're just going to do the code ql integration. So hit install. and I'll use. my password okay, and once you've installed it takes a little bit for it to sync up but then this is what you should see. You can manage the connection and that will allow you to open up the aperture on what other repos you want it to be installed to. Now that you've got that connection set up you can add a connected Repository. And so what we'll do is connect. The GitHub repo volnote Express to our volnote Express repo on this side. Hopefully I've picked the right one because I created two that were the same name. All right. We'll see how this goes, but you should see a similar thing. So hook up your repo to your app on on the stack oxide and hit finish. And now to see this in action, we have to run another scan. So what you can do is just go to your latest build and test run and hit rerun all jobs from GitHub. so under actions go to your building test jobs. Hit rerun all jobs. Kick that scan off. So we'll have to wait for a couple more minutes. while we're waiting one person on a chat said they're often working Oh forget Hub when it asks you to use Authenticator. It seems like yes, feel free to drop more clarification in the Discord if you have a more specific issue. Yeah, what it's referring to in that case is it you must have MFA set up or multi-factor authentication setup for GitHub? And usually it will give you a couple of different options. You might be able to use your GitHub password again, if you if you walk through that flow one more time. but the authenticator on on my phone I use the last pass Authenticator. A really popular one is Google Authenticator, but it's that one time token thing and it's looking for it wants you to go through. Hopefully you've said that up on your phone or something and you select your GitHub account and it should give you a six digit code or something that you can pop in there. They have another integration if you have the GitHub app. On your phone then another option for MFA is to go into your GitHub app and read in the code. That they'll give you a little code that you can type in from the web interface as well. Oh somebody missed how I restart the build and Test action. Let me let me back up and show that one more time. So from the actions tab. Go to the build and test workflow. and select your latest workflow. Let's say it was this one if you if it's all green check marks. Actually, I want if you can do it from here. No. Yeah, just click it on your latest workflow and just say rerun all jobs. cool Okay, let me see. So my building test job is still running. And now it's complete. So let me see if that worked for me. So go back to your scan results, excuse me. And if it worked your latest scan results should have a new GitHub icon under the sast column. And when you click in any findings that it found sased correlations with should also have that GitHub icon. And then when you click in on those results. Then there should be a new tab called GitHub codeql. Click on that and it'll show you. Hey this vulnerability that I found on this side the SQL injection attack. Has a correlated. bit of evidence from GitHub code ql and what they found was that in that you've got a vulnerability or a vulnerable code pattern in your search.js file. And you can click out to this to look at it directly. So now we've we've clicked out to the GitHub code repo and it's pointed out this line and and that's where we need to look. Better view is available if you hit view code ql details. So if you hit this button. from the evidence pane GitHub codeql tab view code ql results then You get this full data about hey look in the search.js file. I found this line where you're trying to put together this query yada yada gives you the full rundown of what what the vulnerable code pattern is. So now To put it all together. You've got a nice little summary of the SQL injection problem the input/output evidence that you can use to recreate the attack. And GitHub coach UL evidence to show you exactly where in the code base to look for that problem and start fixing it. And just one more time just to walk through this integration one last time. In order to set up this integration when you come into first you go to the the Integrations section of the application. You pop this out. It's a little more clear the Integrations section of the application. Go to GitHub. And then there will be an enable button here if you haven't set up the integration yet. Walk through that on the GitHub side. It's going to ask you what repos you want to connect it to just select the whole note Express. repo and then you'll need to add here, you know GitHub repo side and the stack Hawk side. of the connection and then to see the correlated results you will have to run another stackhawk scan so you can go back to your workflows go to actions. Find your code or your build and test workflow. Click into the latest one. and hit rerun jobs and that'll kick off the whole workflow again. It'll run Hawk scan again. And now as it send it sends in results. It's gonna be looking for those correlated results from sast. I'm gonna go check Discord myself, see what other questions we've got. All right. It looks like folks have really followed along great job everybody got um, you know progressively harder as we went through the workshop, so Really impressive that everybody is has hung with us all the way through and of course if there's if you if you didn't manage to follow us all the way through I encourage you to after the workshop go go back to the workshop details here and just pick up where you might have left off here. There's some other things in here that we didn't cover but we also got you know, a couple links to other things that you can check out about stock Hawk as well as actions code ql and dependabot so you can do further reading but hopefully this has been really helpful for people to sort of understand how easy and helpful. It really can be to set up this sort of build Automation and the first place and to add a bunch of security tests to it. They can really help you write cleaner more secure code just on an ongoing basis. It's really great to find these vulnerabilities as you're coding rather than having to wait until the end of the month or the end of a quarter or the end of a year. When you get a penetration test and you get these results that are really disconnected from your workflow as as a developer and these tools really help you. Bring them into the workflow bring them into your everyday workflow. It's just adds another one of those tests that gives you feedback right away if you've if you've introduced any problems into your code. So next steps from here at least on the stackhawk side. We've got a bunch of content over at docs.stackcock.com. You can read more about the scanner more about more deeply configuring the application. We've got docs on how to integrate into other ci/cd platforms. If you don't use GitHub actions use Jenkins or Circle CI, I've got great content over there about how to do that. There's really got a nice blog too stackhawk.com We've got a ton of great articles just in general about testing sort of about walkthroughs tips and tricks just more details on how to write some good secure code on an ongoing basis. Thank you so much. Really appreciate your time today, really appreciate everybody hanging with us and I hope you guys got something valuable out of this Workshop.
