ASP. NET Core Development - Understanding Common Vulnerabilities

1. Introduction : Welcome to this first section of the course where we will take some time to understand common vulnerabilities that we will encounter when developing software. Now in this section, we want to explain the costs of insecure code in real world systems, want to describe why secure coding is critical in.net applications, identify the OWASP top ten vulnerabilities that are most relevant to us as C Sharp and.net developers and recognize common coding mistakes that introduce risks. All in all, we want to be able to apply secure coding practices and preventative strategies in our projects. So thank you for joining me in this section. I'll see you in the next lesson. 2. The Cost of Insecure Code: Now let's take some time to discuss the cost of in secure code. Now, insecure code can lead to data loss, reputational damage, compliance fines, and even business shutdowns. Enterprise applications generally are designed to hold very sensitive data because you build an application for your enterprise, the expectation is that whatever the business does, the clientele, all that data is going to be stored inside of that application, or at least the application will interact with it in some way, shape or form. So if that application or other applications that interact with that application or touch that data, if there's insecure code present anywhere that can lead to an exposure of things like connection strings or PII, which is short for personally identifiable information, or things like API keys. So at the end of the day, there are so many things that really go into the development of an enterprise application that you really have several boxes to tick before you can confidently say that your app is secure. Now, insecure code can have direct and indirect impacts on the business should there be some breach? For instance, a direct impact could be the incident response. How do you respond to a breach or some form of security event? There's also going to be downtime and may even lead to regulatory fines because based on the industry you're in, there are different rules and different levels of strictness that are applied to when data is leaked, and, of course, insecure code could lead to a data leak. Then there are also the indirect consequences like loss of trust. Do your customers feel safe with you after that breach? You also have insurance costs and developer burnout when trying to fix the issue, address the issue, triage the issue, whatever it is. So there are several costs that come with having insecure code. 3. Using The CIA Triad: So when talking about secure code, you must consider the CIA triad. The CIA triad is a foundational model for information security, and the letters stand for confidentiality, integrity, and availability. It guides organizations in protecting sensitive data by ensuring that the data is only accessible by authorized users. It remains accurate and unaltered and is accessible when needed. Here's an example of what you may see if you Google the CIA Tread, or if you see a diagram of the CIA tread, it's going to look something like this where they point out the different points. Integrity once again is, can I trust this data? This data should not have been altered outside of the original source or outside of the approved business rules for alteration or creation. Confidentiality means that anything that is sensitive should not be exposed or over exposed to anybody who does not have sufficient security clearance, and availability means that if I need data, it should be available upon request. Of course, you may have some business rules and some nuances around the actual availability and SLA. But the reality is that if the business has timeline for when data should be available, meaning many organizations say data should be readily accessible. Up to seven years. After seven years, maybe it goes into cold storage and archived and then maybe access is a little harder. But the fact is, whatever the business rules are, you want to make sure that your code can live up to those standards and that those are the tenets upon which we say we are building a secure application. 4. The Importance of Secure Coding: So up until now, we've been talking about the importance of secure coding, but what exactly is secure coding? Well, secure coding is writing code that prevents exploitation or at least known exploitations. It means writing code while you're thinking like the attacker because attackers attack. So if you think like what they might do, then you write code to mitigate what they can do. At this point, you also want to consider baking security into the design of your application. So as software developers, we'd be familiar with the SDLC or software development life cycle. And generally speaking, this is a set of steps that are used by, software developers and project managers on a whole to kind of guide software development process. A lot of the times we omit security. Security should be considered at every step of this cycle. So you definitely want to do threat modeling as early as possible. You want to do continuous security testing and assessments. And while developing the application, you want to do code reviews and peer programming because your peers, your team, other persons on the team may see something and be able to identify a security flaw that you were not able to, and that's fine. Won't know everything, you probably won't remember everything. So that's why we work in teams because we are here to sharpen each other and catch each other where we fall. So these are things that you can bake into your process to ensure that you have as much coverage over the general security implementations as possible. As.net developers, it's always good for us to use the APIs that are given to us with the framework. For instance, for crypto development or for authentication and for data protection. Yes, you might need to extend to put in your own business rules and logic, but it's always good to start with them as the base because the.net Team, Microsoft, the open source committee contributing to.net on a whole are considering all of those exploitations and all of those considerations already. So by the time the version gets shipped, they have already considered scenarios that probably you and I may not have thought of. So going into the development life cycle, you want to start with a plan, of course, but always plan with security in mind. Then you may want to develop afterwards, develop with security in mind. We want to test, and testing is usually an ongoing thing. Even after the thing has been deployed and in production, they are still going to be testing. Testers should always be testing with security in mind. When we deploy, we want to deploy to a secure environment, and this deployment should not compromise the security that we have implemented from the coding perspective. And then finally, it's in production. Yes, it's out, but we want to monitor it to make sure that everything is okay. We don't want to just put it out there in the wild and leave it, monitor. And if there's a breach, if there's some exploitation that is revealed afterwards, we go right back to square one, plan, the mitigation, develop, and test, but always remember security at every step of the way. 5. Following the OWASP Standards: So now we're going to talk about OASP and it's probably something that you've seen if you've paid attention to the security spaces. If not, that's fine. But generally speaking, it is a standard that as developers, we should at least familiarize ourselves with it can help us to build more secure applications. So OWASP stands for Open Web Application Security Project. It's a global nonprofit foundation dedicated to improving the security of software, and it is one of the most trusted authorities and sources of information when it comes to application security. It has several projects, and these projects are usually the basis for secure coding standards, audits, and frameworks that are used worldwide by organizations like Microsoft, Google, and even the US Department of Defense to name a few. So what are the key projects of OWASP that you may want to pay attention to? OAS top ten, and this is the most well known project because it lists the ten most critical web application security risks. Now, the latest version was published in 2021, as at the time of this recording. You also have the OAS ASVS, which is the application security verification standard, which is a comprehensive checklist that is used to assess the applications compliance with secure development practices. We have the OAS Proactive Controls, which is a developer focused list, and it focuses on the top ten security techniques that should always be included in software. And we also have the OAS cheat sheets and tools, which are practical guides and utilities that help us to prepare our web application for penetration testing. And one of the tools is Zed Attack Proxy or Zap for short. 6. OWASP Top 10 for .NET Developers: Now, OWASP is an international and universal standard for security. But in this course, since we're doing secure coding for D, developers are going to kind of focus on how our framework best suits the OWASP standards. So many security frameworks and tools like Microsoft Identity, SP Det core data protection, security codes can map directly to OWASP recommendations. This means out of the box, when you are developing a Dt Net application, the packages that you have available to you that are Microsoft Issued are already built with OWASP standards in mind. Now, understanding OWASP helps us as developers to ensure that our C sharp code aligns with the industry recognized best practices. Because all practices are baked into that, it means that, well, we can just write code, and it will be taken care of. No, you still need to know what you're doing so that you can make the best decision because you can always write code that goes against best practices even when they are suggested upfront. So following OS guidance can make our code base more compliant with secure SDLC standards and regulatory frameworks like the ISO 2070001, GDPR or PCI DSS. Now, I'm not going to spell out what each of these compliance and regulatory frameworks are. You can research them, but they are applicable to different markets, different industries, and sometimes even different regions. A lot of the times we build an application and we say, Oh, we want our application to be used worldwide. But then when you even between US states or even between two different countries, there are different compliance and regulatory requirements that can make your application a hit in one place and a miss in another place because you didn't cater to that market. So it's important to understand these frameworks. You can go ahead and do that research and reading. But these frameworks all have a common goal generally, which is to protect the data of the constituents of either the region or the industry, like I said earlier. But also, sometimes things overlap, and sometimes you might need to go outside of that FIN diagram to cater to certain compliance and regulatory requirements. So based on your industry, based on your region, you want to understand what regulations are that you need to adhere to. Now, as Dt net developers, once again, OASP it's universal. It's not platform specific. It's very agnostic. But I kind of created the top ten, the of OAST ten to focus on how that top ten or those top ten requirements affect us as Dtnet developers. So, for instance, the first thing is broken access control, and we will be getting into more details of what each one of these means as we address them throughout the course. But as an overview, I just want to kind of give you an example of how you might end up violating one of these. So broken access control might be violated because you missed the authorized attributor didn't put the correct security policy in place for a particular part of the application. You also have cryptographic failures where maybe you needed crypt a bit of data, but you use the weaker algorithm rather than the current industry standards. There's also injection, which is caused usually by SQL injection, and that is a very common vulnerability, and it's very easy to fall into that trap if you don't do the right thing. Also have insecure design where you might leak the user existence in error messages. You might be giving too much information when giving an error. There's security misconfiguration, which once again, if there's an error, you're giving too much information or you're opening up ports that shouldn't be open. Also have vulnerable and updated components. It's important to keep our applications patched and update to the latest versions of whatever third party libraries we have to use. Identification and authorization failures, we're not encrypting passwords in our database, or we're not restricting how often somebody can try to authenticate with our application. There's software and data integrity failures, which are when we use scripts that we haven't necessarily verified or from unverified sources, and they might have malicious intentions behind them. There's security logging failures, we're logging information and putting sensitive information in those logs. So if somebody got access to those logs, they can see too much information. And then there's server side request forgery, which is allowing somebody to manipulate our system through URL inputs when they shouldn't be able to. Oh, this is the actual top ten. This is like a curated list or a more contextualized list of potential vulnerabilities based on the OS Top ten that we as.net developers might need to consider above all else. If you want to go to the source material to see what the OS Top ten documentation looks like or is all about, you can go there via osp.org slash Top ten SLASH then, well, this is the introduction page. But once you go to Top ten, you'll be able to navigate using the spill the right to the left hand side, sorry, and you'll be able to see the current release versus the release candidate. I did say that the most recent release, at least the current standard document would be dated at 20:21. And of course, as at the time of recording in the year 2025, there is a release candidate. I'm going to firstly focus on the current release, well, the current release is basically what we would have discussed mostly. And if you look, you'll see that the previous release was 2017, and these were the top ten security concerns. But what they did was they mapped some of them over to the 2021, and then they also introduced new ones. So for the release candidate for 2025, which they're making it very clear that it's currently a release candidate. If you scroll down, you'll see the top ten, and you'll get a similar diagram where they're showing you, well, what is mapped from 2021 over to 2025 plus what is new. So even if you look at what is new versus what is mapped over, you'll see that the general concerns basically remain the same. Maybe they would have changed the name or they would have converged one or two into the same security point. But at the end of the day, the security concerns remain. And then if you want to read up on what exactly each one entails and how it got into the top ten, then you can scroll down and you can read up and, you know, go in depth with your research and so on. So, of course, I will leave that additional reading to you. But next we're going to explore some common coding mistakes that lead to vulnerabilities. 7. Exploring Common Coding Mistakes: So let us widen the net a bit and discuss some common security flaws or coding mistakes that lead to security breaches. Well, one is hard coded secrets. So secrets can be things like API keys or cryptographic keys that are used in some sensitive operation in your application. Sometimes you hardcode them in our C sharp. Sometimes you put them in a configuration file. That's all good while it's on your computer, but once you put it on Github, expose it to the world in one way, shape or form. And even then even on your computer, it's still a huge risk to hardcode these secrets. There's also the idea of trusting user input. Once you have a form that you are asking for input from some end user, always assume the worst. Always assume that some attacker or some person with malicious intent will be using this form. And put in appropriate validations and sanitations to make sure that whatever the input is either of the highest, cleanest quality, and free of any violating characters or intentions. And if not, you bounce it back and let them know it's not acceptable. We also have ignoring exceptions. Now, exceptions can be very important, and if not handled properly, they can lead to leaks. So I don't know if you've ever used a website, and when you click on a button, you know, internal errors happen from time to time. But then you can see the exact line of code and probably even the code that run that caused the error. So that's where you want to make sure that your exceptions do not bubble up to the user level. You also have poor logging. So logging is a great way to keep track of what's happening in our application. But there's a lot of consideration that goes into what to log and how to log things that maybe are sensitive, but you need to have some semblance or some tracking of it regardless. So it's important to know how to write secure logs. We also have copying and pasting code solutions without proper context. So of course, we're all developers. We research what we need to do. We use our AI tools to help us to figure out solutions to things. But it's always important, no matter where you're getting that information from, it's always important to understand what the block of code is doing before using it, because sometimes we might not realize that there's something malicious in the block of code that we're copying or it's just not secure enough, and then we just copied and pasted a great loophole into our code. Also, when we are encrypting things, we want to make sure that we're using the appropriate APIs. We want to make sure that we're using third party packages and scripts with appropriate verification in mind. So these are common mistakes that we make as developers. As you get more experienced, you'll see them beforehand and mitigate them more easily. But even then it's important to be aware of them as early as possible in your career so that you can make sure you make the right decisions. 8. Secure Coding Principles: So some general principles that we want to adhere to when writing our applications include least privilege. You always want to limit the permissions. Persons should only be able to do exactly what they need to do, nothing more and well, arguably nothing less. We also need to make sure that we think about defense in depth. So we have layered controls. What are the different layers of our applications and how do we secure each layer. We also want to fail securely. So if something fails, you want to deny the operation by default. Only allow the operation if they have the security clearance. This is kind of very similar to least privilege. We also want to validate input. Anything coming into our system should be validated and vetted to make sure that it is acceptable and not going to introduce any security headaches for us. Also, you don't want to reinvent security. And I said this earlier. Use asp.net core issued or the.net core issued packages and libraries to handle things like identity, cryptography, data protection. It is better to rely on these from an organization like Microsoft and some reputable organization that would more than likely be following the OWASP pattern rather than to think it's better to build your own because you wanted to do this and that it's better to extend the existing one, so you're building on that already laid secure on. Another one is to encrypt data at rest and in transit. So when data is at rest, it's in a database, it's in a file, wherever it is. You want to put it in a secure or store the data in as secure a manner as possible because an attacker might just get access to one of those resources. If they do get that far into the when they try to interact with the resource, it should make no sense to them. So that is what we mean by securing data at rest. In transit, we want to use our SSL TLS certificates to encrypt the data going over the wire from one destination to another. We also want to use parameterized queries and input sanitation. This will help to mitigate against QUAL injection. We want to make sure that we're not logging sensitive data once again. And generally speaking, we go back to talking about the security at each layer. We're looking at something like this. The first layer is code. Then the code comes together to me the application and the framework and the infrastructure. You want to make sure that you think about security at each of these levels as much as possible to make sure that you have as many bases covered as possible. 9. Review: Now at some final words, as we wrap up our introduction to understanding common vulnerabilities and problem mitigations, most security breaches begin with a single line of insecure code. Understanding how and why software becomes vulnerable is the first step towards secure software development. So this section was designed to prepare you to think like an attacker and to code like a defender. Of course, we didn't write any code. We were just looking at it from a theory perspective. But now that we have an appreciation for what when somebody says, You code is not secure, I want a secure application. Now you have a full appreciation of what that means, where you can go to know what to and not to do. And generally speaking, how it might be implemented in.net. So thank you for joining me in this section. When we come back, we're going to get our environment set up and make sure that we're ready for the journey ahead.