Learn to defend by learning the hacker mindset

Hi Everyone. Good morning, good afternoon, good evening, wherever you are. Today we're going to be talking about web app end testing and there will be some hands-on, some of the things that I will be sharing, why I did not give a requirement because I wanted to make sure that we understand here and then go back and try it. If you want to try it, you can just post your questions in the chat box and I'll make sure that I help you out in setting it up. So there will be a few things that I'll be using, so I'll share those things here.

Now, a bit about myself, I'm working as a security relations leader at Snyk. I'm also one of the global board of directors at OWASP. So, this is how I look. I'm also a speaker trainer at Defcon, Black Hat. I've spoken at Black Hat Asia, USA last year. I'm also speaking at a few of the conferences. Now, I'm also on the review board for Grace Harper India, US and some of the VISA conferences. And even Black Hat Asia.

Okay, so today we're going to be talking about basics because I want it to start from the very basic. How exactly an application behaves, what are the things which are there, how exactly we can enhance the awareness about the applications, and what are the ten basic principles to mitigate the application security risk, which will be revolving around OWASP top 10. OWASP is Open Web Application Security Project. It's one of the security community around the world, which started with a motive to have something around application security. But then there are so many projects to chapters to whatnot, which is there. So we'll be discussing about that as well. So that you can also contribute, you can also learn from that. So here, as I mentioned, we will be learning about what what is a web application? Have you used one today? So all of these questions, we'll try and answer. But before that, we need to understand the CIA triad, which is about confidentiality, integrity, and availability. Now, while we talk about that, there is one important thing, which we have with any application. Now, confidentiality, integrity, availability is all fine. But then there are more things which are getting associated with it, which is around authentication authorization and whatnot. And that also needs equal attention when we talk about security or cyber security.

Now, if we look at this image, what do you see, like there are a lot of people who are together there are people from different age groups, different colors, different walks of life. Now, what this picture says is that, or I would say it depicts more of a cyber security because cyber security has so many domains, so many frameworks and whatnot. And the most important aspect here, what cyber security deals with is that it connects all people, because cyber security is not just for the people who are working in cyber security. It is for everyone, literally everyone. If I have to say, I do security. That was one thing that I did. So anyone can be part of cyber security. We deal with cyber security day in and day out. And, one important thing that we do is understanding and taking care of things.

For example, right now you must have a phone. Now, if you have a smartphone and you have a passcode or something, which is protecting your apps or pictures or chats or phone calls or whatnot, that means you care about the security. And, you want to know more about it. And especially, if you are in this session, you want to understand more around application security or software security, here, when we talk about that. It's not just the application that you see on the screen or when you log into any of those external applications that it's just that, oh, this is the only application that is there. There's so much more. There is a back end. There are firewalls. There's a whole network, which has been set up. And at the same time, we also have legacy servers, custom code, be open source code, and think about how much of an open source code that we use, literally think of it.

So when you have an application, the image that you have in your brain, only 10 to 20% of the code is written by us, rest all is open source That is like 80 to 90% of the application code is open source code. And that's been mentioned by many, many people. Now, while I say that there is the, uh, the piece that you need to understand how, how much of open source is actually eating up the whole internet a lot, a lot, but can we stay away from it? No, we can't stay away from it. We have to deal with it. We have to make sure that we understand the whole architecture, and especially when we are working or towards application security, we need to understand the underlying principle.

For example, when you hit google.com on your browser, it, it just doesn't open up. There are many underlying work or if you, if you know about OSI model. So this OSI model actually has seven layers. So it travels through the whole seven layers, go to the server and come back with the information in like fraction of seconds or milliseconds. And that's how it goes. And while it does that, if it's a corporate network, then it will go through the firewalls and app servers, web servers, and hardened OS and what not. So this is like a simple architecture that I could show. But then there are multiple hops that happens. And this is an old architecture of SDLZ.

So earlier we were using SDLZ, which is software development lifecycle, and what used to call it as a waterfall model. But over the years, that has shifted its way, moved its wings or opened it wings to Agile, DevOps. Agile is trying to fail fast and see what are the things that actually fix, what are the things that fix and write. Earlier there used to be development and then after the release people used to go for parties and I remember going for a lot of them. But then the things have changed. If you wait for a year or six months to graduate an application, what will happen or to put the application to the production, by that time, things will be outdated. There are so many new technologies that have come in. There are so many new things that have come in. And at the same time, it also talks about that how we are shifting things to automation. We want application to go live as soon as possible. The feature to go live as soon as possible. How many releases are we having in a month, in a week, in days or in a day? I know there are companies who are having like over 70 releases and a day. Do you have time to think of anything where you go slowly, you have this, you have that? No, you don't have. And at the same time, when you talk about security, oh, that's another nightmare that you have to deal with. So while you're dealing with that nightmare, there is one important aspect that you have to be with, especially it is web application pentesting or security. And that's like a big challenge. You have everything right. But suddenly you say you have to do this. You have to do that. You have to understand that if you don't do the security right, you will be breached. How many people are we, uh, uh, do we have here? And then we say that, oh, you have to take care of security and especially to developers or testers. When you are supposed to test the application, whether it's looking right on or not or how exactly it is. Can you say that you have to look at security or so? You have to do the pentesting. Now, you must be thinking, what is pentesting? Similarly, for developers, they have been doing their development and then on top of it, what more has come in cloud native environments, containers, Kubernetes and what not has come up in ever-changing technologies, like technologies are changing with the lightning speed when that is happening. So what do we really need? We need to understand these key concepts, client-server architecture, where there is a client like me, who's sitting on the laptop or desktop and then try and speak to you, or communicate to a server. It could be TechGIS Summit, could be anything else. So there is a request that I send and there is a response that comes back. So there is a communication which is happening. Now, when we talk about HTTP conversation, those conversations are generally stateless and that's when, or I would say, insecure. More of that, insecure. That's when we start talking about HTTPS. So for any communication that you have with any of those applications, you will see a lock sign. Now, why is that? Especially, that is there in the browsers. Like, if you open Chrome or any other browser, you will see that, yes, there is a lock symbol. Now, what it does, it actually makes sure that your connection is secure, your information that you're trying to do with anyone is secure. Think of a bank account. If you have a bank account, you're transferring money to someone and suddenly I come in between and start removing the money from your account or start transferring that money to myself. Would you feel comfortable? Absolutely not. Why would someone get to know that I'm transferring money to someone else and what is my username, password, what I am dealing with? Nobody needs to know. And that's when browsers are also enforcing these SSL or TLS communication. To be very precise earlier, it used to be SSL. Now, over the years, those communications in the browser have changed. And most of the organizations are enforcing TLS communications for their applications. Browsers are enforcing that you should only have communication over TLS. And even, for that matter, when you talk about the ranking on the Search Engines, they are also very much dependent on TLS connections as well. If you don't have a TLS certificate or proper certificate, your ranking will go down. It might be a push enforcement, but I think this is a good one which is keeping ourselves secure. Then I'm sure most of you are aware about it. But I always speak about the web servers as part of the training so that people get to know. There are many people, especially for the beginners. They don't understand what are the web servers. The primary function or the main function, it is to make sure that it delivers the web content or response to the requests which are coming from the client. It supports basically the server-side languages and at the same time it helps application server. So basically they could be based... The primary function for those application server is to make sure that there is a dynamic content that is processed. It also connects very well with the web server software and takes care of the content which is dynamically coming. So now, we have databases connected so that the data can be saved somewhere, so that the data can be saved somewhere. Data can be saved at a backend which can be fetched at the later point of time. So I will not spend much of time on this, but then databases are very very important. While we talk about frontend, backend is equally important. For example, you have some data which you are storing somewhere.

You have pictures, you have movies, you have your username and passwords, what not is there. And suddenly someone changes the content or someone deletes your content. Would you like it? I wouldn't like it. So that's why we need to secure databases as well.

And that's when there is one important aspect that comes into picture, these web servers and web application servers, which are there. Now with web servers we can handle those web pages, graphic files and what not. And applications that would majorly take care of code, data and what not. And there are different architectures which are there.

Now the most important is which I wanted to show is HTML. We tend to undermine the capability or we tend to not look at HTML content. But this is very, very important. So it was started all for creating a document sharing system. Over the years, we all know that this has changed. Now we are dealing with the sharing communication to what not. And then what it supports, what supports it. What supports application programming languages like PHP, Java, Perl, Node.js, Python, what not is there like Go code or Go language which is there. So there are so many things which are there and it has.

Now when we talk about an application, there are two things that deal with static content and dynamic content. Now what is the static content which does not accept anything from the user? So if you look at my website, infosecwandana.com, it is just to inform you about something like what I am doing, what I do, what are the things that I am taking care of? All of those things. But then there are applications like Facebook, Twitter, Instagram, your Gmail account, and what not, it has dynamic content. They accept information from the users. They try and fetch some information from the user. And that's how dynamic code works. And that's when all of these vulnerabilities come into the picture. And that's why we are here, talking about them.

Sorry. So there are many web frameworks which have come. And the beauty of these frameworks is that we don't have to write a lot of code. It helps in hosting the codes, managing all those extensions, beautifying the applications. So they have their own pros and cons. And why I say cons is when while it helps, there are certain vulnerabilities or flaws that comes with it. There are certain things that come with it. Because if you're using Django, you're using WordPress, but then you have an outdated plugin that you're using. Would you be secure? Oh, absolutely not. Look at WordPress website and the kind of advisories, security advisories that they're publishing because people are reporting the bugs and they're fixing and then updating. But if you are not updating, that means you are vulnerable. And on top of it, what we really need to do is this whole architecture, which is that, which we need to… Oh, okay. Alright, so let me just show it to you. Already, let's go ahead and start.

So this is the client server architecture, wherein we are trying to communicate with the server and then you send a HIRE package or a SEND package. And then there is an acknowledgement that comes from there and then you again send the acknowledgement. Now, this whole communication is called client server architecture. That is the key in any of the application transactions that are happening. And today we're not just going to be talking about applications, but we are also going to be talking about the third party APIs, the third party issues that can be there, the issues that can be there in any of those applications.

Now, while I say that, this is the kind of conversation that is happening. So here I have a browser, I have a web server, but do you see any sort of this communication? I am sure no, we don't see that. So this is the conversation that I have picked up from a web proxy so that anything that is happening on my system, to the server, any communication that is happening, I can intercept, I can modify, why? So, I generally, I'm from the security team, so my brain works in a different way, like it all works in a reverse way. So I'll tell you a funny story, which is not so funny, but then this is what my friend did. Now, there was a new movie that came in and this person wanted to watch a movie and what this person did, obviously there is an interface, which was there, to book it, and this person put in a proxy and started checking, what is going to the server, what is coming back from the server. So, there was a ticket price that came in, as 10 bucks. What this person did is that this person changed the 10 bucks to 1, over the fly. Now, when it went to the server and response came back from the server that paid for 1 dollar and it's like, how is this happening or why this is happening? That means there are some parameters which are only getting tested on the client side but not on the server side. So, that means we can make all the changes. We can change those HTTP headers and whatnot.

So now what is an HTTP header? So, HTTP request, so what we sent to what response that comes back from the server. It is like two-part thing and in that itself we have a header and a body. In the header there are some parameters which are called referrer, cookie, user agent, x-forward, etc... Now I have not installed proxy on my system. I am going to do that with you so that I can showcase to you what I am talking about. So, this is the basic header. Now in the header there are communications that happen via different methods. So there is a GET method, HEAD, POST, PUT, DELETE options. Some of it you might have already seen. Some of it you might not have seen at all. But then these methods are there. And the interesting portion of it is that that when you deal with these what you call it as methods. They work in a totally different way. They work and behave in different way. So here comes the important piece wherein if let's say I am using GET and POST. It is the most common method.

But then suddenly I use DELETE. I use TRACE to trace the information about the server or on top of it I use CONNECT so I can connect to the server. And then I use DELETE wherein I can delete some of the method, some of the files, some of the resources from the server. Would you be comfortable? You have a website and I start deleting some of the files because I know the location and DELETE method is enabled. You would not see the application, having it turned on. Now, another most important aspect is that while I say everything has a different way of working, so it also emphasizes that, yes, you need to look at the security of it. You need to look at a point where how exactly those methods are handled. What I am doing here is explaining the very basics of it. You please keep posting your questions in the chat box so that as and when I see the chat box, I will pick them up. And while we are doing the demo or while we are discussing about the different vulnerabilities, I will open up the stage for everyone to ask questions, everyone to put up any questions that you might have. But I know that it's more of a webinar style wherein I'm speaking and you are just on mute, but then I would request that you keep posting your questions in the chat box so that I can pick it up. And there are few things that you might want to add to it. So please feel free to post those questions as well here in the chat box. So that are the sort of discussion that you might want to have around anything that you have in mind.

Now, let me go ahead and tell you something important. When we talk about the methods, GET and POST are the most common ones. Now, why they're most common ones because we are trying to get some information from or fetch from the server. And at the same time, we are also trying to make sure that we have some information which is actually getting posted to the server. So if you want to deal with just GET, most of the things generally would go in the header. But then we want some information to go in the POST as well. Like if you are communicating with any of the server for the first time and your username and password will also go there. So with the username and password, you don't want that information to go in the header. So that means you need to have it separate. You need to make sure that you are sending it in the body part. And another important thing to remember, any confidential information should not go as part of the URL because URL can be fetched by anyone. Now, we don't go to cafes, but then if you remember a few years back we were going to the cafes and dealing with all of this. Now while we were dealing with it there would be somebody else who would come and sit after us, so they would try and fetch all the information that we traversed through or that we actually accessed. I'm sure you must have seen that those were the major concerns and we didn't have an internet at home or a slow one so we made sure that we just go to this cafe and then chat, speak to the people, email, all of those things. What we really want is that this communication to be secure and that's why we're talking about HTTPS only, not HTTP. Now this browser deals with certain content which is on the client side, so it deals with client side functionality. There are some things which are on the server side, so server deals with that, especially around java files or PHP,.NET, Go-court, or the coding languages. Those are running on the server side. But then the scripts. Remember the scripts run on the client side and that's why we're going to be exploiting some of the scripts as well. Here what happens when there is a communication between clients and server, we put a proxy inside. This proxy could be Burp Suite, it could be Zap, it could be any proxy that you can think of. So there are many in the market. But Burp Suite and Zap, Zap is ZedAttack proxy by OWASP, which is, as I mentioned, Open Web Application Security project. Why I keep mentioning, because it's a security community, it's an open community, and it has resources which people should look at.

Now, before coming to OWASP top 10, let me go ahead and show you something. Let me go readies. Here, let me go to OWASP.org and actually show you what this is. So that you can go back and look at it, you can take help from all the projects which are there. I started my applications for security career with OWASP when my mentor told me that there is OWASP top 10 that you should look at, and OWASP web security testing guide. So this is a security testing guide. So if you're totally new to security testing, this is one of the places to go for, like one beautiful place, which has everything that you can think of. Here, why I'm giving you all these resources and why I'm talking about it, because the motive of this workshop is not to just show you how security can be critical, how security can be scary, but at the same time, you can go back and learn from the resources which are there. There are many wonderful blogs and YouTube channel that I'll be sharing with you all so that you can look at them, you can understand what they do. And as I said, if you have any questions, please keep posting. And the session, I think, is getting recorded. So probably you would be able to go back and check, but I'm not sure when it'll go live. Like when it'll be shared with you. So here, under the repository, you have GitHub repository. There are multiple templates which are there. You can actually check all of the details here. So it's going to be like a checklist which is there and a PDF and whatnot, which is there. So this deals with the whole testing guide. So if you see that their latest version is 4.2, and you can look at the testing guide here. So it's on the web. And then now, why I was saying, see, if you talk about session management testing, how you can do session management testing, especially as it's a testing community. It is very, very important to understand how to test for a particular bug. And the funny fact is that if you are testing any of the vulnerability, and suddenly— or there is someone who has raised a bug for you, and you don't know how to deal with that bug, this is one great place to look at, and it will give you all the information. Okay, this is how this bug is dealt. This is how you should take care of privilege escalation, or this is how you're going to be taking care of certain things. So this is very, very important, and that's why I'm highlighting here. Now, another important thing that is there is that when I started, I looked at it. I created my own checklist. Do you like using checklists? Like, we do love test cases, right? And by looking at it, there are so many things. Think about HTTP methods that I was talking about. Strict transport layer security, like TLS I was speaking about. So here, these are the methods. What do they do? What is the testing objective and how to test all of this? Everything is listed, so you can go back and check. Now, there will be certain things that I would be sharing so you can learn on the go. But then I might not be telling you everything which is part of it. So here, how to test it, what to test, all of the things are there. And I will also share some of the links for vulnerable web applications because it is important If I give you the information, but I don't tell you where to test it, you don't want to test it on the live application, if I'm not wrong. So you would want to secure your own environment and you want to be safe while you're dealing with all the security bugs. And the most important aspect when you're testing your own application, you should have a reference point. This is it. And then I'll tell you the story wherein while I was dealing with this web app and testing guide. Oh, I started creating an Excel sheet because I wanted to remember each and every test case and it took me good week or so to prepare one because I was making it exhaustive and whatnot. And suddenly when I went to my leads, I realized that they were like, why did you have to work so much on this? Like, I thought this would be very useful to me and for everyone in the team. But then they said, have you ever looked at a cheat sheet called OWASP ASBS? And I'm like, no. So OWASP Application Security Verification Standard is basically, this is basically a checklist, which if you look at here, there is a CSV file.

Oh my God, okay. Let's go ahead and download it. But okay, so here I am opening in a word format. Okay, so it opened up in my monitor and let me go ahead and shift here. Okay. I hope you all can see. So here, this is application security verification standard team. So, if you want to deal with password security, what are the things that you should do? Set passwords for at least 12 characters. Now, it says 12 characters, but I was working on one of the environments which was dealing with application security or which was dealing with cloud security to be per se. Now, while we were dealing with cloud accounts, how strong the password was? Eight-digit a lot of times. Now, over the years, we have seen the trend is changing. It is more secure password. People have started to use vaults. People have started to use more secure passwords. And, do you use a brush? I'm sure we all use brushes. So, our passwords are like toothbrushes. When we don't share our toothbrush, why do we share our passwords? It is very important not to share. All of the practices are listed over here. So, you can go back and check or if you want links, I can share it.

Now, while coming back here, Top 10. Why are we even talking about it? So, top 10 are the top risks which are part of the whole ecosystem. And, what it deals with is it talks about the references. It talks about the top 10 risks, not impact likelihood or vulnerabilities. It talks specifically about risk which we can have to our application. And, people say it's a standard. Top 10 is not a standard but it's more of an awareness document which organizations take it as the standard. But, it is more of defining the risks.

Now, what it tells us that we need to look at these risks for sure. The doubt, like sets of baseline. And, at the same time, how frequently it is released, it was first released in 2003, then 7, 10 and every 3 to 4 years, it is released. The last one was in 2017 and then 2020, but we know that last year was not so easy on everyone, so the team could not get all the data from the organizations. And then now the update has come in 2021. So it's September, the new version came up. And that's why we are here talking about the latest one. Now, while I was working on this workshop, we were planning to have the older version workshop, but now it's going to be hybrid where we will be having some content from the 2017 one as well, apart from the top 10 that we are going to be dealing here. And who are going to be like... who can get benefited out of it? Developers, lead developers, architects to testers, to people who are working around the program management and professionals who are actually on consulting, to vendors, to anyone. Who wants to understand about the top 10 risks and applications? And it's nearly 20 years that OWASP has entered the picture. So, injection was one flaw. If you heard about SQL injection, that was like topping the chart or injection of different sorts. They were topping the charts. Even XSS, which is cross-site scripting, which I'm going to be discussing in detail. What are these? But I thought of just giving you some brief history about it. So, here I am. And now, it is shorter by design so that you understand how you have to deal with these top 10 risks. How exactly we can view it at different platforms? Because earlier, it was like a PDF and that's all. Now, there are multiple versions of it. You can open it on Kindle, to mobile, to anywhere. Read it anywhere. And now, it has also changed a lot because now it has adopted the whole AppSec programs, how different organizations deal with it. And it also talks about how exactly a vulnerability can be exploited. There are new categories which are part of it now. Earlier, the injection and this and that were there, but now new things have been added. Including insecure design of an application, server-side request forgery. And there are many steps that have come into picture. Now, people have a lot of questions. If you know about OWASP Top10, I am sure you will have these questions because I know people are asking these questions to me. So, how exactly Top10 comes into the picture or these top 10 risks in an application comes into the picture. So first, we start with, I use this so a lot, I'm sorry, data collection. First, the data is collected. How? By the industry survey and reaching out to different organizations, vendors and who not. Then the data is analyzed. Understood that what are the Top10 risks which are there. Then, there are write-ups which are prepared because it is not easy to create a whole list with explanation to remediation to everything. Then comes the review part. Review, it comes to the community. They look at it, they understand, they vote upon, and after that, it is shared with people and at the same time, there are translations which are done in different languages, English, Hindi, German, French, all of those languages. Then there are multiple formats that are created from web to mobile version, and then we talk about a PDF and developer post, that it is there for people.

Now comes the most important part, the first vulnerability, broken access control. Now, what is broken access control? While you're dealing with broken access control, there is one very important aspect that we deal here, and that we take care here. So if you try and understand from the name itself, it's access control, which is broken. There are things in the access control itself which are broken. So it also says, anyone who's not authorized to access the application, they have access to it. So access control, basically, what it deals with is that it enforces the policies that users cannot act outside of it. For example, when we talk about TechGIS Summit, and there are people who can attend certain workshops. There are people who cannot attend. And suddenly you see that there are people who are not supposed to have access to it, but then they are trying to access it. They are trying to work with them. And at the same time, they're also trying to violate the principles. Now, what are those? I am a developer. Do I need to have access to the production environment? No. But suddenly I switched the teams, now I have access to production. So do I need to have access to the development environment? No. Those kind of access should have been left back there when you switched the team. And there are people who can bypass these access controls. How? Multiple ways, by modifying the URLs. I have seen cases wherein in the URL, you have a username and suddenly people are able to modify those URLs and access anyone's content. That is not the happening anymore, but then that used to be there. And that's what is changing.

Now, people are understanding that if it's an HTML page, there are things in browser, those things are restricted and you cannot use someone's account or you cannot edit all those unique identifiers. Another important aspect is that APIs, which has missing controls, like put, post, delete, we can go ahead and use these APIs and can elevate our privileges. Now, we are dealing with tokens, especially if you talk about JSON tokens. So I am able to temper those tokens or modify the cookies or I am able to manipulate the sessions so that I can get access to the system, which I am not supposed to have access. What it does? Now, it has a very major impact on the privacy. Now, we are dealing with GDPR, a CCPA and whatnot. So it talks about that your data should be secure, but then I have access to hundreds of different accounts because access management is not proper. So what I can do? So access controls is basically only effective in trusted server-side code. If I say, I can modify the client-side, like if you remember the movie Ticket One, where my friend was able to change that, that means the server-side proper validations are not there. And I need to have right set of technology. I need to have validation in place at the server-side as well. And then I put in some business logic testing where I limit the requirements, and I limit the access, then I love the access control failures, or if there are any changes that are happening. And another important aspect about it is that, let's say, if I have an application that is dealing with all of these sort of things, but then I tend to not look at access control. I tend to just avoid that, or I tend to miss out on the like access issues, which can lead to major data breaches, literally major data breaches. So I'll tell you where one website is. It's called, Have I Been Poned? Oh, here you go. Now what this website is, if your application or your email, let's say, this is my email, or let's say demo.com, has been poned part of any of the breaches? Let's see. No, you haven't been poned, but then there are multiple other websites that I have, like on my own domain name. Let's see. No, so you can try any other website. Let's say, oh, okay, my another email. I keep changing my passwords so frequently so, but then I remember being part of one of the breaches once. See, my email address was part of two data breaches. Now, what are those data? What exactly is there? Now, I don't know which are breaches, but then this website can tell you that yes. So anytime you see that you've been part of the breach, you will be listed over here. Make sure you change your password. And another important aspect is that do not keep the same password for multiple applications. Why I say that? Because if you know about the recent issues that happened with the colonial pipeline attacks, right? What was the issue? What was the hack all about? Now, it was all on the pipeline. And then the whole issue started where one password actually allowed attackers to disrupt this whole colonial pipeline. So this is all that I read on the internet. I have understood what they've mentioned as the whole history of it. Now, what happens when there was someone, their password was reached or their password was lying as part of one of the breaches and somebody, malicious attacker you can say or an attacker, they got access to it. Now they started playing around and they realized that this could lead to something very informational to them and they started using it. So, but what happened beneath that, the credentials found were part of a legacy VPN or virtual private network. We think that VPNs are secure. They are but then people were using the legacy VPNs and there was no multi-factor authentication which was enabled. Now, while they were dealing with it, think of somebody gets your password, access it and then starts playing around and that's how the whole ransomware piece came into picture. They encrypted the whole files and asked for money. Now, FBI came into picture. They paid the ransom and after that, what happened? They gave the software or the key. Now the key helped in decrypting but then the major portion come into picture that it was so slow that they had to back it up from the backups that they had. Then came the nightmare. Even after paying so much, there are issues. So can we recommend two factor authentication? Can we do better at security hygiene? And that's what this broken access control talks about. And then it also talks about multiple CWEs, CVEs. Now CVEs are common vulnerability exposures. Now every vulnerability has associated CVE number. So broken access control has 19k CVEs. So many. That means it has occurred many, many times. So one vulnerability has multiple things under it, multiple agendas under it. And on top of it, how do you test it? There are many ways, wherein let's say, for example, let me show you actually. Then you will have a better understanding. Let me go ahead and share my other screen as well. I read it. Where did it go? Here if you see what it says, username, what could be the username? I don't know. What could be the password? I don't know. So let's try. Generally if I get to any application, I'll say admin, admin. Admin password? No. There are some applications which have super admin and super admin. Oh, there it is. Oh, see, it is all there. Am I logged in as a super admin? I am. Do I have an unsecured password? I do have. So these are the things that actually create issues. Now, you must be thinking which application is this. So I am using Damn Vulnerable Python Web Application. And let me just give you the link in the chat box so that you can host it on your environments and you can test it out. I'm gonna be using this application for SQL Injection as well.

So I'm gonna just send it to everyone. And I'm gonna open it and I'm gonna show it to you here as well. So here, this is Damn Vulnerable Python Web Application. You can run it on your Docker container. So I'm running this on a container. I have a container running, on which I am running this app. So this was the easiest way to get into any system. But if you look at the whole security piece, there are many things which are there. And even the checklist, this checklist, ASVS, talks about a lot of things. This scares me.

Now another important aspect is that authentication errors. So sometimes you don't look at the authentication errors in an application. I still see a lot of applications give these errors like, oh, your password is incorrect. Or your this is incorrect. Oh, here is the issue. Now think of, if we don't have a generic error, would it be a problem? Absolutely, there will be problems. How would you get to know about these information, right? Like, this particular information has to be dealt with this way. Now remember one thing, never to have weak passwords. Never, ever have passwords which are dictionary passwords, which are easy to remember. Have a big one. Maybe a passcode, sorry, passphrase. And another important thing is that for application owners or the people who are dealing with these negative test cases, remember that these error messages which come as part of the application should not give any information. Now I'll tell you something more. Let me close this scary thing and then show you. So I have another application which is running, which is called a security knowledge framework. So I hosted it on my Kubernetes and I'm running with RabbitMQ and whatnot. So here, I can log in. So here I don't have a login local host setup. So you can't get to it, but then you can set up your own thing.

Now, why I talk about this? Because it has the whole framework, which I totally love for you to go back and check. It has a dashboard, which gives all the information, different code-based, checklists, knowledge-based, escape knowledge. And then it also talks about managed projects. If I have a project which I want to deal or I want to create a new one, and then quotes examples. Let's say I want to know more about XML injection prevention, or I want to know more about password storage. So I'll go ahead and read about it. And I can see how exactly I can set up my own code for that. And not just that, if I have to whitelist certain characters, what I need to do, I can just go ahead and read your about that. What kind of code that should be there? If you look at the whole pattern, how exactly I should be auditing it, what are the functions that I need to call, what is allowed here, all those things. And then the most important aspect is that if I need to prevent session hijacking, what I need to do, all those are here. And that's why I recommend you to just go back and check the Security Knowledge Framework. If you want to download it now, let me go ahead and show you. Go over Spark. And I'm gonna give you the URL so that you can take a look at it. Projects. And under the Project, there is Security Knowledge Framework. You can go here. And, okay. Here I can go to the repo, which has all the details. Like how you can set up, what are the things that can be done. So let me just keep it in the chat box so that you can take a help from it. So this is called Security Knowledge Framework.

So, the one important aspect, why I'm sharing all these resources, because if you knew from my like, the way I'm speaking, you understand that these are the things that are there, but then you don't understand that how to exploit it, then it is a big problem because security talks about exploiting and how you fix something. And in the knowledge base, everything is there, right, from web applications to mobile, and then you create your own custom checklist for certain bugs that you get to know, which is only coming in your code. Or there are labs which are there. Let's say I want to know more about cross site scripting. So let me go ahead and start the lab. Oh, yeah, yeah. So let me tell you one thing. Then I am using this lab, it has multiple attacks, like literally multiple attacks are there. So you have to, you can actually go one by one and enable specifically, let's say, this is the deployment URL. I'm going to go here. I am going to click here and I'm going to open it. So if you see there is a live demonstration that is open, and this is first XSS. Now, I'll say JavaScript alert XSS. It might work, it might not work. Because not all the time XSS works. That's very common. And not all attack vectors work. So let me go ahead and click on this. If you see, it is just posted over there.

But then what more I can leverage from here? Let me go ahead and understand what are the things which are there and how exactly I can exploit it. Now, I might want to try something interesting here. Let's see. Script. Alert, one, two, three. Script. Submit button. So it might work, it might not work. So what I should do? Should I lead the hope that it will work, or what should I do?

So there are cheat sheets which are available. So I am gonna go and access this cheat sheet. I'm gonna go and do that. So this is what security people do. They look for cheat sheets for every vulnerability. For this one, I'm not sure if it's gonna work. And secondly, I'm running on a local Kubernetes, so sometimes the things are slow, but then when you run it on a good speed and server, it will work. And then in the cheat sheet, I have like this image scripting tag, there are multiple tags which are available. So remember one thing, that when we are dealing with these test cases, some of them might work, some of them might not work. So, it depends. Similarly, let me go ahead and close this and then enable another process scripting one, so that I can show you how attributes work here. See, did it work? No, but then there is something which is breaking on the web application, which might work. So let's go ahead and see if my lab is open already. So I'm going to go ahead and open here, 320.71 and here, I'm gonna use this, and see if it works. It is, it needs a color, so I said red. And then on mouse over, alert 1337. Okay, so let's see if it works or not, but then meanwhile here, you see that there is something which has come on the screen. So let's see what has come on the screen. I hope it works because before coming for the session, I tested these labs and it worked. So I'll show you something. I'll just show you a screenshot. Oh wait, did something happen? Live demonstration, did it come? It's still coming. So let me post a screenshot here. So if you see this, this was the lab that I was working. Wherein it alerted localhost on the port, this alert 1337. So this is very easy. Alerting so that I can make you understand. And not every time XSS will actually give you a popup. Popup is easy because script run and it gives me the alert. But it might print some attributes. It might work in href. It might work wherein there are certain characters which are blacklisted and I'll try and overcome that. For example, there was once what happened is that I found an XSS. And after finding this cross-site scripting, somebody fixed it. But then after a while when I tested again, it was there, why? It has to deal with input validation. And that's when you're, oh, no, no, no, no. We've tested the user authentication, we have tested all of these things. And the most important aspect that comes is input validation. Then we need to have an understanding of what are the inputs that we're giving to our application. Okay, why didn't come? Let's see, let's see, let's see, I hope it works. While it's happening, let me go ahead and tell you. So for example, you are dealing with a database and I start sending some malicious input to the database like database expects some input from the user, but then we put like a SQL statement in that. Am I supposed to provide SQL statement? No, I am not supposed to provide any SQL statement. So what do I need to do? Here, let me close this and then show you something interesting. So here, I have this. Now, while I'm dealing with this, what do you see on the screen? Like it's just SQLite, I have a Super Admin account and I'm dealing with users. So under students, I can add a new student. So which could be Vandana, which could be anyone. But instead of that, I choose to add something else. I choose to add maybe a vector where in it shows it's like a SQL statement. So should it accept the SQL statement or no? Think about it. I'm sure it does. And specially if I add the statement with the name, Robert Rock Table Student Cascade and I'll say, save. Oh, what happened? That means some information. Do you see? It gives me some juicy information. It tells me that it's a system. Oh, could be a Linux system. It could be a Python package. It could be an issue with such lines. So all this information that I was able to get. Now, I might want to modify with something else or I might want to have a SQL query embedded to it wherein I drop tables. So this will be very, very helpful for me.

So would you want your... So this happened with one of my friends wherein one of my friends wanted to check the results for her daughter and she was looking at it. And she realized that there is some issue which Database was giving her. So what she started doing is she started playing around with application content and what happened next. There was a table that she could find that yes, this could be a problem with the table itself. Can I delete the table? What next? The table got deleted. Interestingly, the very next moment, the application server went down because the backend started to be behaving in a totally different way. So what was the problem? Whereas we did not have appropriate validation in place. And that's what it led to SQL injection, where application is not supposed to accept this drop table or it is not supposed to take these information wherein I can remove the users from the table itself. Is it supposed to? No, it is not supposed to. And that's when the problem occurs. That when we take all the inputs and we don't handle it well, that's when it starts creating all these issues.

On top of it, if I'll say, okay, let me see. To try and see, okay. So it is giving me all of these errors. And let me go ahead and go to SQLA and see they around with some more courses. Now, do you see student section is not there anymore, wherein it has started to give me errors. Why? Because I have started to play around with the server. First I was able to log in via broken access control to the application. And then I started deleting the content because the server was not validating them. And that this is how I landed to it. Now, if I come back to my presentation, here it says input has to be validated. So SQL injection is one important thing that has been there in web applications for a very long time, or injection. And that will be there. People have been there for ages in the ecosystem and they're able to find these vulnerabilities. Why? Because new, and newer things are coming up, but we don't tend to understand the whole concept. I don't know each and every application. I don't understand each language. And I start working on something and suddenly it starts to crash. Why? And then there are certain issues which are there at the database side. We don't know about each and every database. And it starts accepting the things which it's not. Then how would you deal with the cross-site scripting? Now scripting happens, so this is actually on the client side. Now, it is not part of OWASP top 10, but it is important, so I'm talking about it. So when we inject malicious code into the vulnerable web app server, ideally, does it supposed to accept it? No, but then we are sending a script to the server, so now this is specifically a case of a blog, like blog as vulnerable. And now people go to blogs to read something. I have posted a vulnerable script there. Anytime anyone comes to that page, they see a popup, they see their information getting somewhere. Similarly, if the script says that send the cookie, anyone who comes to the server, all the cookies should be sent to a third party server, will it work? Absolutely it will work. So that's how it give all the information to the attacker web server. Now anyone who would be dealing with it, like intercepting with a proxy, they would be able to have access to it. They will be able to take care of it, or they will be able to play around with it. Now fuzzing is something when we deal with a particular parameter, or when we are dealing with any of those applications where there are hidden parameters, and I start putting some random characters and try and bring down the application or modify the application. This is more or less about input validation. Please let me know if you have any question in the chat box.

Okay now while moving to insecure design, earlier it was not part of the OWASP top 10. But now it has become part of OWASP top 10. Now why we are dealing with this top 10, or what it talks about. So insecure design, the name says itself that it is insecure design of an application. And while taking care of that, it actually impacts the whole application. It also actually deals with, with the way that the design, which is more of a broader category, but it has different weaknesses. Wherein think of as a design flaw or implementation flaw, which leads to giving you access to anything. Now, the main requirement and negotiation here is that, it actually impacts the availability, confidentiality and integrity, and at the same time, authenticity of the datasets. Your, when you are dealing with secure design, it is more of a culture, you understand, oh how secure is our application? And while we are building an application, what are the things that we should keep in mind? A lot of times we don't tend to look at that aspect, and what happens next? There is a design flaw. Oh, there are people who are able to bring down the application. There is a denial of service attack. There is this attack, there is that attack. So which becomes more common, and we are not able to have the maturity that we need for our own application. And that's when we try and talk about, we need to have maturity modeling. We need to understand, where do we stand? What are the components that we're using as part of the applications? What are the tooling available, and how we affect modeling an application? And what are the things that we can do for this? Like, how do we even test it? And the most interesting portion here is that it helps in integration testing, that wherein we have an application which is connected with the front end and back end. So how exactly we can prevent these flaws? We can have a secure development lifecycle wherein we evaluate this design and security of these tools. We establish and understand that what are the security design patterns which can be there? What are the components that we're using as part of the application? And how to keep them secure. Another important or interesting aspect is that threat modeling. Now, threat modeling is performing security checks early in the lifecycle. Understanding what are the risks which can be there for our own applications? Understanding what languages do we use and what user stories that we have. What the best cases, or the unit or integration test cases that we need to validate for the critical flaws which are there, which can impact an application. We need to compile all those use cases and misuse cases for each tier of our application and segregate each of this. Understand, what are the resources that are used? What are the resources which are consumed by the users or services?

Now, why we talk about that? Attack scenarios can be there, wherein, think of wherein we are trying to recover a password, which has question and answers. Now, which is now prohibited by the organizations, why? If I am your friend or if I am your acquaintance, how difficult it is to answer some of the questions? It is easy. That's when the security questionnaire is trying to be removed from all these things. Such codes should be removed and replaced with more secure design code. Another thing is that I was talking about the cinema chain, right? Which allows group booking discount. Like we have a Book My Show here. Which is like you can have a max of 15, 20 tickets that you can do. But then I understand the flow. I tried, tested and I start booking more than that. Or while I can book one ticket for 10 bucks, but then I am able to book it for one. And that too, if I want to book the whole hall, movie hall, I would book it. Similarly while we are, like for example, while we are buying on eCommerce sites, especially time of sale. And what happens is that I can modify the cart value. How good that would be. Or I'm able to modify the price. That's another way that I can modify the cart value. Let's talk about security misconfiguration. So there are so many CVEs associated here. And it all talks about understanding how to have security early, threat model the application, testing these applications. And another important aspect is that security misconfiguration. Now, what is security misconfiguration? Absolutely. Now it talks about the application might be vulnerable to appropriate security hardening. Or the stack itself is not secure. The permissions to the cloud services is not secure. And now while you have cloud accounts, you have your applications in the cloud. But then anyone has access to the root account and they are able to play around. Anyone is admin on it. Well there are certain people who are admin and then suddenly leave the organization but they still have access to it. Unnecessary features like different ports are enabled, services are enabled, pages are enabled, accounts are enabled. Am I supposed to see that? No, those should be closed completely. Default accounts and passwords, they should not be enabled. We just saw today, super admin, super admin. I was able to log in. Would you allow that? Absolutely no. And then there were errors that came as part of the application. Would you want that? No. And the most important feature, if you don't have the right kind of libraries used, then there'll be a big problem. Now let me show you a demo here. Okay. I will say Java. So this is another app that I'm hosting on Heroku Cloud but then this'll help you understand more around the security validations, why am I actually emphasizing on all of this? And the next vulnerability, vulnerable and outdated component has actually just lead to that. So here, this application will take a few minutes to come up and now because, yeah, it's here. Now for every app like conference or anything, I make sure that I create a new account. So I'll say TechJs at demo, then TechJs at demo.com and then some password. Hmm, hmm, hmm. Hmm, hmm, hmm. Always use a long password, don't share it with anyone. I don't, nope, I don't want to use.

Here, I am not, I did not save the password to my password manager because I am just using it as a demo. So here, if you see, I have my account. Then in my account, I have some details. Then it says, so this application is about to-do list and I am a huge fan of to-do. Like, I totally love it. Why? Because it helps me in remembering things. Another important aspect is I can track what I need to do in the coming few days. Like, I wanted to do this, this workshop. So I actually collated multiple demos here. Now, I'll say, that's just the due date is December 12th. Oh, sorry, December 2nd. And I created the to-do list. Then I create another to-do list, Vandana is a hacker. Okay, I created it. I'll click on create. And that has been created. Now, if I try and modify, if my brain works in a totally different way, like, so what I should do? Understand more about the application. Okay, so I can see that there are options to upload the files. And all the files would be seen in the public folder. Hmm, interesting. What else I can see about, generally, things that you see here in the about section, you might not be able to see it in all the applications. So here, the information like struts, Spring Hibernate, these are frameworks, or banner grabbing. So, you would not be able to banner grab easily. Generally, you would see in the HTTP response. So here comes the most interesting aspect. If I try, if I know what is wrong here, so the wrong thing is here, the struts version which is used here, it is one of the vulnerable version. I'll show you here, struts.2.3. And here, if you see, I can see the release, but then it has struts.2.3, there is an exploit, which is available. What do you mean by exploit? That there is a vulnerability that is available, which people can leverage. And this is the same vulnerability, which was part of the Equifax breach, when we had sleepless nights. So we could see that there are remote code execution and whatnot that could happen here, right. Now, I know it. Hmm, what else I can do? Let me try and create a to-do list with cross-site scripting. I would love that. Okay, let me create something interesting. Here, I create my to-do list. I create a few days. I'm not sure if it's gonna work, but let's try. Hmm, it didn't work. Let me try something else. Okay. Okay. Accesses. Hmm. Where is accesses for the revision? Let's see. Generally, it doesn't work, but you never know. Oh, see, it works. Yes, yes, yes. So, I can actually fetch a lot of information. Ha-ha, see? But then there is one. Now, interestingly, I will upload some malicious files, so I'm gonna go choose files. I'm gonna go here desktop, I'm gonna go to my GOOF, all ready. I'm gonna go to my javagoof, like any malicious person or attacker, I have some exploits, so I'm gonna use this zip folder, which has my exploit, and I'm gonna upload it here. Uh-oh. There's nothing which has been uploaded. So what interesting fact is there? Let me create a doodle, oh, nothing happened, my exploit did not work, but it said it is using an older version. Might be something else. So I'd say, vanna is a hacker. I'll use it to date or create it. Exorcist is coming, Exorcist is coming, but I am looking for this one. So do you see that there is something that which I wrote? Vanna is a hacker, did not come here, something else came here. Let me create another to do list. Vanna is not a hacker, it might like it. Here. Uh oh. Okay, so exorcist will keep coming up because it's a stored now. But do you see, it has accepted the remote code execution which I did, so remotely I put in a code and it is accepting it. The fun fact, it actually works here, so, if I'm using an outdated version, but things can go wrong, you can look at here. And things can go wrong in a very very weird way. And that's when we talk about vulnerable components, that we should not have these vulnerable components.

And we should not have this side effects that are there. We should always test our application before putting to production.

Okay, okay, okay, prevention done. Here, my favorite one, which is more talking about that what are the things that should be there.

Now, if you don't know the versions of all the components that we use, both from the client side and the server side, it can create a lot of chaos. If the software is vulnerable, like I just showed you, or unsupported or out of date, this can include the OS, web application server, database management server, applications, APIs and all components, runtimes, environments and libraries. It can be very tricky. So, we have to scan for all the vulnerabilities regularly and understand what are the things that we have in our environment. Those are the things very, very important not to miss them. And if we do not test the compatibility of updated and upgraded softwares or patched libraries, we can be in trouble.

Now, let me show you an API, which can create an issue while we are talking about it. Okay, let me go back here. Okay, so I have my system running over here. Okay, let me make it a bit bigger, yes. Now, I'm gonna go to my Desktop, and then on Desktop, I have my GOOF, which is running. And then we have so many things. I'm gonna run a CD express node index.js. Now, if you see that this is an index.js, you must be thinking what is there in the Express. So, let me go ahead and show you here. Varys cd express ls. Only a JavaScript file is there. Nothing else, like literally nothing else, no application. I've been showcasing applications, but here it is running on Localhost 3000. Now, when it is running on Localhost 3000, there is an interesting factor. That means it's an API, it's a JavaScript file, which is calling some APIs and running somewhere. So, I want to play around with it, like literally play around with it. Okay. So, it has some features which are there. And now, what I really want to do here is, I want to open it up here. Okay. Okay. Here, this is the common thing. Do you see anything here? In the browser, I have some excesses. But then, it is not reflecting. There is a string, which is here, which is going in the name. Now, I create an area here. So, you see an excess is getting replicated. The most interesting aspect is that application is considering string and area separate. Even though the application is sanitized, it is bypassing it. And that's a problem with one of the APIs, or a red query, which is part of the express framework. And anyone who's using that, they are vulnerable to it. They are vulnerable to cross-site scripting. So, this particular request, or request query, even though you are sanitizing it, you are creating a lot of concerns. You are creating a lot of issues for yourself. And never, ever use a library, which can be a tricky one. If you see, it is reflecting here. In the browser, it was taking it as a string. But here now it's taking as an object. Now if I want, I can have multiple, let's say they put in something for an array, so I will double array it. So, it might not work, but I might want to try something else, which might work. So, similarly, we keep trying all of this. If you see here, I have double arrays, but then I want to play around with it. Or, I might want to see something more. I keep adding things, and it'll work. So, it depends how our application is taking, but then this particular Express API is basically vulnerable to cross-site scripting. Now, this was with single API, right? I mean, just go ahead and start that, or it's going to eat up my whole system. Okay, Ctrl-Z. What? I don't want it. Okay. Here, let me come here. That's why we say that when we recommend the third-party components that we're using, we should not be using the outdating components. Beat anything. Beat your browser, beat a framework, beat a web server, beat an application server, beat any dependency, third-party dependency. Like so many dependencies that are part of our code. Sometimes we don't even know about it. And then comes the interesting part, wherein there are many threat agents, which can be there. We have to spot as early as possible, understand the technical impact, business impact, or these kind of known vulnerabilities, which will exist in our environment. And will keep creating concerns for our application. That's when we need to understand, identify the authentication failures also. Now, what is that? Now, why are we dealing with it? We've been talking about all of the other things.

So here, we need to understand who the users are when they're trying to access the application. So authentication and session management is very, very critical here. To understand around any authentication-related attacks. We need to permit automatic. We don't want to permit any automated attacks or attacks which will lead to password trying. So if somebody knows your username and they keep trying it and they might get to your credentials, it can happen. So that's when what you need to do is we need to make sure that we are using account failures or lockout when we have these applications. And another important aspect is that when we are dealing with this, we need to make sure that we are not permitting brute force or automated attacks. And then plain text or encrypted passwords or hashed passwords are handled properly. We are not missing out on multifactor authentication. It is very, very important. We should not expose the session identifier. So right now we are able to log in to any application. The first time you use the username and password and after that, what happens? You don't use a username and password but instead you use like the session token. But if I get to your session token and I'm able to replay those things, would you like it? I'm sure no. You don't want your session to be logged in as me. So people are using Instagram, Twitter, like I'm super active on Twitter. So you get my Twitter account. Would I be comfortable? Absolutely no. So we should be making sure that, especially for testers. When we are testing these cases, we need to do a negative testing for the session identifiers. The session identify should not be, never ever be reused. And there are sessions which are invalidated properly. Whenever possible, let's implement multi-factor authentication to actually prevent these automated credentials for like e-mail traffic, root forcing attacks. We should also make sure that we are using, we're implementing a check for weak passwords. And we need to make sure whenever somebody's trying to put a simple insecure password, we tell them that there are issues which are there.

And then server side attacks that we can avoid as much as possible. Now comes another important aspect of... data integrity failures. Now all of this that I'm talking about, these are all new OVAAS bugs, new bugs, which are part of the whole CACD pipeline or security list. So software and data integrity failures relate to code and infrastructure that actually does not protect themselves against the integrity violations. What are integrity? Wherein something which is stored somewhere and people are able to modify it up. So example of this would be, wherein there are plugins, there are third-party libraries, modules which are there from unstructured sources or content delivery networks.

Now, and then there is the whole pipeline which is set up, but then there are components which are insecure and that's how data integrity failures happen. So what we can do is, we need to use certain tools, which can help us in understanding that what do we have in our environment? We're using Maven, we're using Jenkins, we're using so many tools. So can we have them, can we actually have security as part of the whole ecosystem? Can we have a review process for the code? Can we make sure that the configuration which is there, which is checked properly? We are ensuring that our CICD pipeline has proper segregation, configuration check and access control, making sure that the integration of the code is appropriate.

Now, many home routers set up boxes, device firmwares, and we don't verify the updates. We just go ahead and start using it. So unsigned firmwares is basically a big issue or unauthenticated upgrades. So there is a major concern many times that there is no mechanism to remedy those fixes. So the latest version is vulnerable. The older version is all good. Or you have updated from place where it came up with some malware in it. Think of solar wins. Now, it was a nationwide issue or the worldwide issue wherein there was something happening with solar wins. There was a dependency or a DLL file, which was part of the whole software base which was the main cause behind it. And that was shipped to everyone. They were able to support, but then for several months, the phone distributed a highly targeted malicious update for more than 18,000 organizations. Out of it, hundreds were impacted. This is one of the most far-reaching and most significant breach in the nature of the history. Oh God, that was so big. Similarly, we need to understand what we are dealing with. Because if we don't know what we are dealing with, we will have these issues.

Now, server-side request forgery, the most interesting one. Now, SSRF has been there for a very long time. And when we are dealing with this, there are like challenges which are there, which we need to take care of. And we sometimes tend to forget about them. So, what happens next? If we are not dealing with SSRF, which is impacting the server? So, let me go ahead and show it to you basically. And if I can go ahead and show you. Give me one second. So there was one beautiful website which had the demo, which I'm trying to give you so that you can also try. Hashtag, Deano. Give me one second. I'll show it to you. I'll actually ping you that URL so that you can actually try that. So, there was one breach which happened on CapitalOne, which had server-side request fraudulently. It deals with where we're trying to get some information from the server. And we are able to successfully get all the server information, and we are able to play around with the SSRF. I think I have it. All ready, so let me go ahead and ping you here in the chat box, and put you on the screen also. I have no idea. While I just change my browser, or while I search something, it behaves in a weird way. Okay? Now, so this is the capital one SSRF. It is an online one, so I really like showcasing here. Now, let me give you a brief introduction about it first, so that you understand more about OWASP Top 10. So SSRF, so SSRF is server-side request forgery. So these flaws happens when application is fetching a remote source, without even validating. It could be scanning an internal network and give you all those details. What it does is, it allows the attacker to understand more about the application, and they can draft a request for the unexpected destination. And modern firewalls may not be able to detect it. So it can impact the network layer to whatnot. And where is the contra? Okay. Here, now while it is talking about it, let me go ahead and click on next. So you can actually try it yourself. Now, this is a capital10.com, because it's just a demo. I'm gonna go ahead and paste it here. And when I hit here, it is asking for a username and password. So I'm going to put username and password. I'm going to sign in. Now, it has account services. So I'm going to go hit my account services. I can change the way card image. Now here, I should put some card, right? Just the basic card. Just the basic card. But then, instead of that, I'm able to go ahead and wait. I am able to update a png image.

Upload and preview, find, next. Next. But do you see there is a URL here on the screen? It provides the location of this image, where it got stored. Interestingly, very amazing. That information is with me. So let me go ahead and close this for happened to it. Okay. Now let me copy it. Now here, I'm gonna go ahead and change the URL and see if something happens. Here, it has taken from anywhere, if you realize. So here, when it took from there, it actually gave me some back end code. Wherein I can do some exploitation. I realized that I can put in from third party pages. Instead of uploading from my system, I can give a URL. Here, if I start analyzing the code, there is a method for rendering which is used. There's a URL that has been taken and then I can take this query string. I can load it because there's a load method which has been used here. Unfortunately, there's no input validation which is there because if you remember, I just will pick up the S3 bucket page and then change to something catchment. So there is no URL which is being validated. Now here, I could see Cat's theme, right? Now, let me go ahead and put a different URL. So this is a unique URL, basically, which fetch the metadata from the AWS account. Any AWS account. Here, this is not everywhere. So now, what I wanted to understand about metadata, it actually gave me the metadata, if you see here. Interestingly, I have that information. Now, I know about the structure. So this is a structure for getting the security credentials. So let me go ahead and fetch security credentials. If you see here, I can actually figure out a role here. And then, I can try and create, I can try and fetch more information about this role. Interestingly, it gives me some more information. Okay, sorry. Here. Now it tells me nice information. What is that? It gives me access ID and secret ID. Do I just need that to log into the account? Absolutely, yes. Here, if you see, I'll put in this access ID, I'll put in this code, and what else I need. So here, I'm gonna go ahead and fetch the details. Anything and everything that I need, I have the information. So that's what SSRF does. There are many exercises that you want to try, so you can go ahead and try, from command injection to XML entities. So, this is one great website that I like for training people, and especially SSRF is one beautiful one, which is listed over here, so that people understand that how the third-party URLs can fetch the information from the server. You can scan the server altogether. You can actually play around with the server, which is there at the background. So, server-side request forgery is big problem in many applications. Even if I talk about the security knowledge framework, it also has it. So, let me go ahead and start the lab and show it to you. So, if you want, you can try all of these exercises yourself and you can set up your security knowledge framework as well, which I am enforcing because you should try these labs yourself. Then you understand better. Because instead of me telling you what it is, how it is, and how you prevent it, if you have mechanisms which are available for you to understand, it becomes easy. So, I can just go ahead, go to my lab view. Let me remove this. And in the lab view, I have everything possible. Right. Here, under labs, there are many labs which are available, right. So, I have server-side request panorama as well. So, I can go ahead and start it. It will take some time, and we'll be started. I have graph QL introspection to XSS to captcha-bypass, to database schema bypass. Everything possible that can be there. Now, let me come back here. Now, what are the next steps? We need to understand the code-quality issues. Understand what can lead to denial of service attack or memory concerns. And at the same time, we need to understand how big these issues can be. For example, if I talk about the OWASP top 10, so it's just a minimum list, I would say, which is the entry level UpStack program. It can be very good, but then you need to understand it, that there are more things attached to it. There are more issues which are attached to it. And at the same time, there are more features that we need to understand in our own applications. So it is very, very important to understand all of these things. But not to miss out, that these, there are proactive controls which we can do.

We can properly define the security requirements. We can leverage these security frameworks and libraries, but then, let's use responsibly, and then encode and escape the data, understand where we can have proper input validation, where we can have the whole validation in place. And the most important aspect, let's have proper access controls which are enforced, handle all these exceptions, errors properly, use application security verification standard wherever possible.

Understand how these frameworks can lead to bug classes. Very, very important. And last but not the least, understand that we don't need this insufficient logging and monitoring. We need to log everything. This is what happens when we don't have the proper tooling mechanism, proper mechanism where we can record, understand these things. We need to log the errors, understand where the polls are happening because if we don't understand that, it will lead to issues. The breaches that are there.

And most breaches, studies show that it will be over 200 days to detect a breach. Typically detected by external third parties, then internal process on monitoring process. So how critical that can be. These are some of the resources that I totally love that you should look at, but totally, as I said, look at security knowledge framework that are labs, which are available, that can be helpful. There are filters, which are available. And yes, the most important of all is that OWASP top 10. So let me go ahead and give you the URL so that you can go back and check it. Idly, we kept it for three hours, but I think we are almost done with it. And I'm going to just share these information so that it will be helpful.