Resource Center > Webinars
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 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.