Hi, I'm sure you've seen the introductory video already, but I'm Francesco. I'm 15. I'm a student pen tester, student web developer, and today I just wanted to generally go through the importance of integrating security measures throughout development. Now I'll be going through some well known security vulnerabilities, primarily in web development, and I'll also just really quickly demonstrate them in Kali. So to start off with, I just wanted to talk about input sanitization and specifically xss. I'm also going to be talking about SQL, but for now I just wanted to talk about cross site scripting and how we can exploit these unsanitized input fields, whether it's with reflected XSS, stored xss, or any other type of xss. So to understand how XSS can lead to compromised accounts, I'm just showing you a really quick snippet of some code that should be vulnerable, even though it's probably not. But I'm going to show it anyway just to kind of understand how these logic works behind XSS. So to give a little bit of context, what this code is meant to do, or the general model of this website is to just store comments that users can post. And here we can actually see the user comment variable which I now filled in with just some HTML saying hi just as a proof of concept. And I've also created a function to handle the request which takes in a URL and an input. And here we can see that we're making a post request to these designated URL passing in the input and to call the function we're just giving it a locally hosted API route that leads to comments and giving in the user comment. And if these input truly is not sanitized in the front end or the backend, then as a response these text high will be displayed on the user's page. And moving on from the code here we can see a really quick flow diagram which actually displays a malicious payload as opposed to the high in HTML. And what this payload actually does is it tries to render an image which we know it definitely won't because the source is given as x, which is just invalid. So it will inevitably call this on error function, which in turn makes a request to the attacker's ip, giving the attacker the cookies of whoever views the web page. Now obviously for this to work, the attacker would have to have a web server hosted, but this is just to generally show how it would work. Now, to test XSS on a vulnerable website, I've loaded up owasp zoo shop which basically is just a training tool for hackers. And here we can see that we have a search bar. And since we know that this input is not sanitized, we could try run something like a h one tag saying hi like we showed in the code and just closing it and it should return high. Now we know it's vulnerable to XSS because it actually displayed high. But if we wanted to just test a range, we could try to test a h two, which makes it smaller, or a h four even makes it even smaller. Or if we wanted we could just do a p tag right here and it got bigger. But you get the point. Now another thing you could do is you could test if the website will run JavaScript, which you could just test by doing script and typing like Cert and giving it something. But I'm not going to do that because in this case it doesn't work. Now going back to the presentation, this really shows us that we really need to make sure that all of our inputs are sanitized. And to further show the extent of the damages that an unsanitized input could cause, I'm going to show how these can lead to SEO, which the general concept is the same. They're both based off an unsanitized input and injecting something in that input field. In this case, the only thing is that we're going to inject an SQL query, whether it's a union select or whether it's just a dump. The users, there's a lot more you can do with SQL in my opinion, than you can with XSS. And here I just displayed an example that you could use if this password field was indeed vulnerable. And for this to work over here, we need to make sure that the email is actually correct in the database and it actually exists. Otherwise we need to flip these parameters and we need to hope that the email field is also injections. And to show how this would look like on the code base, we could just see that it's actually selecting all from users, where email equals this and password equals or one equals one and comment the rest of the code. Now we need this quotation mark here at the start because it actually closes the password variable, allowing us to actually put SQL statements after it. Now once again we're back on the OASP gshop. And just to test that same thing, and just to test that it works, you can try the same thing on the login maybe whatever at Gmail, whatever. And password or one equals one comment. Now I dont think this will actually work for now. Yeah. Invalid email or password because this is not a valid email. But if we don't know the email, we could always just try to put that statement here or one equals one comment, the rest of the code and literally whatever over here. And if we log in, we have admin at juice shop. Now. Just signing into someone's account is really the least you could do with an SQL injection vulnerability. If you really wanted to, you could go on SQL map and fully dump the database contents, which actually I might show if we go here on this DVWA. Go on SQL injection. I might need to load. Okay, so I have burp suite loaded. I'll just intercept the traffic here and user id one or whatever. Yeah. So here's a request. So I might actually use this request to put this into SQL map. I'm just going to copy the cookie that we need right here and bring it over here so we could do SQL map, tacu the link. And I've already done this, so just add in the cookie just in case it changed. It didn't for some reason. But yeah, we're just going to enumerate these database like this and we can see that we have DBWA and information schema. And if we wanted to, we can just select the DVWA and then enumerate the tables. We have guest book and users. We just go for users, users. And I didn't dump it columns and say we wanted the password or user id or anything. We could just go here and then select which column we want. In this case password dump. Since I've already done this, we have everything here. And then we actually have the MD five hash which you could just try crack. I'm sure it's probably going to be some simple hashes to crack because it's a vulnerable website. But yeah, this really shows the extent of SQL injections and how they can really damage your business. Now moving on from SQL injections, I just wanted to talk about broken authentication, which in my opinion is not as bad as SQL injections, but it still can cause a lot of damage and it's just a bad look to have any of these vulnerabilities anyway. Now with broken authentication, there's actually several types of it. For example, there's insecure cookies, which is what we're going to talk about. Now. There's unsafe password policy, which is when you allow your user to pick whatever password he or she wants, even if it's just like a three character password, which can be easily crackable. Now on the more serious side of broken authentication, there's also no request restrictions, which is probably one of the worst ones because it lets any user make a limited amount of requests to these login or sign up field for example, which just allows them to brute force these password of any users they want and they can just leave it running. Now you can easily change the amount of requests that you want a user to make per hour, for example on the back end. So that should really just be a quick fix. And moving on to unhashed passwords, this is also pretty serious because if you're storing user passwords in plain text in the database, say in your MySQL database or your MongoDB database, because by doing so you can allow the effects of any other vulnerabilities such as SQL injection to be way worse. Because now if someone can perform an SQL injection on your website and instead of receiving passed MD five passwords, they just receive plain text passwords, then the purpose of making a really complicated and hard to crack password just gets defeated. Now even with this broken authentication, it should be really simple to just encrypt users passwords. For example, you can use bcryptjs if you're using a node JS backend to easily encrypt these passwords and that should at least increase your security by a bit. So yeah, all of these types of broken authentication, they all have their respective solution down here. But moving on to the insecure cookie type of broken authentication, we can see here that we have a cookie called privilege with a value of user. Now the reason as to why this isn't optimal is because anyone can just change the value of the cookies as something really predictable, say admin for example, which if you're having this type of cookie structure, then you probably have a value for admin that might lead to a dashboard, for example. Now the point is that you should just not have insecure cookies like this and instead just make unique cookies to anyone that visits the website, say with JWT cookies, or just anything that's encrypted and unique for each user so that an attacker can't just guess another user's cookie. Now carrying on, I also wanted to mention directory exploits and specifically local file inclusion vulnerabilities because these are really simple to exploit and cause basically anyone can dump the contents of the Linux machine hosting the web server. Now here I've just included the most common example of vulnerable PHP code, which basically just takes in any directory from the user and displays its contents. Now to showcase how we can exploit it, I just took a screenshot of a random domain which just shows the vulnerable parameter lang where we can replace en, where presumably it's for language, but basically we can just replace en with any directory and basically we can just use path traversal to escape the directory that we're currently in and to get to for example Etsy shadow or Etsy password and once again to exploit it. I'm just going to go back to this DVWA find file inclusion and I need to turn off intercept on burp suite. Yes, and I need to also turn it off here. And yeah, here we have just an example of the vulnerable parameter, which in this case is page. And if we just type for example here to just escape the directory Etsy password. These are the contents of the root user and if you wanted to crack it you should go to Etsy shadow. And I dont know why nothing loads here, but usually to crack it you need to unshadow the contents of the password and shadow and then you can crack the hash that way. And also aside from just displaying shadow or password, one thing that you could do is in here you could just put the link to your local server hosting a reverse shell and then that turns into RFI where you actually get a remote shell on the website. So this should really show that you should really be careful when you write code. And if you're not sure about something just comment it out and leave it for later or at least before pushing the branch, get a pen test done on it. There's many ways that you can just check that your website is relatively secure before you actually push it, which I'm actually going to talk about later on. So yeah, like I said, we're going to be going over some prevention methods and what we can do to generally make our website secure. But it's not just websites, this can also be relevant to your servers or whatever you want to keep secure. So one thing that I actually found useful was listening to your package manager. Now the first two screenshots are actually react and anytime you do NPMI or NPM install to install any new package basically just highlights anything it wants you to take a look at, which most of the time it's probably nothing important, but the times that it can be something serious, it might be worth taking a look at it and checking with your senior developer. Now about checking with your senior developer. Just getting code reviews done in general are really useful. Again to make sure that your inputs are sanitized, that you don't have some LFI vulnerabilities or just some basic mistakes that junior developers can make, even seniors, that can lead to serious vulnerabilities. Now most companies already have a system of code reviews in place, but if your company doesn't already have these code reviews in place, it might be worth bringing that up. And another thing aside from Code reviews is just updating your libraries. For example, Apache had vulnerabilities before where they had some serious Tomcat version vulnerabilities. I can't remember exactly which, but I remember some black box that I did involve some Tomcat vulnerabilities which you could just easily exploit with metasploit. They had a bunch of modules on that, and for another vulnerability there was these Grafana path reversal exploit that was found. So yeah, it's really important that you make sure that all your libraries are updated, that you get these code reviews done, and that you also listen to your package manager. Now if your company can't afford the correct employees to do code reviews, you could always just go open source. But also going open source you just kind of have to hope that there's going to be more good people trying to help you with your code than bad people trying to craft exploits for your website or whatever it is that you're developing. Now I probably mentioned this before, but you should most likely get a pen test scheduled before publishing a new branch. Now again, most companies do have systems like this in place where they have full time pen testers, where every time a new branch is supposed to get passed before it actually gets pushed to the public, they have pen testers check it and make sure that everything's secure. But what if you just don't have money for a pen tester? You're just a small business. Well, in that case, the best thing I could recommend is just to use these surface level vulnerability scanners like Nessus or whatever it is, to just generate a user friendly chart or list of all these vulnerabilities that you may have. So in here you can see I listed out NMap, which is probably one of the more advanced ones out of all of these because this is something that you need to do on the command line and you need to kind of learn all the companies for it. But if you just search up how to do a script can on Nmap, that should give you a rough idea on how secure website is. And aside from NMap, there's Nessus, which is really user friendly. Once you get it set up, all you need to do is just select what type of scan you want and it will perform it for you. Once it's done, it will give you a list of all the possible vulnerabilities that you may have. And while we're talking about vulnerability scanners, I also wanted to mention Openvas. It's like Nessus, but way more thorough. It has way more vulnerabilities to check. It generally takes way longer, but it's really worth the time and effort that you put into getting an Openvascan set up. Now if you know that you've recently set up a reverse proxy or a web application firewall like Cloudflare, then you should probably take a look at security trails, tiny and zoomai and going in order. Security trail just checks if you've had the actual IP of your server leaked. And it also lists out all the MX emails, a lot of information that it can pick up on the website. And Tinye and Zumai, they're both really similar. They're really powerful search engines that once again help you see if you've had the actual ip of your website leaked. And I've actually used Zoomi and security trails for a pen test I've done where I actually was able to find the actual ip of the web server, which was probably really lucky. But it just goes to show that these tools are really easy to use yet really effective. I also forgot to mention Mascan, which is just an ip port scanner, just to make sure that there's no ports that you don't want open. Like you might have an FTP port open that you don't want. You might have an SSH port open that you don't want. Just generally making sure that the ports that you have open are the ports that you need to have the website running. And that just really limits the attack vectors that are available for attackers. Now this is a really important one. Setting up an ACL is one of the things that you definitely do want. And here you're actually seeing a real screenshot of a pen test I did where I actually had to blur out the ip because I don't want that to be leaked. But yeah, basically I was trying to access a MySQL server or a MySQL server. And on the third line you can see that my ip was not allowed to connect to that MySQL server because of the ACL that they had set up. And in the diagram you can actually see that my ip tried to contact the server and it was rejected. But another ip that might be in the ACL list was actually accepted and was able to get through. So it might be really worth implementing this. And the last thing I wanted to talk about was how you could prevent lateral movement and what this is. It's basically once an attacker gets a foothold on one machine that was easy to exploit, whether they use LFI to get remote control execution or anything that could get them remote control access to one machine. What we're trying to do here is we're trying to prevent lateral movement from taking place so they can access the more important machines. And generally this is overlooked because most people don't think that attacks are going to get into one machine anyway. But it's usually that one vulnerable machine that allows the attackers to get access to everything else using privilege escalation. And here you can actually see that I'm showing a terminal picture of a. I believe that's linpie's output, which, in red, it highlights all the directories that might be worth taking a look at, because they might be that one thing that allows for privilege escalation to take place in order to get access to all the other machines. And the leaks framework is actually just one of the tools that attackers can use to perform lateral movement and get that privilege escalation done. There's a really popular one called bloodhound, which is way more in depth. It actually displays a whole map of the entire network of everything it could find. It's just generally way more in depth and just highlights absolutely everything that even has a chance of getting you that rc on the next machine. So, yeah, that should really just show the importance of integrating security measures throughout development. You really want to make sure that all your inputs are sanitized, that you don't have some LFI vulnerabilities. And it's not just vulnerabilities that I displayed in this presentation. It's just a bunch of CVE vulnerabilities that you really want to look out for, since it can really cause a lot of damage. So, yeah, with that being said, thanks for listening. If you have any questions, you can email me on my proton mail, or you can just contact me through LinkedIn.