Chris and Robert -- Controversy within the OWASP Top 10 RC

0:05Chris RomeoThe Application Security Podcast. Here we go. On this episode of the Application Security Podcast, Robert and I jump over a wall. Just kidding, this isn't Top Gear. This is Chris Romeo, and this is our 2nd episode of the Application Security Podcast for season 2. And in this episode, we talk about the OWASP Top 10 2017 Release Candidate. We walk through what is the OWASP Top 10 and also what is some of the controversy that lies in the things that are being added to OWASP Top 10 for this year. Please give it a listen. So today's episode, we're going to talk about the OWASP Top 10, what I think of as the most prolific, well-known document in the world of application security. And so Robert's here with me and we're going to unplug kind of what does this thing actually mean. Robert, how long have you been working with the OWASP Top 10?

1:25Robert HurlbutI want to say at least around 10 years or so since it came out. I can remember many times back in 2003 or so when this came out that I was working with— on a web application and doing some security and so forth and taking a look at it and trying to understand it. And then over the years, just talking with different groups and conferences and so forth, but mostly user groups just talking about OWASP Top 10. What is it? And I always ask that question, do you know what the OWASP Top 10 is? And of all the things out there, as you said, it seems like this is the one that many people, if they don't know what's in it, they certainly have heard about it.

2:08Chris RomeoYeah, well, just in case somebody listening to this podcast has been hiding under a rock for the last 20 years, the OWASP Top 10 is they— what they refer to as the top 10 web application security risks that exist. And they create this list— they don't just get a bunch of people into a room and, and decide on the list. They pull data from various testing tool vendors and various companies that are kind enough to share their vulnerability data as far as what they find from either their human process or their tool-based process, and then they can take all that information and combine it together. And that's really what they use to decide what pieces go into this and what are the— how do we change and add new things to this picture. So I think that another thing for us to think about here is, now that we've kind of provided a definition for this, people tend to think that the OWASP Top 10 is only for web people. Robert, have you ever encountered that, people with that type of attitude?

3:17Robert HurlbutI have, and I've even seen it in some tools where it seems that primarily if you have a web application, the tool is looking for the OWASP Top 10, applying it to a web application and not really to anything else. Yeah, I have seen that, heard that, where it seems like it's the only thing it's for is for web.

3:38Chris RomeoYeah, and I want to, I want to bust that myth because I think that there is a lot of value in the OWASP Top 10 for anybody who's doing development. Sure, a couple of the items, and when we go through them and look at them individually, we'll discuss the ones that are web-specific, but for 7 or 8 out of 10 of these, I think there's applicability to the C programmer, to the Ruby programmer, Python programmers. These, these are concepts that you can apply to any type of codebase that you're working on.

4:10Robert HurlbutYeah, definitely. I agree.

4:11Chris RomeoOkay, so I think it'd be good for us to provide our listeners with— those that may already know the OWASP Top 10 will have a better understanding for when we talk about the changes here. But I guess one of the important things to do is OWASP Top 10, it doesn't get updated every year. This is something that's updated every 4 to 5 years. And they're right in the middle of this process right now of doing the 2017 update. And so the document that we're looking at and talking about right now is what they've referred to as Release Candidate 1. So instead of just releasing this thing to the public, they created a draft, you know, releasing it as final, they created a draft and pushed it out to the world and said, okay, let's let everybody throw stones and bottles and cans and whatever else they want at this. And there's certainly been a lot of interesting dialogue going on, Robert, wouldn't you say?

5:08Robert HurlbutDefinitely so. And the last time this came out was in 2013, and so it has been a few years since this was released. But yeah, when this came out this year, early this year, 2017, I remember on Twitter the day that it came out, and right after that, yeah, quite a bit of discussion, conversations about it almost immediately.

5:32Chris RomeoYeah, and we'll break down each item on this list individually, and we'll talk about the controversial one when we get there. We'll save that for, for the breakdown conversation. So just looking at the document here, they did a really nice summary of what's changed from the 2013 version to the 2017 version, and the first big thing is In 2013, they had actually— the previous version before 2013, they had actually broken 2 of the items that they had referred to then as broken access control into 2 different separate items. One was insecure direct object references, and the other one was missing function-level access control. So what they've done for 2017 now is the Code has moved far enough along now and they've gotten the right effect that they were trying to do by adding those in. They've merged those 2 back together into A4. So A4 and A7 from the 2013 edition now becomes A4, just A4 in a single item in 2017.

6:36Robert HurlbutRight. And it looks like from the document that that was the original category in 2003, 2004. So just going back. So that makes sense. That makes sense.

6:46Chris RomeoYep. And then so with that, that left them one open spot in the glorious top 10 here. And so they added this A7, insufficient attack protection. And what they're talking about here is the need for self-defending applications. And this is the idea that you should add some type of library or component or instrumentation that runs inside of your application and it's watching for attacks and it's able to deflect attacks and things in real time. And so that's kind of the idea of what they're talking about there. We'll dig into the issues of the— or the challenges that that poses here in just a second. So Robert, the other new one that they added was underprotected APIs. I guess, are APIs, do they tend to be unprotected, underprotected?

7:39Robert HurlbutI think so. I think so, especially if there's no security at all. There's a lot of APIs that may be out there that are just wide open. They might protect and put something on the client, but the APIs that are being called by the client, by a browser, for example, internally may not be protected at all. So I think that's a valid one.

8:01Chris RomeoYeah, and then the last one that they dropped, they had to drop, they added 2, so you got to drop 2. you don't have a top 10 list anymore. They took out what was 2013 A10, unvalidated redirects and forwards, and they basically said the data doesn't show this as being as prevalent as they had expected, so it didn't make the cut this time around. I think that raises an important point for folks to know is that the OWASP top 10, things get added into this in the hopes that there'll be change across the industry. And CSRF, cross-site request forgery, is a perfect example of the power of OWASP Top 10. So CSRF, when it was first added into the Top 10 lists, you had to, you had to code up your own tokens and things to, to be able to prove valid sessions and, and not allow somebody to take over an existing session. And now what we see is those CSRF tokens, they're built in everything these days, right, Robert? I mean, they're in .NET, they're in Java, they're in Ruby on Rails has got it built in. So you don't have to work that hard. But that's the result. I got to say that if TopOS Top 10 had not added CSRF and drew all the attention to it, I don't know that we would have all those protections in a framework today.

9:20Robert HurlbutYeah, I agree. And like you said, in my experience as well, I see lots and lots of frameworks now that have this. And when I speak about this, I always say Check your framework. More than likely, you already have this now built in. You used to have to build it yourself. Now it's built in, so use it, learn it, understand it. So yeah, and again, that's the value of a document like this that has made it understandable to people, and they've taken some action on it. So it's great.

9:48Chris RomeoYeah, and the comment period is still open on this thing right now. So if you're listening to this podcast, in the middle of 2017, you can still go out, grab this document, read it, and submit any comments that you might have about what you see, what's been added, what's been taken away. So, there's definitely an open window for influencing this document with good rational comments.

10:14Robert HurlbutRight. I believe it's mid to late June is when they're— or even July that they're closing this.

10:19Chris RomeoYeah, I think it's June 30th, 2017 is when the comment period closes and then I just read on the site today that they're thinking either July or August release of the final version of this document, which—

10:32Robert HurlbutExcellent.

10:33Chris RomeoYeah, will be huge. So let's take a walk through these 10 and just real quickly in a minute or two kind of expose what each of these items are for folks. And you know it's OWASP, so you can just go to the website owasp.org and download the document and read it yourself, and there's a million things posted about it. But let's just do a quick kind of summary, a little faster on some, maybe take a little more time to explore some. And first one is A1 injection. So I like to joke, I use this joke all the time, but, you know, I'm not— I tell folks I'm really not that concerned with the OWASP Top 10. I think we need to just focus on the OWASP Top 1.

11:13Robert HurlbutHmm.

11:13Chris RomeoAnd being if, if we were able to erase SQL injection from the planet Earth, then, I mean, imagine how many data breaches would go away if SQL injection was completely taken away. And there's been a lot of good things that have happened to combat SQL injection, but I think injection is still in the right place in that number 1 seed or number 1 spot here on the OWASP Top 10. Right.

11:40Robert HurlbutAnd I still hear people say to me, I can't believe it's still number 1, but it is. I mean, there's lots of sample code out there. There's lots of people that are still doing it. So it's still going to It's still one and still going to be one for a while.

11:52Chris RomeoYeah. And injection is really— the A1 injection is not even just SQL injection, right? It's OS command injection. It's LDAP injection. It's untrusted data is being sent to an interpreter of some form, and that data is being messed with by the attacker to generate or create an attack that then gets executed through the normal command processing. SQL injection is where we see it, it's where it sticks out to us, but that's not the only place that it can exist.

12:21Robert HurlbutRight.

12:23Chris RomeoAll right, Robert, number 2, broken authentication and session management. You're trying to tell me that authentication— everybody doesn't just nail authentication?

12:30Robert HurlbutWell, you'd like to think that they get it right, but they don't. And sometimes I know I've seen where either authentication is not handled correctly or it's misunderstood with authorization. Then also included there is session management and how is that handled in terms of passwords and keys and tokens and how are those managed and how are those represented. All those things can be a little bit complicated and because of some of the complications, you see those problems creep up in applications where they just haven't been implemented correctly.

13:09Chris RomeoYeah, and I think this is, uh, I mean, frameworks are part of this as well, right? So like, if you're going to develop a new application today, I can't imagine anybody needing to make their own authentication and session management function right now. I mean, I can't even think of a use case why you would want to do that.

13:27Robert HurlbutRight, right. There's, there's lots of libraries, lots of things in frameworks that already are provided. A lot of work has gone into them. And it would be best to learn them, understand them, use them. And that's, that's what's trying to address this issue, just to make sure you don't have those kinds of problems in place. Yeah. Yeah.

13:47Chris RomeoAnd so A1 and A2 that we just described here, I would say both of these are applicable to any type of development. You can have injection attacks that you can write C code that opens up the door for an injection attack. It may be in a command injection. It's probably not going to be a SQL injection if you're writing in C, but it doesn't mean that that's not something you have to worry about.

14:11Robert HurlbutRight.

14:14Chris RomeoSo cross-site scripting is A3. This is the idea that somebody, an attacker, is actually going to get some form of data. They're going to put data into a system and then get the system to output it without realizing that there's actually an attack embedded in it. And so for example, somebody can try to— I mean, there's a stored cross-site scripting attack, right? And this is the idea where somebody places JavaScript into an input field on a form and gets that JavaScript to be saved in a database. And then the next time that that website goes to display all the entries it has in its database, that JavaScript is executed inside of the victim's browser. And so still a very prevalent problem. I think frameworks help us some by enforcing input/output validation or output encoding and input validation, but still something that I think we've got to worry about today.

15:14Robert HurlbutRight, and there's content security policies, there's other things like you said that, that can help you with this, but you still have to be careful about it. I mean, this is one that is very specific to web as we talked about. Some things don't always apply to web or only to web. This is one that's very specific to web, but again, it's a very common thing. If you have an XSS, just one XSS problem on your website, it's almost game over because there's so many other things that you can try that with an XSS flaw you'll be able to circumvent. So very, very important to get this right. Yep.

15:52Chris RomeoAnd then A4 is the broken access control. This is like we said before, this is just combining 2 other things into this idea that applications, if you don't have a policy and a setup for how you're going to handle who's allowed to access what pages, who's allowed to access what data, that's going to be a big challenge. So the idea here is you have to have an access control approach or design and then you have to implement that throughout your application. Frameworks, I think, help here as well, right, on the access control side?

16:24Robert HurlbutThey do in terms of trying to provide a way to manage either through role-based access of some sort or even better, claims or capability access. If you can set up some system to manage those, and use some frameworks and libraries that would help you with that, all the better.

16:46Chris RomeoYeah. Yep. And yeah, so that's access control. I mean, really the big thing you need to do in the world of access control is it has to always be implemented. That's what gets people into a lot of problems is that there'll be some random page and since they don't have a uniform access control policy applied across the entire application, they'll have one page that they forgot to implement the access control capability into. And even though it sits inside of an admin directory and should technically be part of the admin interface, that one page could suddenly be exposed. And so that's what I think of when I think broken access control is you don't have a uniform approach to how you're going to protect the resources that exist within the application.

17:30Robert HurlbutRight. And so, yeah, in that case, what I also see is that it's that kind of a blacklisting approach where I'm only going to I'm going to explicitly say what things are, let's say, set up for admin instead of a whitelisting, which says everything is locked down until I allow access. And so, you know, that sort of thing is what also causes broken access control as well.

17:55Chris RomeoYeah. And then so A5 and A6, let's talk about these 2 kind of together. So A5 is security misconfiguration. This is the idea that you that to have a solid application, you have to have scripts and things that assist you in the deployment. You have to have a standard approach to deploying. And I think we're actually getting pretty good at this one right now. With all the— with DevOps taking on the industry here and coming into such a prominent place in how software is being built now, I think DevOps takes away a lot of that security misconfiguration and I wouldn't be surprised to see A5 go away in the OWASP Top 10 2020 edition.

18:37Robert HurlbutHopefully, hopefully. I mean, there's still, I think, some room for potential error, but yeah, I think you're getting— you're right, we're getting closer and closer to getting this established and automated, and anything that's automated, and if you can at least verify it, and then it's set in place, it's going to help you. And I think this is one that you— is a big win with automation and all the DevOps procedures that we have seen in place, put in place lately.

19:04Chris RomeoYeah, the A6 is sensitive data exposure. This is the idea that you are not— your application or your API is not properly protecting sensitive data such as PII, personally identifiable information, PHI, personal health information. This is just a general thing. I think the answer to this one has always been encryption and using proper cryptographic techniques within a given application. Once again, I come back to frameworks and saying that somebody's trying to create their own crypto scheme, run away as quickly as possible. Don't talk to that person ever again because crypto is something that nobody should ever try to kind of figure out on their own. It's about using standards, using existing frameworks to protect that sensitive data.

19:51Robert HurlbutMm-hmm. Right, and this doesn't apply again only to web. It applies to lots and lots of applications. Anywhere that you're saving data either at rest or in transit, how are you making sure that data is secure? How are you making sure that data is protected? And so again, like you said, using frameworks, understanding the algorithms, you don't invent your own, those types of things I think are good solutions. Yeah.

20:20Chris RomeoAll right, so here's A7, the first new one to the list here. This is insufficient attack protection. And like we said already in this conversation, that this is one that's really drawn a lot of controversy in the industry. And so this is the idea that the application should have something within it to help it detect, log, respond to, and even block security attacks that are happening. Because security, the way we've approached it for the last 20 years, as long as I've been doing this, is security from the information security side has been about putting devices, some level or some number of metal boxes with network interfaces that provide all of the protection that we need, whether that's DDoS protection, which then feeds to my firewall, which then feeds to my IPS, which then feeds to something else and something else. And so this is the idea that some of that protection capability has to be brought into the actual application itself, which I actually believe in this because when you think about trying to do things at scale, that's one of the things that I learned over as I've kind of had a chance to explore some very high-end or high-performing websites that are passing, you know, gigabits of traffic per second, there's not enough firewalls in the world to keep up with a site that's pushing gigabits per second of data consistently throughout all the time. So you've got to have something else to do security there, and I think that's what insufficient attack protection is trying to do.

22:01Robert HurlbutYeah, so like you said, some kind of inherent in the application itself understanding some attack patterns, understanding what's happening, and getting real-time understanding of what's happening with your application so that as it's running, I could think of, for example, out of OWASP, there's the AppSensor that does this kind of thing as well where you build it in and it can detect certain things. That's what we're talking about, is just ways of building in detection of patterns that may be seen in the code, and then determine what you do next.

22:42Chris RomeoYeah, and I mean, some of the controversy, I guess, that surrounded this is— so Jeff Williams and Dave Wickers are the 2 project leads for the OWASP Top 10, and Jeff Williams actually is the CTO of a company called Contrast Security, and they're building— they have a product that provides that in-app instrumentation type of approach to detecting attacks and responding to attacks in real time. And so that's where some of the controversy I think is coming from, is because people are saying, well, you know, this is something that's like a self-serving type of thing. And I really don't think it is, though. And I have the benefit— I had a chance to work with Jeff and Dave back in the '90s at a small security company for a few years. And so I really don't think— I don't think they're trying to game the system here at all. I think this is a necessary move forward for the OWASP Top 10 because this is where security has to go, closer into the applications. So I think that this is something that really does have to happen for the industry to move forward.

23:53Robert HurlbutYeah, I think it makes sense. Like you said, I mean, there's controversy as well, but if you look at it from the perspective of we need to get better and closer to the code itself, that's where the issues are going to be, then, you know, this is a good solution, or at least a point in the right direction, I think.

24:18Chris RomeoYeah, and one of the things, one of the, I guess, the litmus tests that I used here to try and think about, does this actually make sense the way it sits right now? And I only had to look as far as A9, which is using components with known vulnerabilities. So that's the idea that there's a risk that somebody's going to have vulnerabilities in their open source libraries to get included in an application. And so if we don't take care of those vulnerabilities, then they get pushed. If we, if we push versions of open source into our applications, that have those vulnerabilities, our applications inherit those vulnerabilities as well. And so A9 is a perfect example of an OWASP Top 10 item that is truly met through tools and technologies being the overall solution to that. Sure, could somebody do a manual process to say, well, we have a manual process to ensure that our, our products don't have third-party or open-source vulnerabilities in them. Yeah, if they had one product, but when you have 100 or 1,000 products, there's no way you can do that at scale. So the third-party software tool industry has grown up around this A9, using components with known vulnerabilities. And so I think it— I think there's a direct correlation between that and how this tool market for supporting in-app kind of protections and things fits right around A7 as well.

25:48Robert HurlbutYeah, that makes sense. So like you said, with A9, how do you solve that? Well, first of all, like you said, if I have any kind of third-party components, I need to be aware that once they're in my code, that I'm still responsible. I now become responsible for that code. And so the solution is, as you said, to run various tools to look for issues or to keep up to date with updates and so forth. Same thing with 7. I think, like you said, we're going to probably need some tools to address those issues as well. Yeah.

26:25Chris RomeoYeah. And so even though there's a lot of controversy, that's okay. I think it'll get worked out. And in the end, I hope A7 stays in. I hope they don't take it out because of all of the comments and things. Because I think if people were to really pick that apart down to the base level, they'll see that this is really truly the way forward for application security. So we talked about A8, cross-site request forgery, already. We talked about how that's a great example of OWASP actually having a positive impact because then and now, now we're pretty well protected against CSRF. What about underprotected APIs, Robert? What is this idea that they're throwing out for us in A10?

27:09Robert HurlbutWell, a lot of websites now are building, especially with microservices, that trend of having smaller and smaller services to build out your application with components and so forth. So now you have APIs that you're using and putting those together and using those to build out an application. The thing about those are that many times because we want APIs to call APIs or your main application to call APIs, security is not necessarily a consideration. One, it may be difficult to put that in place to have server-to-server or service-to-service type of authentication or authorization. Those types of things are a little bit difficult and right now there's Not a lot out there in terms of— I mean, there's some tools, but there's still that we're getting ahead of ourselves with microservices and not understanding how to secure them. That's what we have. You have a lot of these APIs now that are unsecure, that are just completely unprotected, they're completely available. I've seen in my own experience where I've seen an application have 300 or 400 or 500 services and I ask how many of these are actually secure, that if caller A called caller D, that you don't have anything to prevent that from caller B calling caller C or caller E or whatever. And they say we have nothing. We're just trusting that our application works the way we expect. And so that's what we're talking about is lots and lots of APIs where security in terms of authenticating the caller, authorizing the caller, is just not in place, so they're just not secure.

29:00Chris RomeoYeah, and that, uh, that I've seen that same type of kind of view from the applications and things that I've seen. A lot of times folks think that there's value in obscurity. So if we— because our application is so darn complicated with 1,000 microservices, somebody would have to decode what we're actually doing first before they could take advantage of our security weaknesses where we don't have authentication, we don't have encryption. And I guess my advice to them is that somebody will figure it out and they'll exploit it, and then you're gonna, you're gonna be in some trouble. So, uh, certainly makes sense to me, A10, Underprotected APIs, as a new entry to the OWASP Top 10.

29:47Robert HurlbutYes.

29:48Chris RomeoSo, I think that, you know, in conclusion, that, you know, I think I could speak for you as well, Robert. I mean, we believe in the OWASP Top 10. We think this is a great document, and it's gonna— it's experiencing a little bit of a growing pains type of thing right now, where with a little bit of controversy, but you know what, a little controversy provides a little more awareness in the industry, so that never hurts. I just think it's, it's a very beneficial document. If you haven't had a chance to dive deeply into it, I recommend that you go and do that. All that we've really brushed over right now is a description or a discussion of what each of these things entails. In the OWASP Top 10 document, there's actually a whole section for each of these on how do you actually make implementation or design changes to prevent these problems. And that's where the true value resides for these. So for Robert and I, Chris, thank you very much for listening to this episode. Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast. Podcast, or on the web at www.appsecpodcast.org.