Hack Your Own App

00:00:00

Speaker 1: Welcome, everybody, to hack your own app. My name is Akira Brand. I work in developer relations at Bright Security, and this is my coworker Oli, and he is the head of product marketing at Bright. Oli, do you want to say a couple of words to introduce yourself?

00:00:15

Speaker 2: I think you did a sterling job yourself, Akira, but really, really looking forward to this workshop. So yeah, I think let’s get cracking.

00:00:26

Speaker 1: Right on. All right, So here’s what we’re going to cover today. So today we’re going to cover application security, what it is and how we do it. I’m going to convince you why you need to write secure code and also how you can start to work on writing secure code. We’ll talk about why we are going to use Bright as our magical tool that we’re going to teach you today to scan your own apps for Web vulnerabilities. And then at the very end, we’ll have a workshop. We’ll go over some common vulnerabilities that we found using the Bright scanner. We’re going to scan an intentionally vulnerable Web application. We’ll go over those results with you and we’ll have a little bit of time for Q&A at the very end. At the end of the day, what I really want to leave you with is that writing secure software is worth the effort. So if there’s nothing else that you leave this talk with today, it’s that looking into writing secure software, learning about the principles of writing secure software is absolutely worth it to you. Okay, I know Oli had a moment to introduce himself. Let’s talk about me a little bit. So my name again is Akira. I’m a software developer and an educator. I’ve worked in software development for three years, mainly in e-commerce and edtech. One of my coolest things I like to talk about that I’m really proud of is I was a NASA Hackathon Award recipient back when I was first starting my software development journey. We made a concept that uses NASA’s satellite data to scan refugee camps to see what kind of resources would be the most needed at those camps. And then a fun fact about me is that I moonlight as an opera singer. I was a musicAyan for over ten years professionally before I moved to tech, and I still do perform quite a bit. So if you Google my name and the word opera, you will find some cool stuff. All right. So here’s what you need to participate today. You need a laptop or a desktop, of course, with admin privileges and the ability to install software. The reason being is we are going to install Bright’s DAST today. We’re also going to install something called a repeater, which essentAyally is a tool to make sure that when you are scanning, the scan itself comes from your IP address, not from our IP address on the cloud. And for those two things, you do need admin privileges. You’ll need a modern web browser like Firefox or Google Chrome, of course, connected to the wi-fi. If you are watching this and not connected to wifi, I want to know how, you must be very impressive. And if you want, you can just watch. You don’t really necessarily need to do the workshop to learn something from this, from this class. And Mark. Yes, MacBook is totally fine. That’s what I’m on. Dennis is hard wired in. Right on. All right. Sounds like a plan. Let’s keep going. So our goal today is helping you automate your application security. So imagine that you are building your dream house, you have saved for this house for over 20 years. You finally are able to find the builders. You have the perfect plot of land, and you go ahead and build your dream house for you and maybe your partner. Maybe y’all have some children. Let’s say you have five or six children. You know, you have a lot of kids. Once you’re done building this house, you look at the floor plan and you realize, oh no, I forgot to add more than one bathroom and I have six children. This is going to be chaos. What was I thinking? So now you have to spend a lot more money, a lot more time. Your builders are really irritated with you. Your flat broke at this point to add more bathrooms. Otherwise there’s going to be chaos in your house, right? With six children and two adults. So that is kind of what happens with software and security. So in the software development lifecycle, we have our process, we have our planning phase, we have our build phase, we have our test phase, and then we have release. Now what normally happens with security is that it sort of gets shoehorned in, in between tests and in between and release, and that is very expensive. It’s similar to looking at your house and going, Oh no, I forgot to add bathrooms. So that’s expensive. It’s stressful. Software gets released with a bunch of security bugs. It’s not great. So what we want to empower you to do today is to shift security left in the software development lifecycle. So what we mean by that is we want to shift the mentality of writing secure code and testing your code to make sure that it is secure much earlier in the SDLC. So we’re talking about in the planning phase from inception and using a tool like a DAST like Bright’s DAST will help you to do that and help to automate that. So why do we care? Why bother writing secure code? Let me say it this way. Like with the house, the earlier you do it, the cheaper and easier it is to deal with. Security issues are a big deal. If you are a software developer, you could be writing software, for example, for someone’s heart monitor, you could be writing it for airplanes, you could be writing it for hospitals. And if that code is not secure from jump, a hacker can get in, a bad actor can get in and really mess with people’s livelihoods. This comes down to something called the CAya TrAyangle, which stands for confidentAyality, availability and integrity. This trAyangle is the raison d’etre. It’s the reason of being for all InfoSec security teams in your company. So if you are having this mentality of, okay, is the code I’m writing available at all times, is the code I’m writing protecting my users confidentAyality? Is it protecting the integrity of the data? You can actually partner much better with your security team and in a way you can kind of get them off your back a little bit, right? Which is something that can be a source of tension in many companies. So, of course, we talked a little bit about what can happen with Insecure Code. Another thing that can happen, Web servers behind a firewall can if someone gets behind that, they can attack your network, they can attack your database, they can change it, they can copy it, they can delete it, and it’s just a mess. So the earlier you fix this, the earlier you look into it and the more intentional you are about it, the better. So what are we going to do about it? We’re going to come in with our superhero capes and we’re going to do something about it today. So Bright is going to be the DAST scanner to the rescue. It’s a magical tool that we are teaching you today to take to your own code and scan it for security vulnerabilities. Hopefully that as you leave this workshop, you will decide that you want to test your own code with what you learned today before you send it to QA. You could even build this DAST into your CI/CD pipeline if you have one. And I do promise you that if you continue to be curious and creative, you will get better at secure coding. Okay. So I want to hand it off to Oli right now. He’s going to talk a little bit more about Bright itself and how it compares and contrasts with other security tools out there, which you can also use for your code.

00:08:05

Speaker 2: Yeah. Thank you. Thank you, Akira, and a great introduction. And really the main focus of this is being able to shift security testing left. So putting security testing into the hands of the developers. And one thing I wanted to say sort of first and foremost is in the recent Gartner document on application security testing, really interesting fact that they came up with now having done a survey with a considerable number of organizations spanning multiple different sizes, but particularly across enterprise ones as well, is actually that 50% of engineering managers are now responsible for application security. The tide is certainly shifting to enable or to ensure that security testing is keeping up with you, the developer’s pace so that you’re not going to be shipping security vulnerabilities into production at the same rate that you are new features and everything else. So being able to put security testing into the hands of you, the developer, really is important to ensure that you’re secure by design. But ultimately you need a tool that’s going to keep up with the pace of you, the developer. So to put a bit of context into who Bright are and I suppose where we fit into your pipelines and into your SDLC. So some of you may or may not be using software composition analysis, SCA, for example, and please let us know in the in the chat I did see one person in the chat say that you were using a multitude of different DAST tools in particular, but it’d be great to see what other tools you guys out there are using. The SCA is looking at your dependencies, looking at the libraries, ensuring that they’re patched and indeed up to date. So you may be using the likes of Snyk or Fossa or indeed JFrog, for example. Then you may be using static application security testing tools, SAST tools that really are looking pretty much from a one dimensional space. But looking at your code as you type it, looking for security vulnerabilities, which is a really, really useful tool to ensure that you are finding certain vulnerabilities as early as possible. But actually this technology is fraught with false positives. And because it’s not looking at the built or the running or the compiled application, actually what happens is, you’re missing a lot of the vulnerabilities. That will always mean that you have to rely on one or  indeed two of two things, a manual penetration test that’s going to be carried out periodically, perhaps, by a security team, if you have one, or indeed is a sort of complAyance checkbox once a year on a periodic basis. And it’s those that will actually be using a dynamic application security testing tool like Brights, to actually look for exploitable vulnerabilities in your applications, in your application, in your APIs, sorry. Looking at it from the outside in, in the same way that a malicious user or an ethical hacker or an actual hacker would be as well. So you would always have to carry out some form of dynamic scan or manual testing that will be looking for these exploitable vulnerabilities at some point. And when we talk about shift left, SCA and SAST have always predominantly been a developer focused tool and actually it’s really about putting the missing link in that chain as early as possible and putting DAST, dynamic application security testing into the hands of developers as early as possible, as Akira mentioned. And to be able to run these tests as often as possible as well against your internal apps, web apps, APIs, etc.. Next slide, please Akira. So, what we did, DAST tools have been around for a long time. It’s a very old established technology but has typically been built for security professionals, for cybersecurity experts, for penetration testers, AppSec specAyalists to use, not built from the ground up to enable developers to actually start to own this process. Now, we’ve looked at the limitations and the pain points the organizations have in being able to implement comprehensive, effective dynamic security testing scans built into the SDLC as part of your CI/CD pipelines. And we’ve done this in a number of different ways. And this is really a sort of introduction before we go into the workshops so you can sort of get an understanding of the sort of capabilities that are very, very developer focused with the Bright technology. So first of all, is the coverage and analysis. You have the ability to scan your web apps, your internal apps, APIs, whether that’s Soap, Rest, GraphQL, and we also have Web Socket support too. In this age of this very agile development that we have and a very, very heavy relAyance on APIs and microservices, this is going to be fully supported with the Bright scanner. We’re going to get on to that and showcase to you how that can be used to test those as well. Trying to scan against login defined places of the application behind a multitude of different authentication mechanisms will also be supported with the Bright scanner, and we support a number of different ones and we will get on to that because I know that I’m sure you’re all sort of raring to get to to the workshop, but you’ll see that there are multiple different ways for us to discover the attack surface for developers, AppSec professionals, we have crawling. Now, this will crawl the application, crawl the web app, detect the entry points, extract the parameters and actually build the attack surface in order to carry out the tests. And we have a proprietary headless browser technology that actually enables our engine and our crawler to interact with your targets very much like a human would to mimic a human interaction with the web application. And this enables us to interact with dropdowns, clickable parts of the website in order to maximize the attack surface, because it’s all about maximizing coverage, running tests as early as possible, finding security vulnerabilities early and often in order to remedAyate them way before they hit production. If you are and subject to, I suppose, the maturity of your processes here, you could also leverage QA to actually also start carrying out the security test. Or if you’re a developer and you’re using proxies like Selenium, Cyprus.io, or indeed others, you can actually start to leverage your existing functional scripts to now start carrying out security tests as well by uploading Har files, HTTP Har files into the scanner. This is a recorded interaction and actually it will enable you to also scope out and define the scope of the tests. Record an interaction with a specific entry point, upload the Har, run a scan that’s going to actually last for a few minutes instead of several hours and days. And that’s really what you, the developers need. You need scans that are going to be fast and in order to maintain your rapid release cycles. And as we mentioned before, the sort of relAyance now in the heavy use of microservices single page applications as well as the exponentAyal growth, of course with APIs, you have the ability of being able to test these by uploading your, your API schema or your API documentation, whether that’s swagger or open API or indeed uploading your your postman collections as well. And we’ll show you how you can do that during the workshop, but also enable you to actually scope the tests as part of that as well, using our open API schema editor that’s in-built. But really for this to really be effective, how have we made this useful for you, the developer, what tools are at your use in order to have DAST intrinsically in your CI/CD pipelines? So we really are truly built for developers from the ground up. We weren’t, we didn’t start off as a security testing tool built for pentesters, built from the ground up to be a DAST tool built for you, the developers, so you can stay within your terminal, right. Configure scans and control scans directly from the CLI vAya code. As Akira mentioned, actually, the endgame is to have the Bright scanner integrated into your CI/CD pipelines. Every single build, every commit automatically spins off a scan in order to test, in order to test for security vulnerabilities. And actually then you get that direct feedback loop, which is really so important for developers to own that security testing process. As Akira mentioned, there’s nothing worse than building your house and realizing you forgot to put the bathroom in once it’s finished. There’s nothing worse for a developer than a year later getting a knock on your shoulder to say, by the way, you made a mistake one year ago when you were working on this specific feature and suddenly your context switching, right? You now need to go back, try and find out what you were doing, it’s been ages since you’ve been working on that specific feature, the specific developer that was working on that may not even be there anymore. So the earlier that you can do this, you’re going to be secure by design. So these can be fully controlled with YAML configuration files to manage the process and we can build the scan surface from the very first unit test. And actually if you haven’t already done so. Sign up for our newsletter. We’ve got some very exciting news about unit testing and we’ve integrated our scanner with certain unit testing and web frameworks in order to carry out DAST scans even earlier on every function or every component that you make with tests that last for seconds, not minutes. And that really is that really is key. One of the fundamental pillars of our technology. And I’m sure if we were sat in an auditorium now and I can see you all, I’d ask, hands up, if you hate false positives, you’ll all be jumping in your seats in agreement. So one of the fundamental things with our technology is that we go through an automatic validation of every exploitable vulnerability that we can detect. So once we go through the workshop and once you sign up and start using our scanner to test your applications and APIs, you can be categorically sure that every result, every report, every vulnerability that we report has been automatically validated by our engine. So it’s actually actionable, right? You don’t need to go away and manually validate. And if there are any engineering managers or anything along those lines, if there’s anyone from a cybersecurity background or you’re an AppSec person dealing with your pipeline, how much time are you wasting in prioritizing which vulnerabilities do I want to test? And a key issue with security debt, which actually leads to a substantAyal amount of technical debt because of that, is not actually knowing where your security vulnerabilities are. Your Gred Tickets are bursting at the seams because they need to go through that manual validation. And actually what happens is the tool gets ignored at best and more than likely actually gets disabled. It’s one of the fundamental pain points that our technology looks to address. Accurate results with developer friendly remedAyation guidelines. So you know that what’s real is there, prioritize the fix, and then be secured by design and all of this integrated into your pipeline. There is a nice UI for security and Akira is going to be going through the UI showing you how to run a scan. But ultimately it’s all about you staying within your environment. So using the CLI, integrating with CircleCI with Jenkins or Ticketing in order to automate the process and we talk about shift left, DevOps, DevSecOps all these different terminologies and methodologies. It’s all about automation and it’s all about developers which typically outweigh security by 50 or 100 to 1 being part of the solution and having this collaborative team to actually start fixing vulnerabilities early and often. In terms of speed, one thing you’ll notice is actually the speed at which they are going to test. And that really also boils down to the way that you can scope and define the test. As I’ve mentioned before, adjusting the scan scope to have those tests that run for minutes, not hours and indeed days. And one thing we’ll show you is a very Bright, if you want to call that Bright as an intelligent but smart scanner, that actually takes away a lot of the heavy lifting for you, the developers. So actually automatically skipping certain tests that are going to be irrelevant without the need for you to go through what can be a very lengthy and complicated configuration of other tools. I noticed one of the…from the chat BurpSuite, OWASP Zap and a few others. These are very much security testing tools built for pentesters. So we tried to remove that. And I think once you sign up and we go through it with Akira, you’ll really notice how the engine is so easy to use. You can literally be up and scanning within minutes. And for those of you that are sort of looking at payloads or interested in that, I’ve mentioned the smart scanning, we also interact with the target applications. So we’re not just looking at trivAyal attacks or injections, but our smart technology can understand context. And actually we look to try and break the logic. How can we break your validation mechanisms within your application to try and find logic based or business logic vulnerabilities? And this is really key to not only just trying to find the trivAyal stuff, but how can we find as much as possible as early on in order so that you’re not having to fix these way downstream once they’re in production and hopefully you find them before someone else does? So we’ll go through during the workshop and we can look at some of the testing categories there. Next slide, please.

00:23:06

Speaker 1: And Oli, we have a couple of questions. Can you answer them really quick? Yeah. So I can read them out. So the first one is, is the scanner the same as having a router which can monitor traffic of devices?

00:23:28

Speaker 2: So, which was the…

00:23:31

Speaker 1: Oh, these are in the chat.

00:23:34

Speaker 2: Is the scanner the same as having a router which can monitor traffic of devices. So so, so we are a scanner, so we’re not monitoring the traffic. What I was alluding to before, maybe with the Har file is a proxy that will monitor the traffic, look at the responses and the requests. Then you can then save all that content to then feed that into the engine and then we can use that to then replay and then start to attack it. So we’re not looking at we’re not looking at that part. No. Scanner actively investigate, monitor passively, see what happens. Oh, I see. That was Mike replying to the same question. VirusTotal I must admit I’m not familAyar with that. Scans files. So we do have a file upload test that we can get through that as well. We are a dynamic application security testing tool. In fact, if you go to our docs, docs.brightsec.com, you can see a full list of all the different vulnerabilities that we try and detect there. I’m just going to try and scoot through a lot of these now. If not, we can wait till the end. Interference from software like malware bytes. So yeah, so interference there will be interference from WAFs, for example. That’s what Akira alluded to before. If you’re using the repeater, you may have to whitelist our IP, but typically if you’re using the repeater, that will then also come through your IP address. So you shouldn’t have a problem there. How does this compare with something like Rapid7? So yeah, Rapid7 also had a DAST tool and all of the reasons that I mentioned beforehand are reasons why we built our technology. Better coverage, authentication mechanisms, developer first, first and foremost, built from the ground up for developers. No false positives, among a multitude of other different reasons. James We can certainly have a more in depth conversation about that. But looking at this slide, Thank you, Akira. This is really what it should look like. So typically Dast was performed at stages four and five. Actually, what you should be using is the Bright scanner as early as possible. Every single time some code is committed, it triggers the CI, it initAyates the scan with Bright. You can set, of course, as part of those YAML configuration files at the breakpoint, whether you want the scan to continue going or whether or not you want the scan to stop. And that way you can start to run tests against every build, every commit to really, really be secure by design. We have multiple integrations with ticketing, with messaging like Slack, for example. It’s all about having that feedback loop back to the developers, perhaps governed by security, looking through the UI, but ultimately you want to stay within your within your terminal, automate as much of the process, find the low to medium and some many high hanging fruits, and then be in a position to remedAyate these a lot sooner more often. And like we’ve said multiple times, it’s going to be the cheapest, most efficient way for a business case for the number crunchers out there for you as a developer. Get it done now. You won’t need to do it later and focus on actually doing what we want to do, and that’s releasing really, really cool features at breakneck speed. Yeah, I think I’m done, actually. I think that’s my last slide, Akira. 

00:27:06

Speaker 1: Awesome. Okay, thanks. Thanks, Oli. And then one last question. Do we integrate with Microsoft teams?

00:27:13

Speaker 2: Microsoft teams? No, not yet, But I like that idea. So I’m going to put that. I’m going to put that to our product. Anyone else use MS Teams? I’m assuming, is that for ticketing or anything along those lines for messaging? Okay.

00:27:38

Speaker 1: I’ve got a couple of people.

00:27:39

Speaker 2: Always good to get some feedback. Thank you.

00:27:44

Speaker 1: All right. Awesome. Thanks, Oli. And then hopefully we have convinced you that using Bright is a good way to go. And that is what we’re going to use today as our DAST scanner of choice. So with that being said, let’s get into the workshop. And yes, I love all of the talk about MS teams. I used it in my last job and oh, what a time. Okay, so let’s get going. So here’s what we’re going to do in this workshop. The first thing we do, we’re going to set up an account with Bright. We’re going to download and install the repeater. We’re going to create a scan together using the UI. We’re not going to do it through our terminal today, but through the UI. We’ll run a scan on an intentionally vulnerable website called brokencrystals.com. While the scan runs, we’re going to talk a little bit more about the tool. We’re also going to talk about prevention tips for you because, of course, the best way to deal with cybersecurity vulnerabilities is to never write them into your code in the first place. So we’ll talk about some prevention and then we’ll discuss a few of the results from our scan. So the first thing we’re going to do, I would please like everyone to go to www.brightsec.com. I’m going to do this with you.

00:29:03

Speaker 2: I’ve actually put a link, Akira, in the chat if people want to…

00:29:06

Speaker 1: Oh you did! 

00:29:07

Speaker 2: Use that and it will actually take you directly to the sign up page.

00:29:12

Speaker 1: Oh fantastic, okay. So if you use that link, it’ll go directly to the sign up page. But if you go to brightsec.com up here on the top, right, you’re going to click sign up. So let’s go to “try it free”. So we’re going to go to “create a free account”. You can do this a couple of ways. You can do this with your GitHub. That’s what I did. It’s the simplest way for me as a developer to just get things done. But you can also sign up with Google or you can sign up with your email. Today I’m going to use an email sign up because I already have my GitHub account connected. So we’re going to sign up with a new and improved email for myself, but choose your sign up method. And again, if you have questions or problems, put them in the Q&A or put them in the chat. So let’s go sign up with email. First off, my full name, Akira Brand. Email, we’re going to use my Gmail right here. Password, choose a password that is secure. That would be super ironic if you chose an insecure password to use with this. All right. And then create free account. So of course, as is the case with many modern web apps, we’re going to confirm our email address. So I’m actually going to do that on a page over here that you can’t see, but you just have to trust me that I am doing it. Let’s go to Gmail and confirm an email address. Okay, so let’s verify my email. Okay, So now I’m going to go here to sign in and pull this over. Okay. Let’s go ahead and sign in. So let’s go here. Let’s go back to our shared screen. So I have confirmed my email. And again, some of you might have already done this before, or you have done this by now. But just in case we’re still running behind with some people, that’s also totally fine and we want to walk through. So let’s create a new organization. We’re going to call this Akira’s awesome organization, of course. So go ahead and create. And this is the setup wizard. So I definitely want to walk people through the setup wizard here if we can. So the setup wizard, the intention is that this will help you install the repeater on your machine and it’ll also help you install the CLI. Because of course I work here, I already have the CLI and the repeater installed, but I did want to walk you through the process. So what you do is you can push next and depending on what kind of machine you’re on, you can use Docker, you can use NPM and you can use the Windows installer. I personally am on a mac and so I like to use NPM, so that’s what I’m going to use. But like I said, you can also use Docker or the Windows installer. What you can do is you will copy this command, you’ll go to your terminal, where is my terminal and sorry, open the terminal here. You’ll copy this and paste it in your terminal. Like I said, I already have the CLI installed and so I won’t need to necessarily do that. But what I will do after you install that is what you should do, you should click on this button down here and make sure that it is installed by checking the version. So let’s go ahead and do that together. I’m going to close this because it’s a little distracting. All right. So version 8.7.1, that is the current version. That should be what you’re getting. If you’re not, let us know in the chat. And just to make sure that your CLI has been installed. So then we’re going to push next. What you can do here is you’re going to start the repeater. And again, this will start the repeater. And to make sure that all scans come from your IP address, not the IP address of Bright. The main reason for this is because we want to make sure that when you are scanning, it’s all essentAyally all kosher, It’s all good. Because sometimes people will try to scan web apps that they don’t have authorization or permission to scan. There’s one thing I do want to mention is that don’t go ahead and scan like walmart.com because you do not have written permission to do that. So that’s what the repeater does, essentAyally says, okay, this scan is coming from your computer, not ours. So that if you try to do kind of strange stuff, it’s on you at this point. Okay. Let’s take another break really quick to check out some troubleshooting issues. Ayah says, is it the command at Windows? Good question. The Windows installer, I think are you talking about… are you talking about the CLI or are you talking about the repeater? If you could just…okay cool.

00:34:30

Speaker 2: Yeah…

00:34:33

Speaker 1: Go ahead, Oli.

00:34:34

Speaker 2: I was just going to say he’s talking about the command line. So. Yeah, it would be for that for Windows. But I have reached out to a colleague just to see what the issue is with the Windows installer. So I’ll come back to you all once I have some verification.

00:34:52

Speaker 1: Okay cool, we’ll get that to you in just a moment with some support. And Yassar had, yeah, he had a really good workaround. You can use this other version. Okay, John is up and running. Dan, the repeater version 8.8.0 repeater running, that should be okay. Let’s see here. Katherine, can you give me a little bit more details about where you’re struggling on the CLI? Because then we can help you. I’ll wait for you a little bit there. Just. Katherine, definitely want to know where you’re struggling so we can give you some help. Okay, let’s continue on. So what we’re going to do here is we’re going to start the repeater with the following command. I’m going to do it with NPM, not with Windows installer. So I’m going to get some really strange things. And this repeater, it does need to be started in order for us to use it, of course. So let’s go back here to our terminal and we’ll start the repeater. All right, starting the repeater. Copy and paste in the command line, but I found errors. Command not found. Katherine, what are you on a windows or a mac? Mac. And are you stuck in the CLI section or are you stuck on the repeater section? CLI section, okay. So what I want you to try,  let’s troubleshoot this for a little bit. And if it works, cool. And if not, we’ll move on. And maybe Oli can help you one on one a little bit more. What I want you to do is, instead of copy/pasting it, actually click on these two squares right here that will actually copy the full command. My guess is that potentAyally what happened is that maybe one of the characters didn’t get properly copied. So try copying that top one right there and then just paste it into your terminal. And then let me know what happens there. Okay, let’s continue. All right. For everybody else, what I want you to do is definitely check and see that your repeater is started. It should say something like this. The repeater started. All right, Katherine, that’s a good point from Kenya and Juan that make sure you have Node and NPM installed, otherwise it will not work. So, cool, Mark has 8.8.0 repeater installed. That started. That’s fine. That’s good. All right. Let’s move on, Katherine. Definitely check to see if you have node installed. And if not, go ahead and install node as well, and then that will help. Right. And if you have more questions, please put in the chat and then Oli, if you’d be willing, if you could also maybe help Katherine and anybody else as we continue forward, that would be great.

00:37:45

Speaker 2: Yeah. Thank you. I’m just going to get a link. I think Aya actually provided the correct link. I think that may be an issue with the link there. Once I have that, I will put it in the chat for everyone, don’t worry.

00:37:56

Speaker 1: Okay, cool. Cool. All right, let’s move on. If at this point you’re super, super stuck, it’s okay. Just continue to watch and you will definitely still learn some stuff from this. No stress, no panic. We’ll get it figured out. Okay, let’s push done. We are, our repeaters started and we’re good to go. So the first thing we’re going to do, we’re here in the NeuraLegion CLI. As you can see, I have dark mode on. We do have a dark mode. And what you’re going to do is on the top left here, you’re going to push “create scan”. We’re going to name our scan. I’m going to say scan number one. We’re going to choose a project, for now it’s just going to be a default project. We’re going to do a single scan. And what you can do here is if you want, you can choose a template. So you can choose a shorter version of a scan. You can have a light scan, a passive scan. You can scan just for the main things on the OWASP top ten. So that is possible. For now, let’s go ahead and choose the OWASP top ten. We’re going to do import configuration. Okay. And. Let’s see here. What we’re now going to do is we’re going to go over here to “Targets”. This is where we’re going to input our URL. The attack service discovery. Go ahead and push “vAya automatic crawling”. Our repeaters, we’re going to use the default repeater that we just started in our CLI. One thing that is good to know is that if you close your computer or your computer goes to sleep, the scan will stop. So make sure that your computer, make sure that your computer stays open. Now for the crawler target, we’re going to do https://brokencrystals.com. That is the URL of the target that we are going to be scanning today. This is the intentionally vulnerable website. All of this for now, we’re not going to worry too much about Oli will go over some of the more intense or the more in depth abilities and what you’re going to scan in a minute here. But for now, we’re just doing a very basic scan and then we’re going to push start scan. Yes. Okay. And now, while this is scanning, let’s take a second and look at the questions that we had and do some troubleshooting. And then after that, Oli will talk a little bit more about the advanced scanning options. And then from there, again, while the scan is still running, we will talk a little bit about prevention. So for now, Oli, I’m going to open the floor to both of us so that we can help answer questions and we can help troubleshoot a little bit. Does that sound like a plan?

00:40:54

Speaker 2: That sounds like a plan. Yes. So just so everyone knows anyone that’s using Windows, I put a link in there for the correct download for the nexploit-cli.msi there for you. I think it’s the same one that Aya put, so thank you very much for that. But that should be done for you. Nexploit CLI is installed, but as soon as I open as admin, the screen vanishes. Let me know if there is any solution to it. Aya, which screen is vanishing, if you don’t mind me asking? Then we can look at that as well. I’m going to start from the bottom and work my way up just because that’s the way that my scroller works. I don’t know how high up to go. Do we have plans to add the top ten 2021 updates? So James, great question. Yes, we are. I think they’ve actually already been implemented. We’re actually doing a series of internal benchmarking and very, very soon we will have the most coverage for the OWASP top ten of any DAST out there, really alluding to the capabilities of the way that we interact and perform our tests actually to enable you to cover a lot more of that. So, yes, the answer to that is yes and including, by the way, the API top ten as well. And. Uh, let’s see. Tucker finds. Mark, has the repeater started great. Leandro, Done. Wonderful. Lets see, copy and paste in the command line. Max. CLI section same result. Katherine, uh continuing to scroll up a bit more. John’s Connected and up and running great. Jan, repeater running with the most up to date one, fantastic. Aya had the issue with MSI, which actually should now be resolved. Please do let us know. John’s up and running, which is great, as is Juan. Okay, now let’s start from the beginning again. So, API top ten and  OWASP top ten. So the OWASP top ten really looks at the top ten security vulnerabilities that are out there in the wild. They take a lot of information from organizations across the world, including many sort of large multinational enterprise organizations, to really try and understand which were the most exploited vulnerabilities there and which are the ones that you should really, really be focusing on. Which ones are the flavor of the year, as it were. So there’s obviously different exploits for both, you know, web applications and indeed APIs. So you can do a simple search of OWASP top ten, OWASP API top ten, and you’ll see there are two or three differences. Actually, it’s very, very similar. But because of the rise in the usage and indeed the rise in the exploiting of APIs that have led to some pretty serious breaches with tens, if not hundreds of millions of people’s data being stolen. Actually, what OWASP rightly did and they’re an unbelievable organization, they’ve created the OWASP API top ten as well. So when you look at our templates or if you want to look at configuring your scans a bit differently, there are going to be certain tests that are going to be irrelevant to test APIs and you’ll be able to see those in the templates as well. Let’s see, I open it for Windows nexploit opened as admin, the screen opens and vanishes. I am afraid I don’t have a solution to that. I’m afraid. Let’s see, what capabilities you offer for APIs can swagger files be leveraged. So, James, that’s a great question. Yes, absolutely. So Akira, if you wouldn’t mind just hitting create scan. Yeah and that’s let’s, let’s show James the API security testing capability. So let’s actually, let’s go to the advanced section actually, it’s not that advanced. The standard is really there to just click and go. But let’s just look at the advanced for a second. So we’ll call it Oli’s scan, wonderful. It always needs to be assigned to a project. Scan template, we don’t need that. Just scroll down a little bit more. We’ve also got scheduling just so that you can schedule a scan for a specific scan to run over the weekend. Or if you wanted to run multiple scans daily, weekly, monthly, then you can schedule that there just so that you’re all aware if you click on targets, please Akira, on the left. 

00:45:45

Speaker 1: Target, here we go, sorry about that.

00:45:48

Speaker 2: So James, you can see here that a bit above Akira. So what you’ll see, you’ll see we have a different discovery attack surface methods. So what Akira showcased was the crawling. We also have the recorded session via Har and this is what I was explaining before, where you have the ability of leveraging HTTP archive files or har files which are a recorded interaction with the target application. Now you can also leverage your functional scripts if you’re using Selenium or Cyprus. All of those functional scripts can be exported as a har file. Or if you were just to go to a web app, open up the developer tools. In fact, Akira just open up broken crystals and we can show them this. Yeah. So if we open up the developer tools, F-12 or shift F-12 inspect, go to the network tab, which is yeah, if you disable cache, preserve logs and disable cache and preserve logs. So if we were to then go to, let’s say the sign in or the contact us form page of the website. You can see here, though, actually what we do is we we can record the requests and the responses. Now, this is a very good way of being able to really scope the definition of the test. So if you just worked on a new contact us form just to keep it really, really simple, you can just put your name in the name, email address, add a note and click submit that will record the requests and the responses from the application. If Akira were to right click on the request and the response on the right hand side, I’m not sure if we’ll be able to see it with your screen share. There we go. You can save all as Har with content. Now this gives you the ability of interacting with perhaps harder to reach parts of your application. Maybe you want to record a login sequence or login process and we can then record the cookies or the tokens or whatever it might be within the Har file and then use that to, to scan, to authenticate. If you wanted to look at microservices, then that will be picked up and even in the Har file pick up certain API calls and then you can then include that as part of the hosts in order to then start scanning the API that’s defined within the scope of that Har file. And if you saved all content with Har, you can then simply go. If you just go back to the UI, please, you can upload that with the Har. So literally if you scroll down you’ll be able to upload the file from a disk or a pre uploaded file that you might have already within your storage within the UI. And just if you scroll up to the top please Akira, you also have the ability, by the way, of running crawling with the Har file concurrently. So if you wanted to test an authenticated part or wanted to test a specific authentication mechanism, you could use that as part of the Har and then have the crawler to then start crawling other parts of it as well. But you have that functionality there to use either of them or indeed both at the same time. But going back to James’s original question about what capabilities we offer for APIs, can swagger files be supported? Absolutely. So if we just click on the via API schema.

00:49:21

Speaker 1: Yep, sorry one second. 

00:49:25

Speaker 2: Okay. Now, if you scroll down and there’s multiple different methods of you doing it, so you can upload a file from your disk, so add your swagger or open API documentation or indeed your postman collections. You can again of course use a pre-uploaded file that’s already uploaded into the engine or you can link to a file. So if you have your API schema on the web or whatever it might be, you can actually link to that as well and we can actually showcase that now. So Akira, if you just go back to broken crystals. And by the way, all of you can do this as well, maybe not now if your scan is still running, but just go back on this application and you can still see the request response still being recorded. If you click on API schema, this is something you can all do after your initIal scans done. Click on OpenAPI JSON. Okay. And we can see here that this is actually our API schema that’s open for everyone to see. You can just simply copy that link. Put that into the UI. And link to file. Paste that within. And then you can see there that actually the hosts will get passed. It’s an authorized host. And another thing that we can show you here is actually we can open up the schema in our schema editor. Now, what does this do? You can see here that on the left hand side it says broken crystals. There’s a yellow dot there. Now, what this shows actually is that we’re missing a lot of information within our API schema here. So it’s a way of you being able to, one, validate it’s basically an API linter, enables you to validate whether your API schema has got the correct content in there. So if we just scroll down, we can see we’ve got broken crystals/paths and then we got POST/API/render and then it will show that we’re missing something, Akira if you just scroll down a little bit. So just click on that, click on the dropdown and we can see here that we’re missing. Yep, click on that. We can scroll down and see that we’re missing the value here. Now why is this relevant? So first of all, we should really always have an example of a value. Is it an email address or whatever it might be? Is it a specific string? And this actually one, means that you’ve got a complete API schema, but it also means that you’re going to have a proper functioning, comprehensive security scan because the engine needs to know what it’s supposed to expect. So it’s just one other way of ensuring that your API scans are going to be full, are going to be complete, and are going to return proper results. One big issue when it comes down to security testing, particularly APIs when using the schema, is that the schema just aren’t right. They’re not relevant. They obviously need to be written by developers. You’ve got 1000 other things that you need to do on your plate. So it’s just another way of being able to validate that the schema is correct and up to date. So you can input those details and that obviously ensures that your scan is going to be not only successful but also comprehensive. Just click on cancel, Akira. And then we have all the same settings that you may have as you’d expect. So obviously we’re now in the advanced mode. We have coverage exclusions. If you wanted to add any specific regex’s to not include, a blog that has one and one half thousand pages of the same article with just text and an image. That’s just going to cause the scan to go on and on and on for no reason whatsoever. And there’s going to be some really cool technology and functionality coming into play with our scanner that will hopefully be in a position to automatically remove those pages. Just click on attack surface optimization, please Akira.

00:53:33

Speaker 1: Yep.

00:53:35

Speaker 2: And what you have here, this is something that I alluded to in my short introduction, by the way. So the engine has a number of scan optimizations already inbuilt into the technology. So, you know, is the scan going to keep on going when the target doesn’t respond for 5 minutes or 20 seconds or whatever it might be? There’s obviously going to be an issue there and that’s going to cause the scan to stop. So this is again, another issue that you have with security testing so you can set it to to either stop the scan or just not test that particular entry point if there’s no response. Smart scan is a really nice functionality of our technology. Just click on the I. please Akira.

00:54:18

Speaker 1: On, sorry it’s a little loud. 

00:54:19

Speaker 2: It’s a little smart scan.

00:54:21

Speaker 1: Smart scan. Yep.

00:54:24

Speaker 2: There we go. Just so people can have something to read there. But it’s our engine using smart decisions so that we’re minimizing the amount of configuration that you have. Like I mentioned before, DAST tools are historically and even now built for security professionals, the cybersecurity experts for penetration testers that want to have a thousand different configurations, to look at all the edge cases to really try and manipulate the scanning. This just doesn’t work and it’s not going to cut it for developers. What you want to have is a tool that’s going to be seamlessly integrated and actually one that you can use. Try and find those low to medium hanging fruits early and often that actually you can take and use and that the scans are going to be effective and with proper actionable results. But smart scan will include things like parameter skipping. It will optimize certain detection phases. As I mentioned, all based around reducing scan time, but built for developers. Developers, you know, you’re releasing code at breakneck speeds. It’s all about CI/CD, it’s all about automation, it’s all about speed. And we really want to make our scanner run as fast as possible to remove that lengthy time wasting with scans that just run for far too long, which is why they’ve historically been carried out by security. And in pre-prod or staging, for example. So we can run all the tests, skip certain parameters, static parameters that aren’t going to have an effect on the scan, all about maximizing the speed there. Thank you, Akira. And yeah, you can change the specific paths if you just scroll down a little bit, Akira.

00:56:13

Speaker 1: Come on.

00:56:15

Speaker 2: Yeah. So you can choose which parse you want. You can choose all of them. Some of them. We just wanted to run quick header scans, for example. Then you have that option. If you just click on the network tab as well, please. Network tab. So you can also change the number of concurrent requests. And obviously this is going to affect scan time as well. So it defaults to ten. But if you think you can take it or the application has the bandwidth, then you can run up to 50 or indeed you can have it up to 1000 concurrent requests. Against the application, this is like the number of threads, the number of attack payloads that we’re going to be running, running against your target application. This will determine the speed at which your scan will complete as well. So just bear it in mind. Obviously, you guys can have a play around with this. So, yeah, any questions. Go to our docs docs.brightsec.com and I’m going to put it into the chat now as well just so that you, you have those as well. It really aims to be as self service as possible so any questions feel free to look out at that as well. Um, okay. And then let’s look at the tests. We might as well show people the tests. Yeah. No, no. Just go to tests on the left. That’s the one. So you can see here the sort of common vulnerability test that we cover. You can see there, learn more about our test. That will take you to the guide with a full list of our vulnerability testing categories that we cover. But we really do have a large coverage here. We know that via internal benchmarks, even when comparing us to some of the aforementioned DAST scanners that someone mentioned we really do have you covered. We’re really about enabling you to rely much less on manual security testing. And if you scroll down as well, Akira to the business logic part of it, this is what I mentioned before. This is where our engine leverages the natural language processing and the very active way that we run scans against the target, interacting with it like a human, using our headless browser technology to interact with certain parts of the application, understanding the responses we’re getting back and being able to use those responses to then carry out a chained attacks against the target gives us the ability of carrying out business logic, vulnerability tests. So trying to break that logic, the validation mechanisms of the target, as I mentioned, yes, they are fairly limited at the moment. We will soon be releasing a number of different other business logic tests, testing scenarios and categories, but it’s really about trying to find as much as we can, as early, as often as we can as well. And business logic vulnerability tests have only been carried out by manual security testing. And really what we’re trying to do here is to try and minimize your reliance on manual penetration tests, manual tests by the security team, whether they’re done daily, monthly or in most cases, yearly. This all goes back to automation, being secure by design, and ensuring that security testing can keep up with your rapid release cycles. And the more that we can find as early as possible, the better. So we’re really, really spearheading the efforts in being able to carry out business logic vulnerability tests in an automated way that’s going to enable developers to own that, to own that process. And we also have if you just scroll down a bit more Akira, the third party test, which includes your JavaScript vulnerabilities, that just ensures that you’re up to date and patched accordingly. So let’s just take a bit of time to have a look at the questions here. Right. Will we have access to a recorded webinar later? Yes. I didn’t know people manipulate the scanning. Well, yeah, absolutely. Other DAST tools, of course, can be manipulated. Of course, we have multiple different settings with regexes and amongst other things, different authentication mechanisms as well. But really it’s, it can be a very complicated process, particularly by the way, a lot of the configuration is carried out to ensure that the results and the output you’re getting are going to be actionable, i.e. how can we try and remove false positives? This is automatically carried out by our engine. So every result that we have is validated automatically by our engine. So we do not have false positives. If you do have a false positive, that for us is a bug, we are also a technology. We all have bugs. But that for us is a bug. So, you know, we’ve really, really pride ourselves on this. And we have case study after case study of the amount of time that we’re saving developers in the manual validation, the amount of time that people are investing in manually validating is astronomical. But worse than that, they’re not manually validating it because they’ve got too many. You could run a scan against an application and have 50, 60, 70% false positives and the rest, it’s just not scalable. And in the world of CI/CD and DevOps, you need application security testing that’s going to be scalable. And one of the biggest pain points and blockers is that manual validation. So rest assured that you won’t have that issue with Bright. Yasar, I had to go. Yes,it will be recorded. That was 10 minutes ago. So you are seeing this on the recording. Yasar, hello again. And let’s see here. Rasha likes the advanced use cases. This is awesome. Thank you very much. Currently jump between multiple tools to validate API scan coverage. Great Kenya. You know, this is really why we’ve built and built the API schema editor as part of our technology. We know that the API schema needs to be validated. Don’t start jumping between one and the other. We’ve in-built it. It’s an API linter to enable you to do that, so please do take advantage of that. And we actually have other clients that just upload the schema or the swagger  documentation and just just use it for the limiter to see where they’re where they’re going. So you’ve got multiple use cases there to use it. James, yes, we support Postman. That is awesome, I completely agree with you, so please do take advantage of that. Everyone asking if this will be recorded, which is great. And of course you can share this with your colleagues, share this with your teams, let them use it, use the docs, docs.brightsec.com as a self service module as well to go a bit deeper. And I would stress all of you, we’re just scratching the surface now on the capabilities. As Akira mentioned in her opening comments, this is really supposed to be used as part of your CI/CD. Look out for another workshop that we have in about a month’s time where we’re going to show you how to integrate this into your CI/CD using GitHub actions. This is like an introductory one that you can use now using the UI. If you want to get ahead of that, you want to start implementing it now. And I wouldn’t blame you for wanting to do that. Go on to our docs, look at the CI integrations, we have step by step guidance on how to integrate it with example configuration files so that you can really be up and scanning within minutes. James Again, looks like the API schema would be perfect. I agree, but you’d expect me to agree with that. Okay, and I think we’ve caught up with the questions. I know there is one new message. Let me see, a third party test is that MPM packages? That’s JavaScript. JavaScript libraries and vulnerabilities to ensure that you’re fully patched there. We do have something in a Q&A. Abijeet, can I sign up for a free account with another email? I have problems with sign up. Yes you can. No problem. No problem at all. You still need both. Oh I see Akira has been answering questions. My apologies. I wasn’t looking at Q&A, so. Thank you, Akira. I believe you still need both SAST and DAST. Well, look, SAST is a very, very good, useful tool. And I don’t think anyone should say that you shouldn’t use it. Ultimately, you will always need to run a DAST scan because you always need to do some form of penetration test. As I mentioned before, static analysis is very good, but it’s fraught with false positives, particularly when looking at modern technologies, single page applications, microservices based architecture. You need to really try and understand how the application would perform in the wild, and you don’t have that capability with a static analysis. I would never say don’t use SAST, but based on feedback, SCA, SAST and DAST will have you covered. SCA and DAST will also have you covered. But categorically you should be using static analysis too, because it’s all part of the security testing stack that you should be deploying. Repeaters running on machine, is this what I use to run against intranet sites? Yes, absolutely. Akira answered that, sorry if I’m going over this again, but perhaps for those of you that aren’t monitoring the Q&A, it’s useful to use. The repeater can be used to test internal applications. Right. So perhaps in a dev environment that might not be open to the public, you can use the repeater as a proxy and we have some architectural or solution architect drawings to show you how you can lock down the repeater for it to be safe and then to start scanning internal applications or other environments within that. Okay. And yeah, I think that’s all the questions so far. So, Akira. I think without further ado. One thing we need to do is refresh our screen so that we can look at what vulnerabilities have been found. So for those of you that are were stuck on that pending stage, you can see that it’s still running and we can now start looking at the results. So we can click on that. We can see here the number of requests, related requests, etc.. We have details of the in fact, Akira you can go through this.

01:07:20

Speaker 1: Yeah. Yeah, absolutely. So first off, really briefly, I do want to talk prevention since we have a couple of minutes and then we’ll go through the results together. Does that sound like a plan? Cool. Good. I’ll say yes. Okay. So here’s what I want to talk a little bit about is, of course, an ounce of prevention is worth a pound of cure. So let’s just really briefly go over a few things that can help you write more secure code from jump, from the get go so that maybe when you’re running these DAST scans, you don’t have as many issues. So, number one, we’re going to talk about input validation, we’re going to talk about output encoding and we’ll briefly touch on authentication and authorization. These are just some top three things that you can do. There is a coding course that is fantastic that we now offer for free through We Hack Purple, which is called Secure Coding Course. It has a 17 Commandments of secure coding. We’re only going to go through three of those 17 today just for time sake, but I definitely recommend you check out this course. You can find it at wehackpurple.com. I will put that in the chat a little bit later. Maybe, Oli, you can put it in the chat really briefly. The course is free as of today. It used to be paid, but it is now free. It’s fantastic. Really great way to learn more about secure coding and how to do it from the get go. First off, input validation. So, brief story about this. A colleague of mine once had an input validation issue. She had a blind SQL injection in her application and she didn’t know about it. The way she found out is Vice Magazine sent her an email and asked her if she would give a quote about how the data of her organization was on sale for the Dark Web for 50 bucks. And that’s how she found out that she had a blind SQL injection in her app, which is a problem because of input validation. So she actually got in more trouble because she made a joke about, Oh, is our data really only worth 50 bucks? to her boss. Then she actually got in trouble for the problem itself. Input validation is the most important thing. The reason is, where else do attacks come in? They come in via input, right? If people validated their inputs properly, 80 to 90% of attacks would disappear. So on that note, validate all types of input to your application. Human or machine. This can include database queries. It can include your L parameters, it can include body parameters. Anything that goes into your app, you need to validate it. You can reduce, reduce or eliminate risk from so many injection attacks just with input validation. A couple other things on this note. Server side validation is mandatory. Use and allow list, not a block list. So that essentially means have resources that are allowed and only those resources are allowed. Don’t just block out a few things that are problematic, only use and allow lists. It’s sometimes also called a whitelist versus a blacklist. Lots and lots of frameworks have this built in now, so use this provided by your framework and always check, is this input okay. Input validation alone can never prevent all attacks, but it can reduce the attack surface and minimize the impact of any attacks that do succeed beyond security implications. Data validation is also crucial for software performance, stability and usability, so this will actually make your code far more, far better. All right. We’re going to do a quick quiz. I know you all were looking forward to a quiz. So here we go. Which one of these the left side or the right side has input validation? Which one should we use? The one on the left or the one on the right? Oh, wait a couple of seconds in the chat. All right. Yeah, it’s the one on the right. Right. Because as you can see here on the left, there’s absolutely no input validation at all. And on the right there is input validation. And you can also see here that the code itself is not that much more complicated. It’s not too hard to use input validation and to implement that. So always, always, always validate your inputs. Similar kind of layer two of defense after you’ve validated all your inputs is encoding all of your outputs. So what does that mean? So essentially what from the OAuth definition, which is an organization internationally for cybersecurity, they define output encoding as involving translating special characters into some different but equivalent form that is no longer dangerous to the target interpreter. For example, you would potentially translate the sideways carrot character like this, like the less than character into an ampersand LT when writing to an HTML page. Essentially what happens here is that it makes these special characters occur to a server as data, not as code to be executed. Anything that reflects back onto your screen must have output  encoding. Does anybody have an example of output encoding that you have seen at your work that you can put in a chat? If so, please go ahead and do that. One other thing I do want to say that without output coding, someone can write essentially JavaScript and put it in your input. And if your input and if your input validation fails, they can run all kinds of wonky code on your server. They can destroy your server, they can steal data, they can corrupt files, you name it. So always use output encoding. Again, there are frameworks that deal with this or sorry, there are tools inside of frameworks that deal with this. It’s a good layer of defense if you use input encoding, excuse me, input validation and output encoding, you are in a really, really good place as far as writing more secure code. Lastly, I want to talk about authentication authorization. So authentication authorization is an interesting topic. Essentially what it is, is asking who are you? Are you the real you? And are you even supposed to be here? And what are you allowed to do? One thing that I want to mention on this, and I used to work at an auth shop and this was really important for us to get across is that you should never write your own authentication. The reason being is that it is so hard to write. It is incredibly expensive. It takes a lot of manpower to maintain and a lot of people what they’ll do is they’ll just salt and hash their passwords, put them in the database and call it done. That is definitely not enough. Here’s a story about why it’s not enough. So, for example, once upon a time in cybersecurity land, there was a breach of a company and they stole a bunch of emails and they stole a bunch of passwords. Now, that would be bad enough if they wanted to just log in to that company’s resources and take information from that company. However, the truth of it is, is that most people use the same email and password combination all over the Internet. So what they did is they cross-referenced these email password combinations with things like banks and they stole $20 Million overnight. So that is just with the sets of credentials that they cross referenced. And it wasn’t initially from a bank. They didn’t breach a bank, but they use those credentials to log into banks and steal money. So authentication authorization is a really, really big deal. Don’t write your own auth, use a third party provider. Okay. Now we’re going to get into discussing the scan results. So what I’m going to do is I have actually finished a scan earlier that we’re going to go over today. While all of your scans, of course, are still running, let me go ahead and log into my account here. I will pull it over to the screen in just a second. And we’re going to go over some of the most common issues that people have in their scans, and a lot of these are on the OWASP top ten. So let’s go ahead and pull this over. All right. Let’s see here. Scans. Okay. I’m not going to show you the scans that I initially had on my personal website because it was super embarrassing and I went and fixed all of them. But you can also, I do want to mention that if you have written permission from a person who is allowed to give you that permission, you can scan a website. So if you have your own personal website, a really fun activity is to go scan your own site and realize, Oh my God, I have so many security vulnerabilities. I didn’t even know about. Rashah, I used to work for FusionAuth. Full disclosure, I think they’re fantastic. I would recommend them, but Auth0 is great. There’s a bunch of other fantastic things on the market right now. So let’s go over these scan results. The first thing I want to go over is reflective cross-site scripting. This is a big one. If you have heard of cross-site scripting, can you just put like, raise your hand or put like yes in the chat? I’m sure you have. What I do want to say about this from the get go is yes, yes, it’s very, very, very popular. It happens a lot. Input validation would have blocked this, output encoding would have been a second layer of defense. It is super important to validate your inputs if you take nothing else away from today. Of course, it says secure coding is worth your time. But secondly, validate your inputs. Okay. Something else that you can use to deal with this is a content security policy header. We will deal with this in just a moment. So I will show you here. We’re going to go to issues. And right here you can see bam, high severity, reflective cross site scripting. We’re going to scroll down. This, for example, is one of the URLs that we found it on. We’re going to expand that. And here you can see details, where it was, you can see remedy suggestions of how to fix it, possible exposure. You can learn more about it here. Also, one thing that I think is cool is that it actually shows you the URL of where they found this issue, which is really good for when you’re troubleshooting it and where you’re fixing it. Let’s go down here. Here’s the body of the Web page it was found. And then one other thing that we give you, which is really helpful is actually a screenshot of what that cross site scripting attack did or whatever the attack was that you choose. You can see some evidence that it happened. So in this case, it just made a little pop up. Come up, right? Not a big deal. Yeah, well, actually, reflection cross-site scripting is a really big deal. What happens in cross-site scripting is that an attacker’s JavaScript runs in your browser against you and your computer. So let’s talk a little bit about what they can do. They can download a keylogger and watch everything that you do. They can turn on your webcam and sell stuff that they capture on the webcam to people on the Internet. They can turn on people’s mics and listen to you. They can install malware on your machine. That malware can spread to other machines and they can also do ransomware. Cross-Site scripting has all the power of JavaScript, which is very, very popular. Very, very, very. It’s a big deal. We’ll just say it that way. What I want to say is that we’re not in pop up box territory anymore. They can do, also things like command and control. They can control your computer from afar. It’s really, really, really messy. So how do we fix it? Okay, Input validation, big one. Input validation would have blocked cross-site scripting and output encoding would have been a second layer of defense. You can also add what’s called a content security policy header, which essentially lists all the resources that are allowed for your website to go to. Do not set it to star. And what I mean by star, I’ll put in the chat, essentially do not say that you can allow any and all kinds of input come in in any and all kinds of input come out if you have any experience with cross-site scripting or honestly any of these things we talk about, please feel free to share them in the chat. Would love to hear some horror stories. Let’s see here. Let’s pause really quick before we go to the next issue and answer some questions. Is there any way to quickly check if you fixed an issue or do you have to re-scan the entire website. So you can do smaller scans. And I think Oli, you can, like you showed earlier, right. You can just select the one type of thing that you want to scan.

01:20:25

Speaker 2: So yeah. So actually if you go back to the UI.

01:20:28

Speaker 1: Yeah. Let’s see here.

01:20:31

Speaker 2: So now you’ve got that click on that reflective cross-site scripting one at the top. No, no. Go down to issues. There you go. Click on that one. Any one of those?

01:20:40

Speaker 1: Yeah. Like that?

01:20:43

Speaker 2: Yeah. And what you’ll see is the little pencil mark at the top.

01:20:50

Speaker 1: Mmhm.

01:20:51

Speaker 2: Modify scripts. And what you have the ability here is if you wanted to, you could amend the request with a re-request If you wanted to try and manipulate that, then it also enables you to, if you scroll down. It’s at the bottom, I think. Execute. So you can actually execute the specific payload and sort of see what comes up. So that’s a good way of being able to understand where your vulnerabilities are. And actually, one thing we haven’t covered, if you just click on projects on the left, on the left nav bar, what you have here is, so click on everyone. So that’s the group. So what you also have here is a project view. So just zoom out a little bit. It’s a bit zoomed in, but what this will give you and is maybe a bit more to zoom out once more. What this will also give you, by the way, is an understanding of once you’ve run multiple scans. Now this is showing as recurring, recurring. I don’t know if we’ve run two tests, but we can see which of your issues are new, which are recurring. You can mark them as resolved, you can ignore them or whatever it might be. The really, really good way of you being able to understand, okay, where are my new issues? Have I seen this specific issue before is another really good way of doing it. But once remediation has been attempted to use the crawler for example, and it’s the same URL, then yeah, it can just sort of just replay that attack against that specific entry point. And it’s a good way of just understanding okay, Well, is this the same issue that we found before? And, you know, we talk about developers leading the charge with security testing actually for security training awareness. It’s great to understand, like, let’s say we have this team, this squad, whatever it might be assigned to a specific application, a specific API, a part of an application. Actually, what we want to be able to do is almost have it like a benchmark. So this team got a problem with cross-site scripting, with SQL injection or whatever. So you get if you’re an engineering manager, you can get global visibility of that and then actually you’ll know where to apply specific training, whether that’s via a third party, whether that’s via We Hack Purple, where you can go online and look at courses maybe specific to certain vulnerabilities. And if you have any ideas or thoughts about that, then please do reach out to us and as the sponsor of the We Hack Purple community and courses which we want to offer for life for free, let us know how can we improve that? What’s going to be of interest to you? And we can start building some courses around that for you with pleasure, because we want to enable you to be able to give you everything you need to be as successful as possible. And that’s not just using all of our DAST scanner, by the way. It goes further and beyond that, with education, with courses to really, really try and help you to get security testing done properly and automated. So you do use this as well just to have a look and see where your issues are. So I hope that answered the question. Rasha says, Awesome. Yes, I agree. Okay. Okay, That’s it for the question so far. So thanks Akira. 

01:24:30

Speaker 1: Yeah. Okay. Let’s go on to another issue. We’ll go back here to scans. And let’s see, here we go here to issues, and we’re going to find unauthorized cross-site request forgery. This is down here. Here we go. Bam. Again, you can see here, all the places it happens. We can expand it to get some details about what CSRF, It’s called CSRF, cross-site request forgery, so CSRF for short. Where it happens, some remedy suggestions, maybe what might have happened to have it be a problem in the first place. The URL, where it happens. And in this case there isn’t a picture to prove it. But since we have no false positives, you can be assured that this actually is an issue. So let’s talk a little bit about CSRF. So what it is and why it’s scary and how to fix it. So would input validation help this? Why yes. Yes, it would. However, the defenses are not necessarily input validation. The defenses are passing a CSRF token. But so what I guess I’ll say to that is that input validation would help. But the main defense is passing a CSRF token. So why is CSRF scary? Well, let me say it this way. CSRF attacks are client side attacks that can be used to redirect users to a malicious website, steal the sensitive information from them, or execute actions while using a user session token or a user session cookie. It’s a big deal. It used to be on the OWASP top ten. Now it’s number 13. The reason it’s number 13 is because frameworks came in and started fixing CSRF. But at the end of the day, what happens is that a user is tricked into sending a forged request to a server along with the credentials of an already authenticated app. So if you have a banking app that’s already authenticated and you’re tricked into sending those authentication credentials to a bogus server, that’s a big deal. Now they have all your auth information. So how do we fix it? There’s an order of operations. There are three things that you can really do. You can do number one, pass an anti CSRF token. This is the best way to deal with CSRF. Number two, you can use a CAPTCHA any time you are doing a transaction that’s a little bit more cumbersome. Users don’t really like CAPTCHAs. And then number three, which works but it’s the most cumbersome for users is you could ask them to re-enter their password. At that point you’re going to risk users just abandoning your site because they don’t want to re-enter their password. Okay, let’s stop for a moment for questions. Looks like Oli is doing a great time.

01:27:18

Speaker 2: One thing I’d also say, by the way, just in response to Abhijit’s answer, of course, feel free to reach out to Akira. But actually if you’re looking for support questions as well, you can email support@brightsec.com. Go to our Discord server. By the way, our support engineers monitor that for questions. We really want to ensure that that community is being used. If there are any issues, feel free to reach out to us there. You’ll also realize, by the way, that at the bottom left hand corner of the UI, we also have an online chat facility. This gives you direct access to our support engineers. They may come back to you immediately as they do in many cases, or it might take time. But either way, we’re here to support you. We’re here to guide you. We want you to succeed. So please do, please do take advantage of that. And we can and we can come back to you and. Yeah, I don’t think there are any other questions. Thank you Akira. 

01:28:19

Speaker 1: All right, let’s go over one more issue. And this issue is called open bucket. So if you have an idea of what that might mean, please feel free to put that in the chat. But what would an open bucket mean? Well, let’s expand it here. Here it is right here in high severity. Okay. So an open bucket essentially is when someone’s S3, so Amazon S3 buckets are open and people can see anything that is inside of them. Long story short, I don’t want all my photos or API keys or resources on my or my users S3 buckets to be available to everybody. And I’m quite sure that you probably don’t don’t either. So how do we fix it? First off, you can make templates for your organization. You can use secure defaults when you configure your S3 buckets. And last but not least, scan your apps, scan your app often, scan your app early with Bright or similar a DAST and it will find it. One cool thing I want to show you here that I, I get a kick out of is, let’s see, is this the right? No, this is not the right…this is not the right tab. I’ve got too many tabs open. Okay, here we go. What we will do is we can actually show you what we found in your bucket. So in this case, we have an awesome photo of an airplane in the woods. We found that picture in your open bucket. We found this picture in your open bucket, which is how I would feel if I had my buckets open. I’d feel very silly, like a cow stuck in a tree. And then last but not least, we have a picture of an elephant. So that’s all pretty PG But sometimes people’s pictures are not necessarily this benign. Also, people can store API keys and whatnot in these buckets, and that’s a problem because then you can have these web crawlers that go through, look for these, look for these open buckets, and now they have all your API keys. So it’s a big deal.

01:30:22

Speaker 2: And there have been some very high prominent breaches with that specific issue. It’s a really easy one to forget or to miss, one that obviously we cover, but one that can be so damaging to your organization that yeah certainly one that’s that you don’t want to miss out. So we’ve put a bit of a funny spin to it but I think as Akira mentioned, the ramifications of that can be really quite severe.

01:30:55

Speaker 1: And that’s something else to just underline again is that this is not a security vulnerability that most people think of, right? They think of cross-site scripting, they think of CSRF. But not many people think about open buckets. Right. Which is why I include it on this list, which is also why we rate it as a high severity issue as well. That’s it for the results that we’re going to go over. As you can see, there are many, many more. They have information on all of them. You can click on the like open issue section and expand them into seeing more about the issue. Let me show you how to do that one more time. So you go to issues maybe you want to learn about, oh, I don’t know, directory listing. You’re going to push down. You can open here with the box with the arrow in it and open it up in a new tab and it’ll teach you more about the issue itself. We’re also working on some video tutorials, like very, very short videos about each issue, and that will be released hopefully in the near future. So that will also be just some more information for you to learn more about the issue and how to fix it. So that’s all for the issues.

01:32:04

Speaker 2: Quickly Akira, Mike’s got a question about the open bucket case. And to what extent could Bright take action against those accounts that misuse the platform? So Mike, that’s really, were preventing you from getting to that point. The whole point of this is that you want to find it before the case so that actually you don’t need to take any action against those accounts. And just to confirm we’re a dynamic application security scanner we’re there to detect it, what, what happens once it’s been exploited by a malicious actor, You know, your executive team will be dealing with, I’m sure. But the whole purpose of this is that you don’t want to be in a position where your executive team is dealing with security vulnerabilities and bugs because they’ve been exploited. Find them early. Running this DAST scanner on your applications. That’s, by the way, just to make everyone clear, because I don’t think we mentioned it before. Our scanner is safe to use on production, on production sites. So you can run this against your own applications. You’ll have to do it through the repeater so that it’s an authorized target to find and see what security vulnerabilities do you have now. The whole purpose and premise of this is, as we’ve mentioned before, is putting security testing into your development pipelines, ideally finding this way before way before they hit production. That really is the key. You don’t want to be worrying about what should we do once it’s happened, Nip it in the bud and make sure it doesn’t happen.

01:33:45

Speaker 1: Totally. Yeah, that’s like I said, the intention of teaching you this tool is to empower you to shift security left. So scan early, scan often, find these problems before you send it to QA. Go ahead and fix these problems before you send it to QA. And your code quality will go through the roof. Like secure code is more is more quality code every time. On that note. You are not a hacker now. Sorry. So web app scanners like Bright or like SAST tools or anything like that are not foolproof. Like all point and click software, it can miss things. So the point of this exercise is to catch all the obvious security flaws and to train you to search for security flaws from the get go. Other security activities within your SDLC will make your app even more secure. So whether that’s like an AppSec program at your company, whether you’re also using a SAST tool or a different kind of security tool, maybe you’re hiring a pentester. Other security activities will obviously make your app even more secure. Please do not learn what you used for evil. The thing is, if we can point a scanner against a web app and find all the security vulnerabilities, so can malicious actors. They can use similar tools to find security vulnerabilities in your code. So please, please, please do not take our tool or any other tool for that matter, and start messing with people’s stuff. And actually, please do fix the bugs that you find. That would be fantastic. And then you’ll become a more secure coder. Okay. I want to leave you with some resources. So, the first resource to leave you with is me. You can email me. You can find me on Twitter at theakirati, which is like the Illuminati, but it’s theakirati. All right. Anyway, I’m too corny for my own good. You can also use courses from We Hack Purple. It is a cybersecurity community as well as education platform. There are a ton of community members. They talk all things cybersecurity. They are InfoSec people, they are software engineers, they are students, they are CISOs. There are all kinds of people, and the whole point of them is to talk software security. They have webinars, they have YouTube videos. Like I said, they have a whole academy that is now free. As of today, it is all free, which is fantastic. Really, really great resource. Our blog is fantastic. If you go to brightsec.com/blog, we have a ton of amazing resources and a lot of really good articles on things like CSRF, on things like secure coding, on things like, Oh, I just found this weird vulnerability and I don’t know what it means, how do I fix it? Fantastic blog, Lots of good resources there. The secure coding course that I mentioned earlier from We Hack purple which is wehackpurple.com. You can use that, you can take that course. There are the 17 Commandments for secure coding that are talked about in depth in that course are fantastic. And also there is a fantastic book that my coworker Tanya Janca wrote called Alice and Bob Learn Application Security. It’s all about secure coding. It goes super in depth. It will teach you how to write secure code. And on that note, we’re actually giving away a free copy of it. It’s a free e-book. What you have to do to try to win this book is go to Twitter.com/brightappsec and answer this question. So the question is this: In regards to secure coding, what small action can you take right now in your own work without needing any further resources or authority? So go to Twitter.com/brightappsec It’s going to be the pinned tweet and reply to that tweet with your answer. We’ll pick the best answer in the next couple of days. We’ll DM you on Twitter and say, Hey, you won, and then we’ll get your email address and you can win a free copy of that book. So I’m going to go ahead and Oli, can you actually put the Twitter link in the chat for people?

01:38:01

Speaker 2: Yeah. And just before I do that, Argie had put something in the chat, for those of you that want to read it. But he raised a very good point. So interesting to learn how you can scan set the scan result as a quality gate in the CI/CD where the when the devs can’t merge unless there are no medium or high vulnerabilities whilst also having a mechanism that can allow the merge to proceed when exception approval has been secured e.g. medium level will be fixed in a later date. Absolutely. This can absolutely be carried out if you do look on the the docs by the way. So there’ll be an example with GitHub actions. I’ve done previous talks and workshops on this very, very topic where even we showcase that to you. So if you want to have a look at that, please do. We will also have another workshop in about a month which will be showcasing how you can integrate the Bright security scanner as part of your pipeline. But this can all be configured via your .YAML configuration files so you can set the breakpoints, You can set what happens after the breakpoints so the build will fail on medium, fail on high, but be okay or you can set it to still merge on that but also be notified and then the configuration is all there configured via code. And we have a full command list on our docs docs.brightsec.com so it’s all there for you. Argie, absolutely you can, we have examples of that as well. To fail builds accordingly. And just to reiterate, we automatically validate every finding, and I know I sound like a broken record, but it really, really is important. A lot of people tend not to add any breakpoints etc. because how can you possibly add a breakpoint when 80% of your findings are going to be false positives? Actually, now you have the ability to do that with automatically validated results. So, you know, categorically, if there’s a medium or high severity vulnerability that’s been detected by our engine, it is there. It needs to be actioned now or you will be pushing into production with a medium or high severity issue. So really, really useful tool, absolutely, you can integrate it into the CI. And absolutely you should. And please feel free to look at our docs docs.brightsec.com, also go to the resources page on our website and you’ll see that there will be other video recordings that you can also follow even now on on how to do that, where I take you through the step to step process of that. John, this was truly great. Thank you so much. And Akira really did do a fantastic job, even in the light of some of the technical issues that we had, hoping I’ll be able to integrate this very soon. John, not even hoping you have to do it. It’s really, really easy. It’s really, really simple. We’ve given you, we haven’t given you a fish. We’ve given you a net so that you can continue to catch multiple fishes, i.e. vulnerabilities moving forward. And yes, it should be integrated into your pipeline as Argie mentioned before and. Jan says great stuff. Thank you very much. Okay. I’m going to leave it to you Akira.

01:41:31

Speaker 1: I just wanted to finish up by saying thank you all so much for being here. Thank you for your time. Thank you for your attention. I hope you got some really valuable information that you can start applying immediately in your own coding journey. Yeah. So just wanted to say thank you and thanks to Oli for co-presenting and we will see you next time. That concludes our webinar today. Thank you so much.

01:42:00

Speaker 2: Yeah, thank you very much everyone.

01:42:01

Speaker 1: Yeah.

01:42:03

Speaker 2: And happy hacking your own app. Your own app. 

01:42:12

Speaker 1: Thank you, everybody. Thank you.

01:42:13

Speaker 2: Thanks, everyone.