Resource Center > Webinars
Unit Security testing with SecTester
Speaker 1: Hello, everyone. Hi, everyone. Welcome to this webinar. Hi everyone. Who’s coming in? My name is Akira Mei. I’m here joined by many of us at Brite. We have Nermin, Artem, Tonya, and Art. Thank you everyone so much for coming. So if you want to get slides and follow along here, you can absolutely do that. This is a little tiny URL because the link for Google slides is very long. I promise this is not a virus. We are a security company. That’d be super gnarly if we gave you something. So this is just a link to the slides. You can also take a picture of this if you want later on and take a look at the slides so you don’t get too lost. All right. So here’s what you’re going to need today. You’re going to need a GitHub account. You’re going to need a text editor, which is optional. But we can look through the code a little bit easier on your end if you want to take a look at that. Also, you will need Docker desktop. If you don’t have those things, I suggest going to get them. Right now we’re going to teach you a few concepts. We’re going to do some top down teaching. So until until the actual workshop section starts, you’ll have time to download either a text editor, dock or desktop or get yourself a GitHub account. And yes, this is going to be recorded. Okay, So I like to frame what you’re learning as a win as opposed to like, oh, here’s a thing you’re going to learn. It’s like this is actually a huge win that you’re going to get. So we’re going to have a bunch of wins today. First thing is going to be learning about application security. So that’s a really big win for you in your career. The second one you’re going to get is an intro to unit security testing and what that means for you as a developer. The third win will be about bright, so this will be like a tooling win. You can learn some new tools today. The last part will be, of course, the Tester workshop itself. This will be a hands on wins plural. What I will say is that this tool is an alpha, so we are probably going to encounter a couple of blips and blobs along the way. Please be patient with us. We also really, really want your feedback. If you’re like, Hey, like this section made sense and the section like didn’t really work for me and I want to know why this was the way this was like, Please let us know. We are actively developing this feature and we’re just really happy that you’re here because on the one hand it’s like there’s the Alpha version, which is where it stands, and there’s like what is turning into, which is really exciting. So it’s cool that you all get to come and be here at the very beginning of this process with us. So thank you again and please, please have patience with us as we all work together to make this work out. And then of course, the last section will be questions. I’ll try to answer a couple of them live at the very end, and that will be a win for you as far as participation goes. So even if maybe, for example, you don’t get the entire workshop in your brain, I don’t expect you to. We only have an hour. You can at least get a couple of wins, right? So to that end, I want to know in the chat, what when do you most want to focus on today? What do you really want to get out of this workshop? And I definitely want to hear that in the chat. What do you want to get out of the workshop? What do you want to learn most? About what? When do you really want to walk away from this with? I think that if we can all focus on one or two wins for ourselves, then we’ll come away from the workshop. Super satisfied. Okay, so here’s me. Just a quick note about me. I work in developer relations at Security. I’m a tech educator and a educator in general. I have taught students of all ages and all skill levels about two main things. One is music and one is technology. For over ten years, I’ve probably taught hundreds of students, and I’m super glad to be teaching you today. I’m always looking for feedback too, of how I can be a better educator, but it’s a really big passion of mine. I just really like to. I really like to. I love to teach. What can I say? I love to impart my knowledge and hopefully you’ll come away with some new knowledge. Today. I’m also a perpetual learner. I actually just started my own computer science degree at Hammond College. I’m very excited about it. It’s really rigorous and I’m really enjoying it so far and I’m always learning. I’m always trying new things. A lot of what I am teaching you today is relatively new to me. I’ve had a few months practice on it, but it’s like, you know, I’m always trying to learn new things and I find the best way to learn something is by teaching. So kind of goes hand in hand. All right, So let’s do our first win. I hope you’re all ready to have a first major win. This win is about learning about OPSEC. So what is application security? So application security is an umbrella term that is used to describe anything and everything that has to do with writing and shipping secure software. OPSEC has always historically been owned by the security team or by penetration testers. But nowadays, actually what is going on is that developers are needing to own it. And on that note, what does that mean that developers have to do? Well, one thing is that developers have to now learn how to integrate security tooling into their own pipelines. They have to learn how to integrate security, tooling into their own works, into their own workflows. They have to understand what secure coding even means. That’s really tough, right? Because there’s not a lot of education around this, which is another reason I’m so passionate about, about teaching this subject. It doesn’t really get taught in schools, It doesn’t get taught in colleges. It doesn’t it certainly doesn’t get taught in boot camps. So it’s like all of these apps like activities, things like secure code review, things like threat modeling, things like installing tools like DAS and SAS tools. Those are now in the hands of developers and we don’t really know what good apps EQ is, right? What differentiates good OPSEC from bad OPSEC? In my opinion, good OPSEC is the OPSEC that happens. And when I mean that is that sometimes developers can become so overwhelmed with the security requirements of code and what they have to now do for software security that they will maybe not do anything at all, which is which is a problem. Right. So in my in my opinion, any kind of abstract that you do is good OPSEC. And of course, then you have to make sure that you’re implementing whatever tool you’re using, whatever maybe software design pattern that you’re using correctly. But a good place to start is just to get started. Going to check the chat really quickly, make sure that we’re all in good shape. Yep. Okay, cool. It looks like we have several questions about whether this is being recorded. The answer to that is yes, it is being recorded and we will have that for you afterward. Why is OPSEC important? So in the rush to develop features, fix bugs and maintain software security can and often does take a back seat. So the earlier you detect security issues, the easier it is to fix. And then one of the great parts of this is that you will not have as much tech debt. So again, like we said, whose responsibility is it now? It’s the developers responsibility, not necessarily fully, but a lot more security requirements and security mindsets are being placed now on to developers. And there’s also a big issue between the communication between the development teams and the application security teams that sometimes people don’t really know who is in charge of what. And then of course, breaches can happen and then it cost your company a bunch of money. It looks really bad. And whoever caused the breach and it’s not a fun time. So I’m actually curious, Tanya, if you are here, can you tell us anything else that you want to maybe add about why is apps important?
Speaker 2: Yes. So this is funny because obviously, this is my favorite my favorite topic after. So someone’s asking about E certificates and are we giving those after the workshop? Akira And then I’ll.
Speaker 1: Answer that one.
Speaker 2: Everyone is getting an E certificate after the webinar. So apps X important for a whole bunch of reasons, like all the ones that said. But basically cybercrime has completely exploded because one, it’s really hard to catch people who are performing crimes on the internet. Repudiation is very complicated and so there’s not that much risk. Like when you go and rob a bank and you have a gun, people can shoot you. And quite frankly, death seems scary to me. And it turns out lots of other people feel that way, too. But when you do a cybercrime, you’re not going to get shot while you’re doing it generally. And the other reason is because there’s so much potential for stealing and other types of crime on the Internet because we don’t have extremely secure apps everywhere on the Internet, just some places. Most I want to give happier statistics, but there’s still lots of stuff that’s quite old on the Internet that hasn’t been updated and re secured. There’s still lots of people releasing applications all the time that haven’t even had like just one scan and then like two bug fixes done on them. They just have had zero attempts to ensure they are secure. And so until things get better, criminals will continue to flourish on the Internet. So we are hoping and I, I mean me, Akira, everyone on this call and everyone that works at Brite are hoping that we can ensure that we can provide something that will help you make your apps more secure. Essentially. Like we really this really matters to all of us. Is that good, accurate or is there there’s.
Speaker 1: Also a question that I want to answer that’s been put in the Q&A that I think will be really good maybe for us to weigh in right now. Before we move on to other things, the question is from Zhao, and the question is how do we apply security patterns to software design patterns? So maybe we can talk about that a little bit. So there’s a couple of things that are like best practices that are a good thing to implement. We won’t go into all of them right now because it’s a lot. But the the the organization called OWASP o w ASP has a fantastic list called the OWASP top ten. And that list essentially tells software developers like the top ten security vulnerabilities that we should be guarding against right now. And inside of that OS top ten, there are remediation steps and suggestions for patterns to take in your software for how to guard against these particular issues. Also, there are security courses that you can take. For example, we have one on, we have purple dot com that is all about secure coding and there is some things that would be inside of there that are really important. Like for example, input validation is incredibly important. Output and coding is incredibly important. Doing things like having proper authentication and authorization incredibly important and all of these things tie in again usually to the top ten list. So that’s why I would refer you to is to learn about the top ten, take a look at those resources and dive a little bit deeper in for yourself. And also check out we have purple dot com, which will give you a whole secure coding course so you can learn about as well. All right. Let me see here. We have a couple of we have a bunch of other questions. Let’s keep going, though, because I don’t want to get too terribly stuck, but we will. Eddie, Muhammad and Kumar, I see your questions. We’ll come back to those in a little bit. So maybe after this next section. All right. When number two, learning about unit security testing. So what is unit security testing? So what we’re trying to do here with unit security testing is we are trying to integrate these OPSEC practices with developers as soon as possible. One way we can do that is through a tool called a DAS tool. So a DAS stands for Dynamic Application Security testing. And what a DAS does is it tests your application from the outside in. It’s called also black box testing, which essentially attacks your app the way that an attacker would to see where it can get in and where it can corrupt data and where it can steal files and things of this nature. Normally tools like a Dast are only integrated into the software development lifecycle after integration tests and right before release. What we’re trying to do today and what we’re doing with Spec Tester is we are integrating our DAST engine. So the thing that makes the dast run here at right into end to end security testing. So inside of that intent test, we have security unit tests that we’re going to run a little bit later on. And that way when you’re actually writing your code, you can start writing these security tests, especially like how we talked about earlier, the OS top ten. Maybe there’s a particular vulnerability that your OPSEC team really wants you to guard against at this particular moment in time. You can actually start to test for that as soon as you are writing unit tests, which is actually quite revolutionary. I’m very excited about this because no one else has integrated a DAS tool this early on in the process. So all of this falls under the umbrella of a term called shifting left. And shifting left is sort of a buzzword in the OPSEC industry right now and the InfoSec community in general. What that means is normally, again, all of these a lot of security tools and pen testing and security, anything really was done on almost the far right side of the SDLC. So right before production pre production right after production, and that’s too late. So we’re trying to shift it as left as we possibly can, such that we can find these issues earlier and remediate them earlier. So it makes developers happier because the teams aren’t like dumping a bunch of work on them. It eliminates a lot of tech debt and of course it secures your applications much better so that your businesses don’t have as much of a possibility of getting breached. So that’s what we like to talk about when we say shift left. And here’s right here where the unit testing frameworks are right here on code changing commit. So like I said, in the olden days, which is like a year ago, all the way here on production and scheduled would be where you would test for all of these issues. You’d have cross site scripting, sci fi, SQL injection, C surf. But now you can actually shift all of those left. So now in the C ICD, you can take care of rescue alai injection and sea surf and sea surf. Then even more far left here on unit testing, you can take care of cross-site scripting, OSI and LFI as well. So it’s actually quite exciting. You don’t have to wait until production to dump a bunch of work on the developers from the security team, which is very exciting. OC. Two things that I want to do in learning there are. A couple of theories that actually really help. The first theory that I want to talk about is that when you try to recall something that you just learned, you will have a much greater ability to actually remember that thing. So in the chat, can you please put maybe one or two things that you remember that we just talked about? What did you just learn? What is something that you are taking away from these first two sections? I want to hear. Awesome shift left wonderful. Some may says the process of security then begins early, giving time to have a well secured app on production. Beautiful das to unit test from cell. Perfect. Brian says Das simulates attacks to find vulnerabilities. Awesome. I can almost guarantee you that anything you’re recalling right now, you’re going to absolutely remember beyond just by the end of this webinar, you’ll remember this for a long time. OWASP Top ten Security Vulnerabilities from Herbert Vassilis. It takes a lot to go on prod. Yes. Facts back. So for real. Okay, good. Everyone, thank you so much for for doing that. Okay, let’s go on then to tooling. It looks like Tanya answered a bunch of questions in the chat. So if you asked a question earlier on the Q&A or in the chat, it looks like that our team is keeping up with that quite well. Thank you, Tanya and team. So let’s talk about win number three tooling. So this is the tool that we’re going to use. It’s from our team at Brite Security. And I want to talk a little bit about Brite in general. So you know who we are. So like I said, Brite is a dast. We stand for dynamic Application security testing tool and we test your application from the outside in. And I’m only repeating this because this might be unfamiliar to some of us. So this is again, it’s called black box testing. We don’t actually look at your code, we look at the running application and test it from the outside in the same way that a malicious actor would. Now why is using a test important? Let me tell you. So anyone on the internet, anyone can take a Das tool like right, or other other DAS tools. They can point them at your application and find security vulnerabilities. You don’t have to have given your permission for this now. Excuse me. This doesn’t make that legal. It doesn’t necessarily make it a good idea to do that because you could get caught. But if I can point a tool at your application and find the security vulnerabilities, anyone can point a tool at your application, find the security vulnerability. So it’s a really, really good idea to make sure that you are screening your screening your apps with Das on a regular basis because anyone can do it. It’s not a good idea necessarily to wait for the pen tester to come and say, Oh, by the way, you’ve had these vulnerabilities that anyone could have found with this very simple tool, and you’ve had them for three years. Not a great look. Our our tool is very easy to use. One thing I’ll mention about Bright is that you don’t have to be a security expert to use it. Other DAS tools on the market are very good. They’re solid tools, and if you don’t have a lot of security background, it can be confusing on how to use them. That’s something that I really like about Brite is that I can go in. I didn’t know a lot about security actually, when I started at this company, and it was quite intuitive to understand how this tool works. We can scan web apps, we can scan APIs, we can scan microservices, we can do authentication. We have it’s quite it’s quite fast. So DAS Tools also have kind of a bad rap for being incredibly slow. Ah, our full blown scans can potentially run for a few hours, but other DAS tools will run for days. So that is also quite, quite a quite an improvement. I’m going to move on from this slide, but if you want to take a picture and just learn a little bit more about what all these other things mean, we don’t have time to go into all of them right now. Feel free to take a picture of this slide and you can look at that a little later in your own time. Och, it looks like. In the chat Really quickly, I want to ask you all, what problems does practicing application security solve? So what does practicing OPSEC doing all these security activities, whether it’s learning about secure coding or doing secure code reviews or using a DAS tool, what problems does that solve? What? Things are not an issue anymore because you’re practicing application security. Andrea says public relations nightmares later. Yes, that is so true. I love that answer. If you are breached, your company not only will probably lose a lot of money, they will have a PR nightmare. It is not fun to recover from a data breach. I know Uber just had one recently and it’s going to be really a tough road for them. I feel. I feel quite bad for them. Other ones, of course. Well, there’s there’s there’s so many. But I’m sure you could look up companies with data breaches and you can sort of see the consumer confidence in that company goes down and it’s very expensive to recover from. Let’s read a couple more out late detections of vulnerabilities from Patty. Yes, that’s true. So you can actually detect vulnerabilities early and detect them often. John Oliver says human error. Yes, it’s so true. You can actually get rid of a lot of the issues of human error by practicing application security procedures early on in the software development lifecycle. This is really good. Okay. These are all really good answers. Thank you, everybody. The last one I want to say is, again, reducing costs and keeping a good reputation. Absolutely. Okay. Great job, everyone. Thank you. All right. Now it’s time to go to our workshop. Huzzah! We had so many wins. So what we’re going to do is we’re going to go to this repository, and this will be the repository that we’re going to hack on. So I’m going to put this here in the chat GitHub dot com slash neural region. Slash set tester. Jess demo. And so. You may be wondering. I thought your company was called Bright. Why do you. Why are we going to a place called New Religion? The answer to that is we used to be called neuro legion and we changed our name to Bright. And sometimes when you do a name change, it can take a little while to migrate over all of the things that need to be changed as far as the name goes. And right now our GitHub just is still listed on an early gen. So it is us. It’s not just some random company. This is us. So I’m going to go to this repo and if everyone could please follow along with me, that would be fantastic. And let’s go here.
Speaker 2: May I interrupt for a second? You’re a bit out of focus, Akira. Can you refocus your camera, please?
Speaker 1: Yeah. Like my me personally is out of focus.
Speaker 2: You, the human. Somehow you became kind of blurry. And you look really good when you’re not blurry.
Speaker 1: Oh, thanks. It looks like people can’t copy from the. From the.
Speaker 2: Who know.
Speaker 1: Let’s see here what’s going on here. So people can actually copy from the chat. Let me try one more time. Is that better? Tanya, my list blurry.
Speaker 2: No, you’re still a super blur, but I think you should worry about the link first.
Speaker 1: Yeah, I’m going to close my camera and maybe undo it in a second.
Speaker 2: Okay. There is someone. Someone added it.
Speaker 2: No, you do not need a GitHub enterprise account to access the security settings. Free GitHub accounts should have the security settings as well.
Speaker 1: Yeah. Avner, can you check for Brian to see about resenting him? A verification email. Brian, could you. Would you be willing to put the email you use to register in the chat? And we can check into that for you. If you want. You don’t have to. Okay. It looks like there might have been a little confusion with. The. Okay, I understand, Brian. I understand. Och, let me see here just Unix and Linux OS as you pseudo OC. So if you cannot install feel free to use. I mean it’s up to you but you can use pseudo npm ci which will help. Look, let’s go on. If you are if you’re with us, please put like, please type like I’m here, like I’m good or okay or something like that so that I know we can move on. Otherwise we will kind of hang back for a second. Okay, We’ve got a couple. I’m goods. I’m here. Okay, So. Yeah. Okay, cool. Cool. All right. Okay, let’s give it a little time. I’ll get here. Open up the project. Cool. Cool. All right. So next thing we’re going to do. What you can do is if you have done the thing I recommended with putting your bright token in the GitHub secrets, then this next section is not for you. But if you did not do that, we’re going to put the right token directly into your repo. This isn’t the best practice, but is this something that can work if you absolutely need it to? So what we’re going to do here is we’re going to run a command that is CP, which stands for Copy and V example. And now what does this mean? So what this essentially does, as you can see here inside of this code base, there is a example in the file. Let’s see here. In this envy file. It has the name for the post Christ user, the postcard password, the bright host name, and then a line for the bright token, which would be your API key. So. So that we don’t necessarily have to explain like what each one of those means and have. You have to figure all that out. What we’re doing is we’re just copying that example file into a new file called env. So I want to list out and make sure that my file now exists. It looks like it does. Now, in a text editor, you’re going to open that dot in the files. So let’s see, sometimes Visual Studio. I was thinking it wasn’t going to work. Sometimes Visual Studio Code. Does this directly from the line. Sometimes it doesn’t. So it didn’t do it today. So we’re going to redo it. Since was. And we’re going to open this up in our Visual Studio code. Great. Okay. Now we’re going to look for our dot in B file. So as you can see here, here’s the copied and B example in the E and B. And you can now paste your bright token, your API key there if you want to do it this way. So there’s two ways of essentially configuring this Brite API key. The first way is through the secrets and GitHub and the second is directly into your repo. This way through your EMV file. If you do choose to do this way and you want to push this to GitHub, I would definitely make a git ignore file and put your EMV file into that. Get ignore. Okay, great. Now what we’re going to do is we’re going to run Docker. So Docker is going to actually boot up the little sample application that we’re going to run tests on today. And the way that we do that is with Docker compose up dash dx. Now we’re going to try an experiment. I’m probably going to run Docker compose up and it’s not going to work. Let me back up a little bit. So here in my EMV file on line four, I have pasted my API key. Och, no. Going back to the next section. Dr. Campos up. Let’s go ahead and put that in our terminal window. But first, you’re going to need to boot up dock or desktop. So if you remember at the beginning. I said, You need a doctor. And this is where this is why you need doctor. So this one actually don’t. I’m going to remove so I can open up the port. So we have Docker up and Docker compose up dash dx. Now, if you are on an MX one Mac, you might see this really weird thing that’s about to happen. Happen. But maybe again, you won’t. So it didn’t happen for me this time. What I will say sometimes, if you are on an MB one, Mac Docker doesn’t play well with the M1 chip. And so if you are having problems, like if it’s throwing a ton of errors at you, I’m going to put a couple of commands in the chat right now to essentially install Rosetta onto your system and then allow the actual OS in your shell to be changed to a Linux 64 system. And that’s what Rosetta does. Yeah. Come here. Definitely. Watch out for the M1 chip. I have an M1 chip, and it’s actually caused me a lot of grief, so I would maybe not recommend it, but that’s up to you, right? Do your research. If it’s. If it’s the right decision for you, then it’s the right decision for you. Okay, cool. Tanya says she has really way less bad, probably more old Mac. Mine works all right with them. One chip. Right on. Okay, That’s good. Hm. To owners. Well, if you’re into, then you’re just too fancy for me. I don’t know. All right, all right, let’s go on. Before we get to too deep into the weeds with hm. Ones versus twos. So now we’re going to run the DB schema, and you’re going to execute a migration as shown here, This command is in the same place that you’ve been doing all your other commands, and it is NPM run migration. So who actually can tell me what this means? Does anybody have an idea? Or if, like, maybe Art wants to chime in or Tonya wants to chime in or our town wants to tell us what this does, I mean, I know what it does, but I kind of want to hear from the class.
Speaker 2: If no one else answers, I’ll answer. I’m sort of a keener, but I want to let the audience answer.
Speaker 1: I know what I am.
Speaker 2: I know I’m a keener and it’s okay.
Speaker 2: Isaac is stuck with the migration. There’s a migration error. Art or time. Would you be able to help with the migration error for Isaac?
Speaker 1: Yeah, maybe they can come in on the chat and just type some stuff there. Look all right? If anyone else is having trouble, please feel free to put in the chat right now. Um. Let’s see here. You can get users after post new users. Brian is having some problems with Docker compose up dash dx. Art is helping Isaac. Tanya is helping Brian. What about everybody else? I definitely want to get a temperature check of where everybody’s at. Like, if you have gotten this to work so far or if you are very stuck, Michelle can post a new user. Awesome. Have a couple of people able to do with. With posting a new user. Let’s do this. Let’s wait for maybe another minute to make sure that people are able to get these problems solved, that we were not just leaving people in the dust. If you have already. If you have already gotten to this point, here’s what I’m going to have you do. What I want you to do is I want you to run this command npm run test colon, seq in a new terminal window in this same repo that you have been working in this entire time. So what this is going to do is it’s actually going to start seq tester. This will take a while. The reason is, is that there’s a couple of safety reasons. So first off, the. Engine. The dust, the bright dust engine needs to boot up. It needs to make an entire new engine. The second reason is going to take a little while, because these tests need to run in sequence. They don’t run concurrently. And you might ask like, Well, why don’t these tests run concurrently? The reason is because we’re all on a free version. So if we were not on a free version, the test would run concurrently and it would be far, far faster. Ironically, like this tool, again, it’s an alpha, so we’re just trying to get it to run like in a reasonable time frame. So like in a matter of minutes. But it will take a little while. So I want you to get started on running an RPM run test seq. Okay. Let me just double check here in the chat. Unable to create an API key. Driver. Failed programming. External connectivity. Tell me more. It looks like people are getting the help they need. Um. Okay, Let me just double check. Okay. Cool. So what I want to do is for a moment here, I want to go to our our UI inside of right to show you that these tests that we’re running are actually showing up on the scans. So you can see we just ran a test here called NPM run test seq. And right here is actually you can see it in the UI that is actually running the test, which is pretty sweet. So far, it’s just told me that the elapsed time is one second, so it must have just booted up the engine and it’s just running right now. So this is something that you can do as your as you’re watching these tests run is you can come here into the UI and see when the test will run and what you can find in the meantime. Sometimes the test will not complete for like many, many minutes, but you can start to check like, oh, my first high vulnerability. Let’s go check that out. Oh, my first meeting about really, let’s go check that out. Like I said, though, this is going to be a little bit buggy. So thank you, everyone, for your patience. In the meantime, though, let’s make sure that. We can. Help people out in the chat if they need to. It looks like there’s some stuff going on which is good. Got the API key. OC. Well, let’s go back here and I’m going to talk a little bit about what you will see once the tests have finished running. So what you’re going to see is you’re going to see something like this result, like in this following screenshot, you’re going to see a fail, which is good. You want to see a fail because this is a vulnerable application that has some issues in it. So we want the test to fail so that we know. That’s the the tests are actually working. So right here you’re going to see that issue found. Target is vulnerable. You’ll see where you can find the issue in the UI. If you want to go really, really in depth and get a lot of information. You’ll see the name of the test and the severity is high. There’s also going to be remediation suggestions for you how it happened. What does this mean? What is SQL injection? How did this happen to me? How did this happen to me? And what it means. And there’s a lot of references then that will help you fix it. And that will be what the entire test failing suite looks like. Okay, here we go. And here we are today. Same exact thing that we just got here. So like I said, it does take a little bit of time. But considering that normally scans, especially with other with other scan companies, can take hours, this is pretty good that this took about 5 minutes. So, yeah, there you have it. Let’s talk about the actual anatomy of the test as well. Unless people want me to go over that section again, if anybody wants me to go over that again, please put that in the chat and then we’ll talk about this whole thing, like the output of the test itself. I see one. Yes. Let’s make sure that we have a couple more people definitely that want to go over it. Let me ask it this way. What was there anything specifically that is confusing or that you want to. Go over. And if not, then I’ll just kind of review it. Cool. All right. Let me just do another brief, a little brief overview again. So what you’ll see when this test fails, you’re going to see a couple of things. First off, you’re going to see the issue in the bright UI. If you want to actually take a look at where it is in the UI so you can get more information. You’ll have the name of the test and you have severity. Now why is. Why is the severity high? Well, again, according to the top ten, they actually ranked these these issues as sort of high, medium and low and aspirates. SQL injection is high. So that’s why the severity of it is high. You can actually also change the test to break and do different things like not break, but like break a build. If you put this in your c, C, if the severity is like medium or higher or high or low or something along those lines. So that’s also why we have it. Then we have remediation steps, which is pretty cool. So if you don’t understand a lot about SQL injection, you can read these remediation steps and get some information about how to fix this problem. Then you can have some details here of how this test happened in the first place. And then a few more references down here. Where to go for some further, some further reading. OC. That is essentially the entire the entire the entire course of running a unit test. What I do want to show you, gosh, we only have 5 minutes left, but I do want to show you what an actual test looks like. So it’s not like what is going on. I want to see what what what actual test looks like when you’re running it. So can everybody see my. Um, code. Ed, can you see my text editor? Okay, cool. Can you make it bigger? Yes, absolutely. All right. That’s a that’s probably good. Yeah. All good. Okay, cool. So these are pretty. The test pattern will follow this up. Yes. Code is syllabus. The test pattern will follow this. This overall pattern. First off, we’re going to have a describe get ID, We’re going to have a name. It should not have the SQL injection. We’re going to create a test runner right here. And then right here on line 74 to 78, we are creating a scan. So this is kind of where we are building and booting up the, the, the dast engine itself. So I’m a little distracted because I’m seeing a bunch of questions over here on the side. So we’re booting up the engine itself from line 74 to 70 to 78, and we’re specifying the test type, which is SQL, AI or SQL injection. There’s tons of different test types. It’s probably a good idea that if you’re going to name your test about having a SQL injection, that you would use the SQL injection test type. I know that may seem obvious, but sometimes that doesn’t happen just because we’re can be in a hurry or we just don’t have that extra pair of eyes to catch us. So just watch out for that. On line 79, there’s a threshold. This is kind of what I was talking about earlier, that if you have this something like in a 60 build, if the severity was medium, you could break the build. There’s also a timeout. This is not necessarily like needed, but if the test runs for like over 5 minutes, you can say forget it. Like this test is taking too long. So just like stop the test if it’s taking too long. And then here the actual running of the test, the method is going to be gets and the URL that we are testing is base URL slash users slash one. Tanya, do you want to take over right here and talk a little bit about like looking at the code that this is testing?
Speaker 2: Yeah. If we so since you are driving at if we look at the results that are on the CLI, can you go back to that for a second.
Speaker 1: Yeah. Let me find it.
Speaker 2: There we go. So when it says that there’s an error, it says so right under the word fail that’s highlighted in red. Then we see. So right near the top. Yeah. So then it says users and get and it’s trying to get the ID and it’s saying that it thinks there’s SQL injection in there. So when we go to the code we need to go to the place where we think that this command is going to be and because so we’re in an open like we’re testing and open source project on purpose to make sure we can find the things. So let me figure out where that is. So if we go to the code and then we go to source and then I believe users and there’s. Users. Was it the controller or was it the entity? Oh, these are tests, actually.
Speaker 1: Oops. My bad. I think.
Speaker 2: The second.
Speaker 1: This is it. These are down here. These are the actual.
Speaker 2: Oh, great. Okay. Yeah. So we can see that, right? Actually, where you happen to be hovering just above it says get ID and then it says Return this user’s service dot. Find one. So can we go to that definition? Are you able to right click and get to that definition?
Speaker 1: Yeah.
Speaker 2: Constructor for this? Is this the same? So the controller? Yes. So where’s the find one?
Speaker 1: Let’s find out. Let me do a control f. Find one.
Speaker 2: Let’s find all. Okay. There we go. Oh, but then it’s just sending us to the same places before being confused.
Speaker 1: We’re going to figure it out.
Speaker 2: I know it sounds weird, but because, like, I’m looking at it in GitHub and you’re looking at it in visual pseudocode. Yeah, it’s not the way I looked at it previously. So if we look in which file. So if we look at. Test and then sack. And then the user just like and let me just copy it for you. We can see where the test is running. And then I think that we found it from there.
Speaker 1: So like tester users, it’s back. Here we go.
Speaker 2: Oh, yeah. So then in there we run the test. Second name, Expert tests. Get. Sorry, I’m a little lost method. Get. We want base users. Yes. So we want to get to that where we find the ID from the users. Like I’m still I look at one folder and you’re looking at the other folder and I have to say I’m getting a little loss. So in source and then I believe it was in users. And then what was the thing that we were looking for?
Speaker 1: Find one users dot service is what one of the people recommended. Maybe we should check that out.
Speaker 2: Huh?
Speaker 1: I hear it. You know.
Speaker 2: You know what I’m doing? I’m looking in the wrong project.
Speaker 1: Oh, that’ll do it. That’ll do it.
Speaker 2: Looking in the other demo that we did yesterday where we had.
Speaker 1: Anyway, here. So here it is. And users thought service.
Speaker 2: Yeah. So if we, if we look at this so we declare that it’s named find one. So and like what it takes and what it’s going to return, then we declare a constant. But then we’re opening up a connection and then we’re immediately executing inline SQL. So what we’re doing here is select star from users where ID equals and then we’re just pasting in user input. So this is called inline SQL, where we copy together a bunch of things to create a command, and then we send it directly to the SQL Server to execute. This is really not good. It’s not good for a few reasons. The first reason is we’re getting the value that’s fed directly into that function and we haven’t validated what we’re receiving. So we don’t even know if it’s what we want. Like it’s probably a number because it’s defined as number. But what if they put 10 billion in there instead of 12? So we need to validate that it’s what we’re expecting. Then we should not be sending it directly to the database like this. What we should be doing is calling a parameterized query. So we get the ID, we validate that it is what we’re expecting. If it’s not what we’re expecting, we reject it. Then we should open the connection, add the parameters we plan to send to the parameterized query. Then we call the parameterized query, then we close our connection. I’m also not seeing a close on the connection on this, which has me slightly nervous that maybe if we run this enough times we’ll have a whole bunch of connections open and we might crash from a bit of a memory leak. Does anyone see what I’m seeing here? Like, does that make sense that right now what we’re doing is a really good recipe for SQL injection? And if we instead validate that user input and then we also only use a parameter as query. So that would be something saved onto our database server as part of our database. Does anyone have questions on this? Yeah. Thank you, Richard. Questions are absolutely, totally allowed, though. I guess once I finally figured out which project we were working in, I did all right.
Speaker 1: I think they’re.
Speaker 2: Living in the broken.
Speaker 1: Crystal. Och, I had a question. Closing connection? No. Do you want to maybe go over, like, what it means to close a connection?
Speaker 2: So I. I have never written an app in Node.js, but generally, if you open a connection later, you want to close the connection. And the reason for this is that you might call this function 20, 30 times. We don’t want to have 20 or 30 open connections to the database. We just want to have one and then we close it. Can you update the code of what to know? So we can’t update the code today specifically because then we would have to have a copy of the post grasp database and then we’d have to connect to that server and then we would have to create a stored procedure or a parameterized query, I believe it’s called. And then we would be able to call the parameter as query. So like we don’t have access to that right now, unfortunately.
Speaker 1: Yeah.
Speaker 2: But open codes for each request. Not good. Yeah. We definitely want to make sure there’s an open and a close. Don’t we already have a commented our pre written fix. Oh okay. Yeah.
Speaker 1: We have as you can see here, we have something that uses an ORM which is like okay, so we had kind of like a good better best. But the best way to do is what Tony just recommended, which unfortunately like again, because we don’t have the access, we can’t make a stored procedure. But Tony, do you want to go over like this section right here, like line 38 to 46?
Speaker 2: Um, yeah. So you can also use what are known as query placeholders or name placeholders. I actually, I don’t know, Node.js, so I actually don’t know this art, would you like to add? Because I haven’t heard of a query placeholder. It sounds good, but I actually don’t know this off by heart.
Speaker 1: Yeah, that’s fair. I don’t know this one by heart either.
Speaker 1: Ah, yes. You all right, Let me, let me check. So Aurum stands for object Relation model. So that means this handles the objects and how they should look like. And typically, if we use a a well established library, they do a lot of the citation validation everything for you, so you don’t need to worry about that. So instead of sending the query in a pure string format, if you use the ORM, it will make sure that the inputs are sanitized properly. Go. Good. Okay. I do want to be respectful of people’s time. We are a little bit over, so let’s maybe just open the floor up for some just general questions before we. We run into where we necessarily go into too much more detail on these things, if you have to. If you have to get going. We understand. Thank you so much for your time. And let’s maybe just stay for about five ish more minutes and we’ll answer some more questions. Camera wants to know their name. Go ahead.
Speaker 2: They really want to know the name of your theme and VTS code. That has come up a few times that people think it’s awesome.
Speaker 1: I Oh my gosh. I don’t know. I said it a really long time ago and I forgot the name. I know there’s a way to look up themes and maybe I can see. Let me see here. I like on theme, color theme maybe. Oh OC It’s called Winter is Coming Dark Blue. Yeah. Winter is coming. Dark blue. That’s my theme. Yeah, it’s pretty sweet. Yeah, wintertime is pretty sweet. And. Yeah, Peter, I totally get it. Sometimes people like black better. Yeah. Okay, cool. What other questions do people have? And I’m going to put up here. We have a couple of resources that we have for you. One last thing I will mention, too, is that Bright is looking for some company partners to partner with to tailor sex tester to your environment. So if you really liked this workshop and you want to give sex tester more, more kind of clout at your company and maybe integrate it into some of the things you’re working on. Hit us up a Keurig brand at Bright dot com. You can just email me and maybe we can find some kind of cool partnership or common ground there. So thank you again, everyone, for coming. Yes, you will definitely get a recording of this session. We will send it out along with the certificate of participation so everyone is going to get one automatically that is going to be sent to the email you provided when you signed up. And yeah, if you want to take a picture of this slide that has all these resources on it, we’d love to see you in our Discord. I’d love to hear from you on email, love to hear any kind of feedback you have. We’d love to see you on the We have Purple community. It’s a free cyber community. Yeah. Thank you everyone for coming. And I’ll keep the room open for maybe like two more minutes. And yeah, we really appreciate your time. I hope you had a good time. It was a lot of fun just to like, hack on stuff. It was a good time, I think. And you learned about obscurity and you had all these wins and that was amazing. So congratulations, everybody, on on all of the on all the wins that you got today. And thank you again so much for coming.