The OWASP Top 10 is the most critical security concerns for web application security as defined by the Open Web Application Security Project® In the last episode, I introduce OWASP, their Top 10, why it matters and who it affects - as well as introducing the first three on the list. In this episode, I talk about four to seven of the list.
Or listen at:
Published: Wed, 08 Dec 2021 17:03:41 GMT
Links
- OWASP - Top 10
- #4 - Insecure Design
- #5 - Security Misconfiguration
- #6 - Vulnerable and Outdated Components
- #7 - Identification and Authentication Failures
Transcript
Hello, and welcome back to the Better ROI from software development podcast.
In this episode, I want to continue talking about the OWASP Top 10.
In the last episode, I introduced the OWASP Top 10 - the list of the 10 most important vulnerabilities to watch out for when developing web applications. I also talked about the first three of those vulnerabilities.
In this episode. I'm going to talk about four to seven.
And to go along with talking through those, I'll be using my example again I used in the last episode. So to reintroduce that example;
You've got your dream car. The car that you've always wanted, but you want to keep it safe - because you know that I want to steal it. Thus while you're at work, you keep it in a secure garage. This garage is protected by Arnold. He is a security guard. He holds your keys. You have to prove who you are to him to get your keys back using a password. We think that's secure, right?
Let's see how many more ways I can get your car from Arnold.
So, let's look at number four - Insecure design. Arnold is watching the front door. He's got a security post. He's ready to interrogate anyone that comes in making sure they are who they say they are and that they're getting the right vehicle. Unfortunately, the side door is open and unprotected, so I walk in there, get the keys, drive off of your car.
OWASP described this as:
Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation.
So would you consider your house secure if you only locked the front door? Obviously, no. That's almost too obvious that you make sure that the back door, the windows, everything else is locked so that your house is secure.
Unfortunately, it's not so obvious when you get into complex software development. You need to make sure the team are thinking about how they design and architect their systems, that they're educated in various ways that it could be exploited. And they need to be allowed time to consider the potential vulnerabilities.
It's not just about protecting the front door, as Arnold is doing in the secure garage. As I talked in episode 107, you want to look at things like Zero Trust where you don't trust anything - you're making sure that you're protected, not just at your borders or your boundaries, but also further in.
You want layers of security.
And we can use techniques like Penetration Testing, Bug Bounties, Red Team/ Blue Team exercises, as I discussed in episode 108, to help highlight potential problems, to help highlight potential weaknesses in our secure design.
No matter how good Arnold is, if the garage is purely designed, then it's not going to be secure.
Ok, let's move on to five: Security Misconfiguration.
There's a mistake in the rota. Arnold is half an hour late in. There is nobody manning the desk. I walked straight in. Take your car keys. I take your car.
So from a technical perspective, this often comes because we've inherited defaults, which we've not removed. Maybe the service we're using, or the product we're using, has well-known default passwords and we've not removed them.
We've not locked them down.
Maybe the service we've got have come with a sample application that we haven't removed - that sample application is okay for experimentation, but isn't built to the relevant level of security to stop it being exploited.
In the early days of Web hosting, many Web hosting providers came with control panels that allowed easy administrator access. Lots of power, but often with very easy or default passwords or insecure design.
Again, the fix for this is very similar to that Insecure Design - you need to review what you have, you need to make sure that your team is educated to look for things and you need to go through those review exercises: the Penetration Testing, the Bug Bounties, the Red Team/ Blue Team exercises to highlight them - so you know they're there.
In the case of where you're taking services, you should also look for best practise documents on how to harden them. Again, a security piece that needs to be gone through with the team to make sure that they're reviewing and knowledgeable on these subjects.
Ok, let's move on to number six, Vulnerable and Outdated components.
Unknown to you, Arnold has a shady past.
He's been involved in multiple frauds and theft. He's been fired for taking bribes in previous organisations. Unfortunately, the owners of the garage haven't checked this out, haven't seen his past problems.
But there's a known vulnerability there. He's open to a bribe. All I need to know is just how much it's going to take for him to let me take your car.
Technically, this occurs because we aren't patching the systems we depend on. I recommended patching as a first thing to do in episode 104.
It can also occur when we're using vulnerable third party components, as I discussed in episode 110, when I talked about supply chain.
Vulnerabilities and problems do occur in software and are found on a regular basis. If we're not keeping up to date with those in our usage, if we're not using them quickly and getting them into place quickly, then we're taking a risk.
We have a much larger window the longer those vulnerable pieces of software stay in place.
So to fix we need to make sure that we're patching and regularly making sure that we're using the most up to date software. We need to make sure that we have the processes in place to do things like audits to tell us which software has known vulnerabilities, which software is out of date.
And to do this, it really helps if we have the processes like the Continuous Integration, Delivery and Deployment that I talked about in episode 19 to 21 - the automation here gives us the ability to move quickly. It gives us the ability to apply changes quickly.
Otherwise, we find the manual effort will normally make this too much effort for little benefit and difficult to justify. We really need to make sure we've got those fundamentals in place to make sure that we're in a position to be able to move quickly and adapt and get these patches and security vulnerabilities out quickly so that it becomes a common standard practise.
Let's talk about seven, Identification and Authentication Failures, also known as Broken Authentication.
I walk up to Arnold. We talk. We have a nice chat. I asked for my keys. He gives me your keys. I walk off, I take your car.
He's not checking the password. He basically is waving me through. He doesn't check that I am who I say I am by using that password feature.
From technical examples, you may see this in things like credential stuffing, where an attacker will try a known list of passwords, not necessarily the right one, to gain access to a system. They will repeatedly attempt a whole list of passwords and potentially usernames to gain access. Computers are great at automating repetitive tasks, and that's what they're using. They can provide it a massive list of potential passwords, potentially exploited ones that are available on the dark web.
Or they could just be randomly generating those numbers, those passwords and making repetitive attempts to log in. This would be like Arnold letting me continue to guess your password all day without questioning it.
Another technical example is how long you're allowed to stay logged in. So, for example, my bank will actually log me out after five minutes of inactivity. This is a security procedure so that if I'm away from my computer, that somebody cannot just log in because I'm already there - especially if you think about what would happen if this was a shared machine.
So how do we go about fixing this?
Authentication can be complex, and this is what I talked about in episode 107 - Beyond Passwords.
I recommended in that using a service provider that actually understands how to manage passwords properly. They quite often implement complex logic like maximum number of log on attempts over a given period. They can implement things like multiple factor authentication. They actively work to implement current best practise so you don't have to.
So in this episode, I've covered four to seven of the OWASP Top 10: Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components and Identity and Authentication Failures.
In next week's episode, I'm going to finish off the Top 10 by talking about number eight to number ten.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.