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 two episode, I introduce OWASP, their Top 10, why it matters and who it affects - as well as introducing the first seven on the list. In this episode, I talk about eight to ten of the list.
Or listen at:
Published: Wed, 15 Dec 2021 17:16:13 GMT
Links
- OWASP - Top 10
- #8 - Software and Data Integrity Failures
- #9 - Security Logging and Monitoring Failures
- #10 - Server-Side Request Forgery (SSRF)
Transcript
Hello, and welcome back to the Better ROI from software development podcast.
Over the last two episodes, I've been talking about the OWASP Top 10 - the top 10 most critical security concerns for web application security as defined by the Open Web Application Security Project. In those two episodes, I've given you a summary of it and talked about number one all the way up to number seven.
In this episode, I'm going to talk about eight through to ten and close off the subject of OWASP.
Ok, let's also recap the example I'm using along with this. So you've got your dream car, you've wanted this car the entirety of your life, you now have it, but you also know I want to steal it. So to keep it safe while you're at work, you keep it in a secure garage. You store it with the security guard Arnold. He holds your keys and you have to prove who you are to him to get those keys.
Secure, yes?
We're starting to wonder about that, as I've managed to use one to seven so far to steal your cars. So let's see, how will I do with eight through to ten.
So number eight, Software and Data Integrity Failures.
I ring Arnold pretending to be his boss. I tell him the password needs to be changed for your car. He updates his records. Five minutes later, I walk in and use that new password. I in, your car is gone.
Arnold has not verified the source of this change. He hasn't verified that it was his boss on the phone or that indeed his boss was even authorised to make the change without your consent.
At this point, this is starting to sound very much like the Supply Chain attacks I talked about in episode 110. OWASP even reference the same SolarWinds attack that I referenced as part of this. Solarwinds did not have the controls in place to identify the loss of integrity and thus became an attack vector into many of its customers.
So the fix; we need to verify whenever possible.
For Arnold, he really need to verify the change was correct and authorised.
For software, we need to verify that the software libraries and dependencies we rely on are valid and they've not been tampered with.
Number nine: Security, Logging and Monitoring failures.
Now, this is slightly different for me. It's not having the relevant awareness to identify if an attack is in progress or the ability to review it after the event.
So, for example, if I'm trying to steal your car, it's Arnold not questioning why I keep attempting, but failing to pretend to be you. Maybe he's blocked a number of the previous attempts, but he's not realising that I keep trying. Maybe I've tried once per shift, and he's not keeping appropriate records to realise that is a sustained attack and a sustained attempt to take your car.
Or maybe it's not having any CCTV to provide the police after I've stolen your car.
So the fix; we often don't know we are missing something until we need it. But trying to fix the broken CCTV after I've stolen the car, it's too late. The damage is done. All we can do is learn from it.
And this is why proactive testing methods that I mentioned in episode 109 are so valuable. Using Penetration Testing, Bug Bounties, Red Team/ Blue Team exercise help provide the experience of failure. Help to educate us on what we're missing - what isn't working, what CCTV cameras need fixing - so that we gain that experience without actually having the financial and reputational impact of a real attack.
And finally, number 10: Server Side Request Forgery.
This is where the server can be coerced into giving away something it has access to. So, for example, on the website, maybe the website can be coerced into giving away privileged information, such as what else is on the internal network, or it can be used to attack or disrupt internal services on behalf of the attacker.
Maybe with Arnold, maybe we can convince him to expose the password list. Maybe we pretend we're auditors.
Or maybe we can convince him that it's a generally correct for him to drive the car out the garage and deliver it and the keys directly to us.
When it comes to fixing these things, many of the principles of the Zero Trust that I introduced in episode 107 can help us here. Even if the webserver or Arnold can be coerced into thinking it's a valid request, there are other controls there to stop it.
Security really should be thought of as an onion. It should be multi-layered - multi levels of defence. So even if we can coerce one part of the system, if we can get past one control, other controls kick in.
Ok, so that's covered the OWASP Top 10, but I wanted to take some time just to go back over the responsibilities around this.
I've heard it described previously as capabilities defend against the OWASP Top 10 as being mandatory requirements for web developers.
Personally, I think that's wrong.
The danger here is we seem to be putting the sole responsibility for these security efforts onto the web developer - onto the individual.
That, for me, is not fair. It's not appropriate.
Most of web developers, while certainly should be aware of these, it isn't their responsibility to protect the organisation. Rather, the team and the organisation as a whole has a responsibility for making sure that the software they produce is safe and secure, so should be the responsibility of the team and the organisation that the OWASP Top 10 are considered as part of any software that's being developed.
So, for example, the organisation should put weight on these Top 10. Should put weight on any security effort. They shouldn't be prioritising feature development and getting it out over making sure that systems are secure and safe. We need to make sure that our development teams have the processes, the practises and the authority to make sure that they can protect the organisation from these types of security attack.
Yes, the individual developers should have an opportunity to learn about the OWASP Top 10 and basic security principles. They should be provided the training. They should be provided the knowledge. They should be assisted in understanding. That's definitely a case, but it's a responsibility that I'm conscious of here.
We need to make sure that the development team are supported - in that we need to make sure they've got the relevant tools, they've got the relevant buy-in from the organisation to have multiple eyes looking at the code.
We cannot treat the team as individuals and expect them to handle this. They need to be working in the right environment.
In this episode, I've closed out the OWASP Top 10, the top 10 of critical security concerns for web application security. It isn't the only list out there. There are other lists out there as well, but this is probably the most well known for web application security and certainly should be something that is being looked at as part of any software development process.
Over the last three episodes, I've talked about each one of those one through to ten - providing an example - potentially contrived in some cases - but hopefully giving you an idea of what that security concern looks like, both from a technical concern and from a real world concern if you were going to apply it to a different context - hopefully making them understandable as to why they're critical for your software development processes.
I really appreciate any feedback on this approach. Has it helped the way that I've delivered this? It'd be great to hear your thoughts on the subject, and certainly if there are further questions that you want me to dive into.
Thank you for taking the time to listen to this podcast and look forward to speaking to you again next week.