The OWASP Top 10 is the most critical security concerns for web application security as defined by the Open Web Application Security Project® In this episode, I introduce OWASP, their Top 10, why it matters and who it affects - as well as introducing the first three on the list.
Or listen at:
Published: Thu, 02 Dec 2021 08:21:24 GMT
Links
Transcript
Hello, and welcome back to the Better ROI From Software Development podcast.
In this episode, I'm going to introduce you to the OWASP Top 10 - I'll cover what it is, why it matters and who it affects. And as a list of 10 items, I'll cover the first three in this episode with the subsequent seven over the next two episodes.
So let's start with who is OWASP. From their own website, they describe themselves as:.
The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.
• Tools and Resources
• Community and Networking
• Education & Training
They go on to describe the OWASP top 10 as:.
The OWASP Top 10 is a book/referential document outlining the 10 most critical security concerns for web application security. The report is put together by a team of security experts from all over the world and the data comes from a number of organisations and is then analysed.
OWASP refers to the Top 10 as an ‘awareness document’ and recommends that all organisations incorporate the report into their processes in order to mitigate security risks.
So in short, this are the top 10 list of things to watch for when you're developing web applications. Many of these actually also apply to other types of applications. So they're a useful thing to know about. The list has been worked on for many, many years, and they've just released the most current version, prior versions were back in 2017 and 2013 - and I think the ones prior to that - but they've been working on this for some time to try and raise awareness of common security vulnerabilities, common mistakes that software development teams and companies make in their web application security.
I've certainly heard people describe these as mandatory requirements for any web developer - almost saying that they're not a real web developer if they don't understand all of these.
Personally, I don't think it's appropriate to put that onus on the individual.
Yes, all of these security vulnerabilities should be something handled by the team - should be something handled as part of the process. Certainly every single developer that you have should be allowed to learn and made aware of all of these. But the responsibility for making sure that the software produced is free of these vulnerabilities is the responsibility of the team, the organisation - the practices and processes to support the development team need to be there.
Now that can be delivered through various sets of eyes on the code - lots of people looking at it and making sure that those vulnerabilities don't exist - or using third party tools or, more importantly, probably a combination of things.
But what I wanted to be clear is this isn't something that is the sole responsibility of an individual developer. Relying on an individual developer, almost certainly will mean that you make mistakes.
One thing you might think as we go through some of these examples is it may seem obvious - and yes, some of them are.
But it doesn't stop people making these mistakes over and over and over again, especially when the focus is on hitting deadlines. If our priority is hitting deadlines with certain features, certain items to be delivered by certain date, often security falls by the wayside.
Many of these problems have been around for a long time, but we still have failed to remove them. When we get onto number 3, injection attacks, this has been almost the canonical example of vulnerabilities and was at number one for probably the last two, if not three OWASP report. Yet even with most software developers being aware of it, it is still prevalent.
It has still only dropped recently to number 3 - Yet we've known about it forever.
So, yes, while many of these things may seem obvious, we need to make sure that we've got the practices and processes in place to make sure they aren't sneaking into our software. Almost because they are sometimes so obvious, people don't look for them. People don't think about them. So make sure the practices and processes and the team are aware of them so that they can be picked up before they go into production software.
To help explain these vulnerabilities, I'm going to work through an example;
Congratulations. You've just bought your dream car. That car that you've been after since you were a kid. You've spent the money and you've got that wonderful, wonderful car.
But I quite like that car and I want to steal it.
And you know this. So to keep it safe while you're at work, you park it in a secured garage. It's just down the road from where you work, it's great. This is a security guard that you've met Arnold. You park the car up. You gave him the keys. He keeps the keys in a safe place. You have to prove who you are to get those keys back from him. You have to give him your password. That's secure, right?
No way on getting hold of your prized possession. Let's see.
Ok, let's start with number one in the top 10, Broken Access Controls.
Broken Access Controls is where it's mixing the idea of authentication versus authorisation. Authentication is where we're proving who I am. Authorisation is where I'm allowed to do what it is I'm trying to do.
So let's take our example with Arnold. Now, I've taken advantage of their free trial to store my bicycle in their garage for the day. Arnold knows I'm using that free trial. He knows that I'm allowed to use it for the day.
Thus, when I come back in later in the day to pick up my bicycle, he performs his authentication check. He asks me my password. I give him it. I'm authenticated, however, because he's they're not checking what I'm then authorised to do, I then take the keys for your car and I drive off of in it - probably after I put my bicycle in the boot.
Your car gone.
So what's happened here?
Arnold has done the right thing in terms of the authentication. He's validated that I'm a valid customer. He's checked me against his list. He's checked his passwords.
What he hasn't then done is made sure that what I then subsequently do is appropriate for who I am.
So he's proved that yes, you're a customer of us, even if only on a free trial today, you are a customer. Yes, you are allowed to use us.
What he hasn't then gone on to do is actually make sure that when I go to take your vehicle, that I'm authorised for that vehicle.
And I've had experience with this with a company I worked with in the past.
They'd had a junior developer build a B2B site. It was used so that partners could track orders. But the URL actually had the partner number in it. So in the address bar at the top of your browser, it had their number in it. So once you actually logged in, you could just change that number and you could see other partners details. You could see other partner's critical information and their orders.
And it's exactly the same as what Arnold is doing.
The website was authenticating me first as a user, but once I was a user on the site, it then didn't make sure that I was authorised to see all of that data.
To fix, we need to make sure there's more controls. We need to make sure that we're checking that I'm authorised to take your car - or in the case of the website to make sure that the logged in user is authorised to see that relevant data.
Ok, let's move on to Cryptographic Failure, also known as Sensitive Data Exposure.
Let's say, for example, that the names and passwords that Arnold used to validate the customers is written on a whiteboard. Now, unfortunately, they've placed this whiteboard directly behind Arnold. So when I walk up to talk to him, I can see the passwords. So I walk up, I give him your name, your password. He gives me the keys.
I take your car.
In practice, this is about not providing the correct level of security and encryption of sensitive data. Possibly not encrypting data even in transit or at rest.
If we talk about encryption in transit, I imagine you're using a hotel WiFi - now, potentially the reception has access to the computer equipment that you're connecting to. Potentially if you do not have encryption in transit, they can see all of the traffic that you are carrying out over the WiFi. So whether you're watching films or going on your bank account or doing any other activity, they have the opportunity to be a man in the middle.
Think about this a bit as a Postal Service in terms of if you didn't seal the envelope, the postman can take your letter out, and read it as it's going through that transit. They can act as that man in the middle by examining information as it goes through.
By having encryption in place so that only you and the destination can read the message, then you protect yourself against the man in the middle of attack. Yes, they will see streams of data, but because it's encrypted, they won't be able to understand it.
Now, encryption at rest is about protecting sensitive data when we store it. So, for example, if we've got credit card data or passwords, we want to make sure that we have that extra layer of security so that if for any reason our servers are compromised and the files are stolen, that the data is encrypted and cannot be accessed by the attacker.
So to fix this, we need to ensure that our sensitive data is first understood - where is it? What is it used for?
In the case of Arnold and his white board, we need to understand that the data on that is exceptionally sensitive. They are the credentials for somebody to be able to authenticate themselves and then authorise the ability to take a vehicle. These are sensitive.
We need to ensure that they are appropriately secured, both in transit and in rest.
In this case, we certainly need to find a better way for Arnold to store those names and passwords. They most certainly should not be visible to somebody just walking up to Arnold.
And in our systems, we need to make sure that we use an appropriate levels of encryption, both in transit and in rest.
Ok, let's move on to number 3, Injection.
Historically, Injection has been the number one - as I said earlier, it's only now falling to number three. Many systems and libraries provide functionality to protect us and our software - yet it still keeps happening - which is why it's still at number 3, even though it's been at number 1, probably for the last 10 to 15 years.
So let's equate this to our Arnold example.
Let's say I've turned up wheeling a really large box. I apologise to Arnold when I say "Oh, Arnold, I'm so sorry. I've got the wrong garage. My garage is down the road, but this box is so huge. Do you mind if I leave it with you - somewhere secure please, because it's valuable - while I go and get my car. And I'll come back and pick it up in a couple of hours?"
Now Arnold's a great bloke.
He knows that he's seen me struggling with this box and he goes "Not a problem. I'm quite happy for you to leave the box here. I'll put it in a secure place and you can come back and pick it up."
I thank Arnold, he's a great bloke. He takes the box through security and puts it there and returns back to his post. Arnolds happy, he's helped someone out.
Unfortunately, my brother climbs out of the box and takes your car.
For websites, the canonical example is not correctly reading user inputted information such as a username and password. If not done correctly, it can be used as a way of "injecting" an attack that allows them to gain access.
If you think about the security of your website being a username and password, when it does that look up against a database to see whether you've entered the right username and password, it effectively goes: "Is there a record that has this username with this password - Yes or no?".
By carefully crafting, maybe the password, you can change it so that effectively the computer runs a second instruction. So it doesn't matter what you put in the username password, you're effectively to tell it to return "true". And this is well known exploit.
But it isn't just about usernames and passwords.
So, for example, you may be operating a site for uploading cat photos. What are you doing to stop someone uploading malicious software to it?
Again, we need to be making sure that we are sanitising anything we receive from users or third parties to make sure that it is correct and not malicious.
So how do we fix?
We need to treat every input with suspicion.
Anything that is coming from outside of the system, whether that be from a customer, a partner, or even our own staff, we need to treat with a level of suspicion and we need to sanitise those inputs. We need to make sure that they are not malicious.
The good news is that most development platforms provide that functionality built in. Most of them have had it added for years, and they're battle tested and they work very, very well. So just by using the features of most developed platforms, we can probably protect ourselves against these attacks. We just need to one know they're there and to trust that they work rather than trying to roll our own.
In the case of Arnold, he really needs to learn to only perform the allowed actions he's meant to do. He's meant to be protecting your car, not acting as a storage depot.
Ok, in this episode, I provided a summary of the OWASP Top 10 and covered the first three. In the next week's episode. I'll cover four to seven.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.