Integrating Security Into Unit Testing for JavaScript

Speaker 1: And so Hi everybody. Welcome to integrating security into unit testing for JavaScript. The workshop. My name is Akira Brand. This is my colleague Bar Hofesh. We are going to be your guides today as we work through this workshop. And yeah, we’re just really excited for you to be here. All right, let’s get started. So what are we going to cover today? First off, we’re going to talk about an introduction to application security. That will take a few minutes. We’re going to go over what unit security testing is. We’ll tell you a little bit about Bright, our company. We’ll do the workshop itself. And at the very end, if we have time, we will take questions. And we can also take a little time and just talk a little bit about some more cool features. If you all want to see a little bit more of the product. It just kind of depends on how much time we have. So yeah, what I what I also want to say really quickly is that unit security testing is totally new to the market. We are the only people that do it and we are super, super excited to teach it to you today. And yeah, so I think it’s really cool that you all are here because this is like a first look into how this stuff actually works. So really hyped. My name is Akira. I have awesome dreadlocks. I like to show those off in every picture I have. I’m a software developer and an educator. I’ve been a professional in tech for four years. I’ve been coding for six ish. I started teaching myself through doing Code Academy way back in the day, and then I went to a boot camp and now I just like to dabble in so many different technologies. I personally prefer a little bit of the back end. I’m learning Node right now, which is a lot of fun, but front end is also super cool. I know React, I’m getting into view a little bit and I have to say I like you an Angular better than React. But again, we’re not going to start too many flame wars today. All right. And that’s it. Neat. Let’s move on. Okay. So we’re going to talk about abstract, and I’m going to get on my little soapbox. I don’t have a real soapbox, but you just have to imagine I’m going to stand up and teach you all a little bit about OPSEC right now. This is a topic I’m super passionate about. It’s why I work here, right? I think that developing secure software is just as important for for developers as writing clean code, as writing dry code. And I’m super excited just to impart this knowledge that I have. So what is application security? So application security is actually a huge term. It’s an umbrella term that is used to describe anything that has to do with writing and shipping secure software. So there are some activities that could be considered apps, so that could be pen testing, hiring a pen tester to come and check out your code maybe once a year. It could be secure code review with your colleagues. It could be internal training. Some companies even do something called an App SEQ Champions Program, in which there’s a few people on the dev team that are focused on application security and they kind of elevate the team around them with training and knowledge that they learn. Typically, App Stack is done by a third party once a year, so that means that it’s been owned by a security team or owned by pen testers. Now that is not a lot of time. That’s not very often that’s not a lot of iterations to get some OPSEC excuse me to get some some eyes on your security. So what the industry has been doing is it’s actually been shifting left, which means essentially putting apps back toward the beginning of the software development lifecycle as opposed to later on. So that said, you have to own it as a developer. Now, it’s no longer necessarily up to a security team, it’s no longer necessarily up to a pen tester. The power is being put more in the hands of the developers and the tools aren’t necessarily always developer friendly, which is why companies like US, companies like Bright exist so that we can help you write secure code early on in the process in a way that makes sense to you as a software developer. So why is that important? Well, think of it this way. How many builds is your team doing a day? In the olden days, you might do one. Build a day, you might do a few builds a week. But now you could be doing multiple builds a day. So on that note, you could be shipping code into production faster than you ever have before, but at the same time you’re shipping security bugs at the same time as as you are shipping production code. So it’s a big rush. It’s very fast. And oftentimes security can take a back seat, which is not which is not the best. If you rely on only periodic pen tests like a like every six months or every year to have a professional pen tester come in, you need to start context switching like crazy once they find the issues. So a pen tester might say, Hey, I found these really big problems in your code and you will say, Oh well, shoot, that was a year ago. And I don’t remember what I did. I know personally when I look at code I wrote six months ago or even three months ago, it’s kind of hard to remember what I was thinking unless I comment the ever loving heck out of it. And even then, it can be it can be difficult. So if you do early detection, you can have an easier fix, not as much tech debt. And then, of course, you are happier as a developer. What I will say too, is that you are ground zero. So malicious actors are going to look at the code. You write first and foremost to get into these to get into these applications. Software developers are often targeted. They are often again, they’re ground zero, and there’s serious consequences for having security vulnerabilities. So, for example, say you’re writing code or like either software or firmware for someone’s heart monitor and a malicious actor or a hacker gets into that code. Well, they could turn off the heart monitor and people can die. It’s the same with things like airplanes, same with things like hospital information, same with things like voting machines. We have a lot of problems with that. So it’s very, very important that developers are empowered with ways to write secure code that don’t rely on pen testing and don’t rely on context switching six months to a year later. So on that note, what did we do about that? Well, we saw this as a huge issue, and we came up with something called unit security testing. And I want to talk a little about a little bit about what that is. So in the olden days, I say the olden days, like a week ago, what would normally happen is you would have all these different tools, you would have sass tools, rasp tools, dast, Iast, etc., etc.. As you can see here in this graph, a lot of these happen very late in the production and development lifecycle. The earliest tool is a sast tool here on the far left. But the problem with SAS tools is they have a lot of false positives and they’re not necessarily reliable. So we said is we need to make a way for developers to use unit tests which they already use in the first place early on in the cycle. So right here we’ve built a unit testing framework. So right as you’re coding and you’re changing your code and you’re committing your code right as you’re on the ground, Ground Zero writing code from scratch, we are making it possible to unit test that code using our engine for security vulnerabilities. Like I said, no one is doing this. I’m super hyped about this because first off, I love testing. If I write code from scratch, I really like to use TDD. So that’s test driven development. Big fan of that and the fact that we can now use technology and a mindset that we already are familiar with in unit testing is like a really big deal. So we’re really excited about this. For what it’s worth to just really briefly, in the olden days, again, the olden days like a week ago over here in production and over here in the C pipeline was really the times where you could start checking for a lot of these security vulnerabilities. But with unit testing, you can check for all of these very early on, which is super sweet. Okay. Let’s talk a little bit about Bright, what we do as a company, who we are. And then after this, we’re going to jump into our workshop. So we’re making pretty good time right now. So here’s what we do. We do something called DAST. It is a dynamic application security testing tool. What that essentially means is we look at your code while it’s running and we interact with your code while it’s running in a similar way that a user would or a malicious actor would. So the first line of defense against the malicious actor can be, Hey, when the code is actually running, is there something goofy going on that that a malicious actor? Or can exploits. This is in contrast to tools like a sast tool, like a sonar cube or something along those lines. And what a SAS tool does is it looks at your code before it is running. It stands for a static analysis tool, so it looks at the code just by itself. It’s not running. It’s just it’s just there in your text editor. It’s kind of like a linear almost. For what it’s worth, there’s lots of what are called false positives with sast tools. What that means is that you will have security vulnerabilities, but they’re not necessarily true. They’re not necessarily there. It’s just the tool saying, okay, best guess, we think this is here. As a result, developers can waste a ton of time looking around for these false positives that aren’t actually there. Something that we pride ourselves on is a DAS tool is that we will not give you any false positives, which is pretty sweet. The last tool I want to mention that we are not because sometimes the best way to learn about something is to learn what it isn’t is called software composition analysis. This is something like sneak or jfrog. What essentially this looks at is all of the dependencies, dependencies that are being used in your code for JavaScript developers. This is especially important since you have so many so so many dependencies. How I like to say it is that see this huge circle with a little dot in it. So the huge circle is all of the dependencies that your code depends on. And then this little dot is your actual code. So as the tool will analyze everything that your code depends on for security vulnerabilities, let’s talk a little bit about why Bright is built for developers. So first off, we can do all kinds of scans. We can scan web apps, internal apps, APIs, microservices, and we also have an authentication ability so that we can scan not only the authentic, the unauthenticated section of a web app, but the authenticated section as well. It’s super easy to use all of the usage of our tool can be done in the CLI or in the in the command line, which is great because you don’t have to contact switch, you don’t have to use the UI, you don’t have to go back and forth, which is fantastic. And like I said too, there’s no false positives. So you can actually trust what we’re telling you is a problem and you’re not going to waste your time fixing stuff that isn’t there. You can also adjust the scope of your scan. This is under the speed section so that you don’t have to do an entire scan on an entire website every single time. You can actually say, This is what I want to scan and we can do that. One thing that I also like to brag about a little bit is that our tool is relatively fast compared to, of course, manual pen testing as well as other tools. I can’t necessarily be like, Oh, I’m going to promise you that it’s only going to take X amount of time. But everything we do here at Bright is to try to get this faster and faster and faster. So, for example, say that you would have a scan for a website that would take, let’s say, 2 hours with our unit security testing, you can run unit security tests in a matter of 1 to 3 minutes, which is really fantastic, sometimes 5 minutes, but still it’s a matter of minutes as opposed to a matter of hours. So we’re super, super proud of that. I think that’s really cool. Yeah. And then of course, we have ability to test so many different vulnerabilities SQL injection, cross-site scripting. We can actually test business logic to see if your logic itself is going to open doors to vulnerabilities, which is super fantastic and much, much more. So that’s about right. I could talk about this all day, but that’s not why we’re here. We are here to do workshops, so we’re going to start the workshop. Okay, so let’s see here. Oh, sorry, I forgot one quick note. We changed our name. So what you might see as we do this workshop is you might see some branded things that say No religion. That used to be our old name. We just changed it. And we’re working on getting all of our marketing and all of our GitHub labs and all that migrated over to Bright. It’s just taking a little while because it’s a huge task. Go figure. So if you see new Allegiant, that’s why it’s not some other company. It’s us in the chat. What sort of security testing do you use? And because I’m a pretty positive person, I like to keep it. I like to keep the vibes good around here. Oh, what do you like about it again? I don’t want to necessarily go into like, what do you hate about it? This isn’t a flame war. We already had that earlier. But what do you what do you like about your security testing tool? Let’s take a couple of seconds. All right? None. That’s okay. That that happens a lot, actually. Sonar, cube, nothing at the moment. That makes perfect sense. Sonar cube cubes, pretty popular. Right on white sauce. Not heard of white sauce. Dependable. Oh, Alex is a new Dev. Awesome. So you’re looking for. For good habits. I’m so glad you’re here. Then you can learn how to do it, like, right up front. And that looks really impressive on a resume. By the way, if you’re looking for your first job and you can write secure code, boom. That’s pretty sweet. All right. Oh, awesome. Zap. Yeah. Nice. Nice. This Alpha uses his senses or her senses. That’s awesome. Yep. Feels it. Okay. Chai and mocha. Yeah. Right on. Ken is a new dev, too. Right on. Welcome, Ken. We love. We love the newbies. That’s awesome. Let the fire rage and try to put out the the fires for all burns to the ground. Yeah, I can, I can resonate with that. That makes that makes good sense. Okay cool. So we got a lot of different we got a lot of different range here. We have ranged from nothing to using in-built libraries like just or milk or chai and then using third party sources like zap and whatnot. So this is what I want to say before we jump into the workshop. This is the very last thing, because you all came and were so grateful that you came. We’re actually going to give you unlimited scan hours for three months. I will show you how to sign up for that during the workshop itself. Normally our free plan, you get five scan hours a month. So now we’re just giving you unlimited. For what it’s worth, you do need to sign up for this offer before the end of the week. Otherwise, at that point, it’s going to it’s going to go away. But I’ll show you how to sign up for that today, if that’s something you want to do. So, yeah, we are we are super excited to offer that. I think it’ll let a lot of devs just play around with a tool a little bit more without without stressing out about losing hours. So here we go. Now it’s time for the workshop. Whoo! Okay, so I’m going to ask you all to please go to right sick dot com. First thing we’re going to do here is sign up for a bright account. I’m going to also put this in the chat. Okay, So once you are here at Bright Security, you’re going to go to sign up right here. Fantastic. Whoops. I need to log out. Okay, So you can sign up with GitHub, you can sign in with Google or you can use your email. What I’m going to do, this is actually super cool. I didn’t know that Google had this trick, but I’m going to teach you this trick now because I’ve already signed up for Bright with my own email like several times. A way to trick Google into thinking you have a new email address is to do something like this. You type whatever your email is plus and then a number. I think at this point I’m at number seven, so and then you just complete the rest of your email and Google will actually recognize this as a new email, which is so sweet. So we’re going to go ahead and sign up that way. Sign in. Oops. Oh, I’m very silly. I accidentally did the wrong side. Akira brand is my name here. It got Brand plus seven at right Seccom. If you want to be really silly, you can sign up I guess with this email, but that won’t help you at all. So use your own email or use your github whatever you want to do, create a free account. Okay, I’m going to go to my email on a different page here. And verify it. That way you don’t see all of my random email stuff. Okay. All right. So now we’re going to go to sign in Akira Brand plus seven. Lucky number seven at right sick dot com. We’re going to sign in here and click sign it. Wonderful. First thing you need to do is you need to create an organization name. Mine is going to be awesome. Jazz workshop. Y’all are great. It’s a super long organization name, but I think that’s a truly what’s in my heart. All right. Let’s go ahead and push create. So right here is where normally you would go through what’s called a setup wizard. This would download our CLI and it would also download something called a repeater. What a repeater does and bar. Please extrapolate if you want to as well. What a repeater does essentially is it allows scans to come from your IP address of your local machine and interact with our engine. But because the repeater is part of the demo project that we’re going to use today, we’re going to go ahead and skip this. So down here, I know we already signed in, but we’re just going to click on sign in. Whoops, That’s not right. Let’s go back. Okay. Yeah. Okay. Yeah. We are going to go to sign in. Sorry. There is a little bit of goofiness right here on our on our UI. But look, we’re a software company. There’s goofy stuff sometimes. All right. So the first thing you need to do is get an API key. So what are you going to do on the top right here? See this little person that’s shaded in? You’re going to click on this little person. And you’re going to click on user settings. Fantastic. And scroll down. Scroll down right here. Click on Create API Key. All righty. So what’s my name? My name is Akira. And we’ll just say Akira is API key because we’re a security company and we care a lot about security. We’re just going to select all the scopes. Of course you would. Don’t have to select all the scopes every time you do an API key, but for this purpose, we’re just going to do that because it’s easiest. Now, right here, you’re going to push create. Now this is very, very important. And if you can also please echo this in the chat, because I want to make sure people realize this. We need to copy this API key and keep it somewhere safe. The reason is once you close this window, you absolutely cannot see your API key again. You will only see the prefix. So I’m going to go over here on my machine where you can’t see it and copy my API key. We do need this later, so please at this time take some time and copy this to a secure location. For what it’s worth, you can also use the GitHub repository secret feature. This is a good way to to store API keys. It’s sort of best practice. We won’t go over that today because we don’t have enough time unfortunately. But if you do use your GitHub repository secrets feature to store the key, you can do that via GitHub. All right. Okay. See where my mouse. Okay. Here we go. We’re going to close it. For what it’s worth to after this workshop, I’m going to blow away this API key so you won’t be able to to use mine. So if you don’t make your own and you’re following along and you’re trying to use mine, your project won’t work after about 2 hours from now. So just FYI. All right. So keep in mind, guys and males and females and everyone in between, which I am myself, if you are trying to go through the setup wizard, you don’t need to go through the setup wizard right now. Just go ahead and log in and get your API key. You don’t need to do the setup wizard because this demo project that we’re about to set up in about a second comes with a repeater. So don’t stress about that. Okay, Now I want everyone to please go to this GitHub repo. It is GitHub.com slash neural legion. Again, as I said, we are still changing our name slash spec tester dash js dash demo. Okay. This is our demo project that we’re going to use. First things first, you’re going to want to fork this project to your GitHub profile. So go up here to the right. What essentially this does is it makes a complete copy of the repo onto your GitHub profile. And the cool thing about it too is that it’s not like an old copy that doesn’t update it automatically updates when we push things to to our repo, but this is so that you can clone it down and make changes and push it up without actually trying to change our stuff. So if you don’t know what a fork is, that’s that’s what it does. So we’re going to click on fork, make sure it’s going into the correct owner. I myself am the owner of several different. Profiles. So make sure it’s going to the right one and do create fork. Wilfred. Oh, yes. You can also download that bits, whatever you want to do. Just make sure that somehow the code gets on to your local machine. So now we can see minus four to my profile, which is fantastic. We’re going to go here to code. And I personally like to use get clone with HTTPS, so I’m going to copy this, this little URL here. Again, like I said to Alfredo, any way that you want or that you like to do to get the code onto your local machine, go ahead and do that. Some people use SSH. Some people do use, of course, a zip file. And so then now I’m going to do a new share of my screen because we’re going to go to the terminal. So let’s do desktop one. Fantastic. Can everyone see my terminal? Maybe just give me a quick thumbs up? If you can. Yep. Okay. Sweet. All right, let’s do get clone, and then I’m going to paste this. Bam! All right, Fantastic. Just do a quick LZ to make sure it worked. Yep. There it is. Tester Just demo. And now let’s go into that project. So CD set tester US demo. Fantastic. Now, where it starts to get pretty cool here, we’re going to download a bunch of dependencies and get our Docker up and running. Hopefully you have Docker if you don’t go get that right now. We can also take a little bit of time to download Docker. We will need that for sure. Okay, you are in the local version of the product of the of the project in your command line. You are going to run this command node, PM space CI and PM space ci. This is just going to download some dependencies. Yes, you can use the US code. That’s totally fine, Barr. You want to talk about any cool dependencies at all?

Speaker 2: Yeah, we can. I guess that’s the only very interesting here. Dependency that you might not know is our hard verifier. That’s just verifies our files. Don’t worry about all of those very, very frightening vulnerabilities. That’s the whole point. Yeah, that’s the whole point. We are showing a vulnerable application. So we are showing actually how to find vulnerabilities in our application. So. That’s part of it. Installing risky, risky dependencies in the in the demo. Obviously, if that would be a real project, we wouldn’t want to do that.

Speaker 1: Yeah, exactly. Yeah. For what it’s worth, the first time I downloaded this, I was like, Whoa, I don’t know that I can show a project about cybersecurity with high severity vulnerabilities and then borrowers gracious enough to explain that. No, that’s part of the project. That’s like the point. So that’s great. I felt very silly, but that’s all right. All right. The next thing we’re going to do is we need to set up our dot and file. We have a template that you can use. The way to use this template is to I’m going to put this in the chat. Use the command of copy dot in v dot example space, dot and B. So what this does is it takes the inv example template that we made and just puts it into your EMB file. Okay, so now comes my favorite part, which is when we actually open up the text editor and start writing some code. So let’s go ahead and do that. So I’m going to use Visual Studio Code and I’m going to just open up here all the code on that. There is sometimes a really strange bug in Visual Studio code where the Shell command code does not get opened up properly. So what I’m going to do now is I’m just going to go here and just open it manually. So let’s do this. So in our dot env v file right here, you can see with that last command we went ahead and took our previous example file and dot dot example. We took that template and just put it in our env file. Now the moment of truth, did you save your API token? I hope you did because it’s going to go here on right token equals on line four. So I’m going to go to where my API token is over here because it’s very, very secret so you can’t see it and paste it right there. Okay. And go ahead and save that. All right. So now we have our API keys all set up. No. Next thing that we’re going to do is we are going to boot up Docker. So first off, I’m going to actually open Docker, make sure it’s open. All right. Looks like my little, little whale is showing up, so that’s fantastic. We’re in good shape. If you do not have Docker, you need to go get it really quick, because otherwise this won’t work. And then we are going to use this command, which is. Loops in your terminal. I will go ahead and place it here. Dr. Campos F Dr. Campos Gammel Up RD. All right. We’re going to connect to Docker now. If you are having. Problems. Um. Please put them in the chat. And R and I and Barr will help you. So I just want to make sure that. Let me just check the chat really quick and make sure we’re all good. Ken wants to know, how do I get Docker? That’s a great question, Ken. I believe it’s just Docker dot com. Yep. Go to Docker Dotcom and install the correct version for whatever machine you are on. Okay, Sounds good. Iker I hope I’m saying your name correctly. That’s a super cool name. It looks like you fell behind. That’s totally okay. Art, can you maybe help them? That would be really cool if they need a little extra help. Sebastian wants to know, are these commands and the read me of the repo? Yes, they are. Let me go ahead and link to the repo one more time so that you can see these commands. Here you go. Shamar wants to know where do I put the API key? That’s a great question. So you’re going to open up the entire project. You’re going to go to your dot in V file. What you should see is this previously copied over template and your API key goes right here on line four where it says bright token equals. If you do not see that template. Okay. Got it. All right. So if you don’t see that template, what you need to do is run this command. Let me see. Where’d my command go? Here it is where you are going to copy the template into your env file. Um. Yep. Hari If it says contact connect permission denied. Use pseudo. So what pseudo means is it means, Hey, I am the admin. Do this. I don’t care what you think. Do it. Okay, cool. Let’s go on. The last thing we need to do to get this project running is npm run migration up. I’m going to put this in the chat and then we will run it together. All right. So what this does essentially is it starts a database migration. We’re using post graphs. Fantastic. We successfully migrated to the latest version. That’s what we like to see. Okay, This is the moment of truth we’re going to do npm start. What that does is it’s actually going to start our application and we’re going to see if it works and PM start. Oh, I feel good about it. Successfully started. Application is running. Okay. If you. See this. You’re in good shape. If you do not see this, please say so in the chat. It looks like Abner is having some issues with the syntax error.

Speaker 2: I think let’s give people a bit of time to catch up. Yay!

Speaker 1: That’s cool. Yeah. Let’s take a little more time. Mm hmm. Maybe that’s.

Speaker 2: A good opportunity to explain why.

Speaker 1: We don’t have to install the CLI.

Speaker 2: Yeah, Yeah, that’s a good point. So basically in high level, the repeater allows us to scan and access local servers. So let’s say you have some kind of an example small server that you are developing locally. This is like the one in this example. We use the repeater like some kind of a proxy to send requests to this local entity. The repeater is a standalone is a standalone program or is the CLI is usually used in the CI process or just in enterprise environments where people want to test local staging and environment, which doesn’t have access from the outside world. But for this demo in the Sector Sturgis Library, the repeater logic is already bundled in, so there is no need to install the the exploit CLI because it’s already bundled all of this logic into the Secretary’s library. So this is why we don’t need it for this demo.

Speaker 1: Totally. Yeah. Okay. All right. Seems like some people we have. It’s working. It’s working. If it is working, please also feel free to say that it is working so I can get a kind of sense of how many. How many problems we’re having, as opposed to how much it’s actually working for people. Working, working, working. Awesome. Good. Working, working. Avner is still having an interesting syntax error. Let’s take a look at that. Working. Working. Still in Docker. Okay, no problem. No rush. Working. Cool. Roll test does not exist. Interesting. I haven’t seen that one. Scott, I’m going to just copy yours. Bar Can we take a look at this error? Error rule test does not exist. Not sure what that one is. Okay, let’s see here.

Speaker 2: That’s a good question. When you generated a pick. Well, first of all, where are you seeing this error from when you run and beam migration up? Give me a second.

Speaker 1: Okay. We’ll take a look here. Now we use post grass. Okay.

Speaker 2: And that’s because. So this is because Vera, you don’t have Docker installed teams. The term Docker is not recognised. The name of a command line interface. Yeah. You need to install Docker and I’m still testing this.

Speaker 1: Roll test. Fantastic. Okay. All right. Oh, good. Art, just put also a clear version of how to install Dockers. That’s fantastic. Okay. Ahmed Awesome. Can we talk a little bit about. Why we use Docker. Barb, can you talk about that a little bit?

Speaker 2: Sure. So we’re using Docker is just an easy way to set up our test application. We have an application that we’re running and we’re going to test against. So this is, this is basically the reason we’re using Docker, not nothing else. It’s just our just our application so that we will have something that actually answers.

Speaker 1: Fantastic. Okay, cool. All right. I do want to go on. Art is going to be on hand to answer more questions in the chat. Thank you, everybody, for participating. So. Well, this is really cool. So we have our application running, and we’re just going to double check that it’s actually working by opening up a new browser window and going to local host 3000 slash API. Oh, it works fantastic. If you are seeing that in your browser, please. Just right. It works. It works so that I know who it’s working for. Okay, so what is this? Well, this is really cool. This is something called swagger and this is a UI that allows you to visualize API endpoints in a way that just makes sense to our to our visual brain. So, for example, this also will allow you to test our little CRUD API here. What I want to do is we’re going to go over here to post slash users and let’s see if it actually works. So we can see here is that the first and last name are the values and then excuse me, are the keys and then the values are just strings. So we can actually try it out. We can make a new first name, last name. So go ahead and click right here. Try it out. Super sweet. The first name is going to be. Let’s go ahead and just type whatever you want to type there. You can be your actual name. It can be blobs and warps. Doesn’t matter as long as it’s a string. We’re all good. Now let’s push execute. Okay. So what you can see here is the curl command that we use to the end point. And right here you can see the response body. So it actually did just add a new user Acura brand with an ID of 35, which is super cool. I love swagger. It’s such a cool way to interact with your APIs. So we have in fact actually been able to get our application up and running. It is working super awesome. Now let’s go to the Good Stuff. Let’s run some tests. So this demo project comes with some pre written tests and to run those tests you are going to go to your terminal. So go back here, open a new terminal window. Don’t try to do it on this window because this one is running our application. So open a new terminal window. And you are going to run and PM SpaceX run SpaceX test Colon seq. Okay. This is going to take a few moments to run, but while it’s running, I’m going to turn it over to Barr. And we’re actually going to go into the test itself and talk about what it is, how it’s set up and what it’s testing for. So, Barr, I’m going to let you drive and take it away.

Speaker 2: No, sorry. I was answering questions.

Speaker 1: No problem. No, no. And bar. So. Bar. While the tests are running, can you please go over?

Speaker 2: Go. Yeah. So we can actually go over the tests themselves and talk a bit about what we’re testing. So. Akira, if you can open the. The test file.

Speaker 1: Yeah, absolutely. I believe it’s. Which one is it again? This one? Yep.

Speaker 2: You are allowed to explore. All right. So we have a few tests here, basically two for the demo. One is one of them tests for X or cross site scripting. The other one tests for SQL or SQL injection. The exercise tests against a post request that sits in slash users forward slash users. It has two parameters that it’s going to test. One is first name, the other is last name. As you can see on line 66. The SQL injection test is going to run against a get based method in the against the URL, which has a rest based interface, basically user slash one. So we’re going to test that. A few things that I can say is that X specifically checks for sanitation issues, mostly client side sanitation issues. If you can inject anything as a parameter that will reflect back to you as the user that can execute JavaScript, change domain elements, change the behavior of the front, and basically can fall under access or HTML injection. SQL injection is a way for us for the attacker basically to try and manipulate the database by breaking queries and adding their own malicious commands. So think about a situation where you want to query after a user. You want to get all of the users that have bar in their first name. So you have this parameter or all their IDs is one. By using a malicious payload, basically modifying the request, an attacker can technically just change the query if that if it’s wrongly written or without sanitation. So that’s what we’re testing here. That’s what we’re aiming to find. Let’s hope we don’t find any of that. But we are going to find it. But let’s hope we want. But that’s basically what we’re testing here. If you have a questions about those tests, if you have a questions about other security tests, now is the time to ask them while our tests are running in the background.

Speaker 1: Thanks, Bar. That’s super awesome. Can you also talk a little bit about, like, why bother writing tests at a unit test level in general?

Speaker 2: Well, we all know that the best code is code that no one tested because then there are zero bugs. The problem is that when we push to production and someone actually uses that, we suddenly we suddenly get bugs. Security issues are just bugs. In the end, it’s just bugs. And as developers, we can have a lot of kind of bugs. Some of those bugs are functionality bugs, UI bugs, performance bugs and some are security bugs. The point of shifting left in general and trying to put security testing as early as possible has two main things. One ROI, which is more of a business business aspect. Basically the late the more time passes between the code, leaves our hands and goes to the other stages of deployment, development, QA, etc. The company is wasting money because more people took time to validate more services, has run, more computation has been done and to fix a bug which has already gone out to production costs much more than to just delete one function and rewrite it when it’s still in your hands. So this is one aspect. The second aspect is that we as developers actually know exactly what’s going on in our application, and this is knowledge that doesn’t 100% go through the chain. So for example, if we know that one method or one code behaves in a certain way, we know best how to test it. Usually we know what we expect, we know what the application should do. Obviously QA as well. But the application security testers, the penetration testers, the everyone later in the chain, they lack a lot of knowledge and access to the core of the system that we wrote. So yeah, that’s also a good reason to use unit testing security because basically we know what to test and we know how to test it well.

Speaker 1: Awesome. One other thing that I want to mention that I saw in the chat as a question is I want to go over really quickly these lines, 56 to 62. So if you recall at the beginning of this presentation, I talked about how in our tool you can actually make like the attack surface smaller or you can specify things that you want to test so that the test itself runs faster. So that’s essentially what this is doing. It’s like, for example, on line 61, we’re saying, okay, we want to make sure that we’re only testing for things that have a severity threshold of medium or above. We’re going to time out the test if it runs for way, way, way too long. And then 63 and below is just where we’re actually running the test and what method we’re using and what endpoint we’re testing on. So this is not actually necessary. You don’t have to have line 61, you don’t have to have line 62, but this allows for a little bit more precision in the test so that the test will run faster. Okay. So on that note, we actually had our test run, which is fantastic. So we had one failed and one pass. We were testing for SQL specifically in this one. So SQL injection. And the cool thing that I want to show you here is that if it finds an issue, it will tell you what kind of will the test name, the severity of the test. And also we will give you some remediation. So essentially like how to fix it. So some suggestions for how to fix it as well as some extra details. Personally, I think that’s pretty cool because as as developers, we’re not necessarily taught how to write secure code. Like I went to a coding bootcamp and it was awesome, but they didn’t really teach us about security. I’ve also like taken a college course for coding and it didn’t teach me about security, so we’re trying to educate. You as a developer on how to deal with this as opposed to just being like, Yeah, we found something. Good luck. Ha ha. So that’s something that I think is really cool as well, and I wanted to just point that out. What I’ll show you in just a second here is that if you do want to see that the test is running and you don’t want to rely necessarily only on your terminal, because sometimes when we run a test, it just kind of says testing, testing, testing. And you can be like, is this actually working? You can actually go into the UI on our tool and see that the test is running. It’s just and what it’s finding and if it’s actually working. So before we do that, we’re actually going to fix this problem because when we test issues, obviously we test them in order to fix them. So let’s go to our actual code file. I will paste it here in the chat. And then, oh, bah. It looks like we’re also getting a lot of questions on like how this actually works while I do this little section here on the code. Can you please talk about how this works? Like we spin up an engine and all that stuff.

Speaker 2: So I’ll try and go through all of that, but. So GitLab integration. Yeah, we do. We have that, I think in our documentation. I guess maybe art or someone can put the link. Any idea why it took so long to run? So let’s talk about that. It took like, I guess like a minute or 2 minutes to run. Something like that is that we are doing a live run of the test. It’s a dust. So it’s dynamic application security testing unlike ACA, like sneak someone asks before, we don’t just check the dependencies and say, Oh, this dependency has known vulnerability. It’s like NPM audit. Here we actually bring up the application, generate requests against it, and then evaluates the responses. It does a real end to end miniature penetration testing, you can call it. That actually gives you real results in real issues that are shown.

Speaker 1: So yeah.

Speaker 2: I guess that’s is the sick test is running in remote server or in a local. So the the main server, the main engine runs in the cloud and the repeater is actually pulling the tests, executing them locally and then responding back to the cloud. It’s like a little proxy. So that’s the flow.

Speaker 1: Okay. So what I just did is because again, when we run a test, we have to essentially spin up a new engine and it can take a few minutes. But again, a few minutes is still better than a few hours or several days, which can totally happen with other tools. So, yes, like we are working on getting the infrastructure a little bit better so that the test itself runs faster. It is, of course, a little bit longer than like a regular test that you’d be used to for just using jest or mocha or chai. However, because these are security tests, when you normally are running security tests, like I said, they can take hours. So we’re down 2 minutes. We want to get an even better. But for now, it’s it’s pretty solid. So what I did while bar was talking is I went here to source users users dot service dot typescript and I fixed quote unquote the issue. Then I ran the test. So now I’m going to talk about what I did to fix it so that we can all see, of course, what’s going on. But the reason I did, the reason I fixed it and then ran the test is that the test would have enough time to actually run while we talk about this. So we’re just going to command Z quite a bit here. All right. And one more commands. Eat. Fantastic. Okay. So let’s talk about why this is wrong or why it’s inaccurate and why it will allow a security vulnerability to exist where we don’t want it to exist and how we can fix it. So like I said, we are testing right now for SQL injection. So SQL injection, which essentially allows people to manipulate a database when they should not be able to manipulate a database. So let’s go here on line 49. What essentially we’re doing here is that we are not doing what’s called sanitization of the data that is that we’re putting in this query. So essentially an attacker can easily use a lack of sanitation from the user inputs to read sensitive data from the database. They can modify the database or they can do admin operations and put in values that shouldn’t be there. The way that this happens essentially is on line 52 excuse me, on line 51, it’s opening a direct connection to the database. And then on line 52, it’s saying, okay, I want you to select all from user wear, ID equals, and then we have the dollar sign and curly brackets. Now, the way that this is written means that anything that goes in here will be executed as code. So anything that goes in will be executed on the database as running code. Now, when I first saw this example, I was like, Oh, wow, like I could have made that mistake. Like, that’s not something that I often think about. Developers make these kinds of mistakes all the time. It’s not because we’re silly and it’s not because we’re dumb. We just don’t know. So that’s that’s obviously a big problem. And then we can we can test for that in our unit test, which is really good because it can actually save us from some serious problems down the road. Because if an attacker is able to interact with your code and manipulate the database, obviously that’s a that’s a big deal. So what I want to do, we’re going to check really quick and see if the tests have finished running. Nope, Still going. That’s by.

Speaker 2: The way. So maybe just to note and sorry, like you already covered it, but just a bit more. So in this example, we actually see string interpolation and this is a very, very, very common mistake, especially when people don’t use ORM as it should be used. The problem is that I’d can be anything and the moment that IDE can be anything and we’re just allowing the the user to specify for us what’s the, what’s the query going to be. Then we’re giving the user and the malicious attacker full access to our database. Yeah, that’s that’s the problem. We’re just giving the users direct access to query our database with whatever they’re going to put in this value.

Speaker 1: Hello. Would you like to. Would you like to? Definitely not. Great. Okay, let’s take let’s go back to the term really quick and see if it is okay. Perfect. So it passed. So how did I make it pass? How did we fix this? There are two ways that we have written here previously that you can see as an example for how to fix it. On lines 40 to 46, this is like a better way. So we have down here, we have bad then we have good dash better. And then up here we have best. So right here, let’s take a look at how this would fix it. This one, instead of saying on line 43, execute select all from user where ID equals and then having string interpolation. What we do is we have this really cool trick where ID equals question mark and then ID in brackets. What this essentially says is I’m going to make you string ify any kind of input here so that when the database reads it, it reads it as a string, not as code to be executed. And that will actually fix the problem, which is super cool. I will prove this to you by showing you in our terminal that in fact the test did pass. So that’s definitely one way to do it. That’s a quick and dirty way to just figure it out and make sure again that we are string defying anything that’s going to in our into our database. So it’s not a command to be executed. It’s a string to be read. So that will that will fix the problem. And you can do this on a lot of different. Let me say it this way. This is like reusable to deal with SQL injection. Then we have up here on line 32 to 35, this is like the best way to do it. So this one actually uses the ORM library and uses a find one method within that library. That is, it’s just var. Can you help me out a little bit?

Speaker 2: So this function has already been, has already been hammered out and created to basically avoid these kind of issues. It has sanitation, it has parameter sorry query parameters like the example below. And the ORM will already ensure that whatever we put in the find one will actually won’t be malicious anymore. Like it can be malicious, but then it’s just a string. It’s not something that can actually break our that can basically break our stuff.

Speaker 1: But what is worth ORM is like a separate library that we used in this example. It’s not something that we wrote, but it’s pretty sweet or it was really powerful. OC.

Speaker 2: So I wanted to maybe answer Harry. So in SQL map, we can specify different techniques we want, and based on that, it can take longer or less time to run. Is there a way to choose similarly a technique or approach? Yeah, but I might say that. Yeah. Or is open source. Sorry. So in regards to more advanced OPSEC usages, what we’re showing here is a very dev centric approach to doing security testing. Our solution as a whole have a lot of use cases and a lot of use usage options. Our UI has more of the common standard application security approach. So you have all of those configurations and you can do a lot of those decisions about which techniques and which parts of the of the request you want to attack and which parameters and what tests you want to use. And if you want Boolean based or blind or etc.. So we have all of that. But on the developer level, that’s not something that we expect developers to basically think about, right? We want to do it as automated as possible. We want to do it as easy and approachable as possible. So basically just this will test for Sky and we will automatically find the best things to look for.

Speaker 1: Yeah. Something else I want to show you all that I mentioned earlier is that if you are running a test and you want to see if it’s actually working, you can go here into your bright UI. So bright, bright dot com and you would log in and you can go here on scans. And as you can see here, this scan right here for this endpoint, the test should not have sky. You can see some more details here. So you can see that it’s running at this point, it’s done because it is finished. But it would have like a a little thing that says running or stopped or if there’s any issues with the test itself, it’ll give you more details there. So that’s just more of a side note. I just think that’s super cool. I want to check the chat a little bit more. If anyone has any more questions about the test themselves or the remediation steps. I also do want to call out that there are a ton of tests that you can write. However, the test patterns essentially match the patterns that we looked at earlier with bar and they’re here in the read me as well. So if you want to test different types of things, so maybe you want to test like open bucket or something else, you just have to change the test name here. And then of course you can change your threshold in your time out and you have to decide where you want to run the test, like what API or what endpoint you want to run that out, but that’s it. You don’t have to do different kinds of crazy things for different types of tests, which is super cool. So it’s very purposeful, it’s very reusable. I’m going to scroll down a little bit more here. These are recommended tests that we we recommend that you use. This is up to you to choose what you want to test for. We are not going to tell you that you should use any one particular test over another. But I would definitely be curious and I will definitely be writing a little bit more about like when should you test for broken jaw authentication? When should you check for cookies, security and things like that. But right now what these are is these are just all of the available tests to you that you can do with unit security testing. So as you can see, this is quite a lot of test options. Last but not least, you also can put this into a PSI, so you can put this into CI integration. We work with Circle CI, we have GitHub actions. We Jenkins quite a lot of CI options are available to you as well to run these unit tests. And we have a little bit more information on that down here on our Read Me. OC. One last thing that I want to mention to you that actually just got asked in the chat that I want to call out is that your code is actually never being uploaded to. Right? So we’re not like pushing your code to our engine in the cloud. We’re actually running our we’re running our cloud engine on your code, but your code is not being sent to us. So if you’re working on proprietary code, totally fine. We’re not going to see it. So you can rest easy on that. OC On that note, we are actually more or less at time. So what I will say to that is thank you again all so much for being here. We are so happy you came. We want to open up the floor a little tiny bit more for questions. If anyone has any last things that they want to go over. So I will keep monitoring the chat as well. There are some resources that I’m just going to display here on the screen. You can join our Discord to get more help, just a much, much faster. You can check out our GitHub. We have awesome docs. We really good. We’ve a really great blog. Check out the blog too for more information on like what should you be testing like and why should you be testing it? And also if you have questions about the workshop in general or anything we covered today, you feel free to email me. You can also reach out to me on Twitter. I’m at the accuracy on Twitter and yeah, it looks like people are enjoying the workshop. It looks like people had a good a good time and they were able to get things to run, which is super encouraging for me. And yes, we will have this recording available. We will send it out to all of you if you want to get one more time. The link to the GitHub for this demo project. Here it is right here. And on that note, I just want to say thank you. Thank you for your time. Thank you so much for your attention. We’ve really, really enjoyed putting this workshop together. We’re so glad you all came. We’re so glad that it worked for so many of you. We’re so glad that we got the opportunity to answer questions when it wasn’t working. We I personally love helping other developers. That’s why I do this job. Many, many, many thanks to Bar for coming in and running support. Thank you so much to Art for also answering all the questions. And again, thank you all so much for being here. We had a great time and we will see you next time. So thanks again for coming, guys. This concludes our workshop and thank you again for for being here.