---
title: "Dave Ferguson -- The OWASP Top 10 Proactive Controls"
url: https://appsecpodcast.com/dave-ferguson-the-owasp-top-10-proactive-controls/
date: 2017-07-25
duration_seconds: 2611
guests: ["Dave Ferguson"]
topics: ["OWASP Top 10", "OWASP Projects", "API Security", "Vulnerabilities and Exploits"]
audio: https://www.buzzsprout.com/1730684/episodes/8122714-dave-ferguson-the-owasp-top-10-proactive-controls.mp3
transcript: true
---

# Dave Ferguson -- The OWASP Top 10 Proactive Controls

*July 25, 2017 · 44 min*

with [Dave Ferguson](https://appsecpodcast.com/guests/dave-ferguson/)

on [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/), [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/), [API Security](https://appsecpodcast.com/topics/api-security/), [Vulnerabilities and Exploits](https://appsecpodcast.com/topics/vulnerabilities/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122714-dave-ferguson-the-owasp-top-10-proactive-controls.mp3)

## Show notes

Developers hear plenty about vulnerabilities, but what should they actually build into their applications to prevent them? Dave Ferguson joins the podcast to walk through the OWASP Top 10 Proactive Controls as they stood at the time of this recording. The discussion covers early security testing, parameterized queries, output encoding, input validation, authentication, access control, data protection, logging, security frameworks, and error handling. Dave connects the controls to familiar application risks and explains how OWASP cheat sheets provide the implementation detail behind the high-level guidance. Chris and Dave also debate where intrusion detection belongs and why security features should be reusable. The result is a developer-focused conversation about turning awareness of common failures into concrete engineering practices.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Dave Ferguson:  
→ [Dave Ferguson on LinkedIn](https://www.linkedin.com/in/davefergusonappsec)

Mentioned in this episode:  
→ [OWASP Proactive Controls](https://owasp.org/www-project-proactive-controls/)  
→ [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)  
→ [OWASP Top 10](https://owasp.org/www-project-top-ten/)

Chapters:  
00:00 Proactive security controls with Dave Ferguson  
07:40 A developer-focused security baseline  
08:40 Verify security early and often  
12:34 Parameterize queries  
15:01 Encode data for its output context  
18:14 Validate all inputs  
23:07 Identity, authentication, and session management  
25:25 Implement access controls  
29:03 Protect data at rest and in transit  
32:18 Logging and intrusion detection  
36:32 Use security frameworks and libraries  
38:33 Handle errors and exceptions securely  
41:18 Turning vulnerability awareness into action

## Transcript

*6,703 words · assemblyai*

**0:05 Dave Ferguson:** The Application Security Podcast. Here we go.

**0:09 Chris Romeo:** Hello everyone. It's time for another episode of the Application Security Podcast.

**0:33** On this episode, Dave Ferguson talks with Chris about the OWASP Top 10 Proactive Controls. As always, thanks for listening and enjoy.

**0:40 Dave Ferguson:** So welcome to this episode of the Application Security Podcast. I'm joined today by Dave Ferguson, and Dave is going to share about an OWASP project that he's had a chance to, uh, to kind of pick around and take a closer look at and even speak about at conferences. So, Dave, thank you for being here today first.

**1:05 Chris Romeo:** Yep, thanks, Chris. Glad to be here.

**1:07 Dave Ferguson:** And so, Dave, everybody that comes on the AppSec Podcast gets a question that our listeners probably are already yelling right through the speakers in their cars and other places, and that is, what is your security superhero origin story? And what we mean by that is, how did you get your start in security? What drew you into it? Is there Every superhero has a genesis story about how they got their powers. So what's yours?

**1:33 Chris Romeo:** OK. Yeah, so my story is maybe a little bit unique. So I came out of school with engineering degrees. I had an aerospace engineering degree and I could not find a job. Ended up taking the first job I could find, which was an engineer, but also some programming involved in that. Did some C++ and Fortran programming early in my career. This is mid-'90s. And decided that I really liked programming better. And so I kind of decided to cross over over and become a software developer. Joined a small company and started doing web app development in the early days, late '90s, early 2000s. And that's where I really learned about web applications to a deep understanding and how they're put together, how they work, and so forth. Towards the end of that, I started to hear about some things like SQL injection. I wondered, well, I write web applications, could my web apps be vulnerable? Sure enough, I was writing a lot of code with vulnerabilities and didn't know it. So that piqued my interest in the security side of things. That was about 2004. By 2006 in January, I decided to change careers and focus exclusively on application security. So that's where I became a consultant. AppSec consultant with Fishnet Security, and I did a lot of application assessment work and pen testing, working with developers, helping them understand how to write secure code. Of course, I was new at the time, but that's— things evolved from there, and I ended up, you know, working for Veracode for a while. I worked at Sabre Corporation as the global AppSec lead, and currently I'm at Qualys. My title is security solution architect internally. It's an SME role, so I help our customers and prospects with our web app scanning product. And so enjoy that. I've been doing it almost 2 years now at Qualys, but application security is my passion, and so I do feel like a superhero in that role.

**3:47 Dave Ferguson:** So it's a good question. That's, that's definitely good stuff. Now, am I remembering correctly? Did I hear you tell a story about Using an application that you had actually written many years ago?

**3:59 Chris Romeo:** Yes.

**4:00 Dave Ferguson:** Tell that story for our listeners because I found that fascinating when I heard that.

**4:04 Chris Romeo:** Several times now. I have kids and a lot of them are in college now. So when I was writing the web applications for that one company, small company, the web applications we were writing were targeting or selling to higher education colleges and universities basically. So my web applications are still in production today. So when I paid my daughter's tuition recently on the college website, it was using the web application that I wrote approximately 2002, 2003 timeframe. It's been modified, but it's still a straight JSP application. It's not using like a Struts framework or any fancy JavaScript framework. It's still out there in production today. Unfortunately, I had not built in any backdoors to bypass the tuition payment somehow. But then again, when I wrote that, I didn't know anything about security.

**5:01 Dave Ferguson:** Yes, and when I heard you tell that story the first time, I thought, this is a reminder for us that the things that we build may have a lot longer lifespan than we ever imagined. Because I got to think, when you wrote that application, you were thinking, yeah, they'll replace this thing in a year or two with something off the shelf from Oracle or something else. that's going to do this. And here we are, how many years later, and that thing is still being relied upon.

**5:28 Chris Romeo:** I'm shocked by it. And it's happened a couple of times now. But yeah, I looked— I did view source on the web page to see, oh yeah, I remember writing this form and I remember these HTML comments I added.

**5:41 Dave Ferguson:** It's pretty weird. That's pretty cool. So something that we write in the past can make an appearance in our career in the future as well. Primary thing that I wanted to talk to you about here today is, I know you've, you've done a talk on the conference scene about one of the top 10 lists at OWASP. And some people, when they hear OWASP top 10, they immediately think of the top 10 web application risks and they go right there. But you actually have been talking about something else. Tell us a little bit about what that other thing is and kind of paint that picture.

**6:18 Chris Romeo:** Yeah, it's a top 10 list from OWASP for better application security, but it's not the OWASP Top 10. It's called the OWASP Top 10 Proactive Controls. It's a list that I heard about probably a year or so ago, but I just kind of brushed it off. Then earlier this year, I was at the SnowFrog conference in Denver, and there was a panel, and Jim Manico was up there, which I guess apparently you just interviewed him recently.

**6:45 Dave Ferguson:** Yeah, we know him.

**6:45 Chris Romeo:** On your podcast. Yep. So Jim and I go way back. He was— I have a lot of respect and admiration for him and what he does. The only other podcast I've really done was actually Jim was interviewing me way back in like 2009. But what I heard at SnowFrog, Jim said, let's not focus on the OWASP Top 10. I think we really need to start talking about the Top 10 Proactive Controls. So that kind of made me stand up and take notice. Maybe I need to go look at these proactive controls more carefully. So when I did, I realized this is really what development teams should be focusing on not the top 10 risks, the top 10 list that everyone knows. Software development teams should really sort of embrace the proactive controls. And so since I started digging into it, I've been trying to kind of spread the word about what a good list it is for development teams.

**7:40 Dave Ferguson:** So that's, so that's the primary audience then. So if, if our listeners are responsible for a security program or Maybe they're just a developer themselves who's actually writing code. So this is a list that's specifically written for the developers then, right? So this isn't for the security people?

**7:59 Chris Romeo:** No, it's really more focused towards developers. Not necessarily everyone on the team needs to be, uh, you know, know this list like the back of their hand, but someone on that team who can be designated as the security champion should know this list and make sure that it's discussed during meetings, it's added to requirements, those sorts of things. It's basically a minimum set of hygiene that every team should think about as they're either working on a new development project or some sort of added functionality to an existing product.

**8:40 Dave Ferguson:** Yes. Let's go ahead and just start walking through this and enlighten our listeners a little bit about the different items that are on this list, and perhaps you can give us a kind of your take on kind of what these things actually mean and why they're so important. And the first one I see on the list is verify for security early and often. What does that actually mean?

**9:02 Chris Romeo:** Yep, that's control number 1. Verify for security early and often simply boils down to testing. There's a lot of different approaches to testing applications to ensure they're not vulnerable. You know, there's static analysis for looking at the code or the binaries. There's manual pen testing approach. There's also dynamic scans that look at a running application to try to find vulnerabilities, you know, in the HTTP requests and responses. So it's kind of— this is kind of the most broad control. In other words, It means development teams, QA extension of that, should be thinking about testing for security, which is really the abuse cases. I think QA teams and developers are so focused on, this is what the application needs to do. Does it do it? Then good, we're done. You have to think about what does the application allow to be done that shouldn't be happening or shouldn't be allowed. And so that's the security aspect of the testing. So that's a really important kind of broad control. That's number 1.

**10:12 Dave Ferguson:** Yeah, and from my perspective, I've seen a lot of companies where security testing gets pushed to the right, closer to the actual release time. And so when I look at this control, it sounds to me like the advice is you want to be testing for security as soon as you have code that compiles into something that you can call a product or a release, even if it doesn't have all of its features and functionality already worked out, you want to start scanning that and testing it and really trying to get a baseline on what are we dealing with here versus waiting until the end where it's a lot harder to fix any problems that you find.

**10:54 Chris Romeo:** Yeah, absolutely. I mean, ironically, waiting till the end is easier to do, but if there are problems or vulnerabilities found, then it's much harder to get them fixed and more costly. So at Qualys, in my role, I'm seeing a lot of customers really interested in moving that testing to the left and doing it early and often. But as far as executing that and getting it done, that's the challenge. So the big, I think, help with that is automating via APIs and making it part of the build process so that you can do that testing. automatically. So when someone— you don't have to rely on somebody manually launching a scan or something. You can use APIs to, you know, as soon as a build is done, the Jenkins or whatever CI/CD tool you're using can kick off a scan on maybe the dev environment that just got updated with the latest code. And then you can have it set up to where if there are vulnerabilities detected, maybe somebody gets an email and say, oh, this latest scan in the build detected a vulnerability. We need to go look at that and look at the details and get it fixed.

**12:07 Dave Ferguson:** Yeah, and that's— automation is certainly the way of the future here, and a lot of folks are really embracing it now. And so, yeah, I think that's wise advice for folks that are trying to figure out how do we verify security early and often. Automation is really going to be the key.

**12:25 Chris Romeo:** Yeah, it's got to be done. There's just too much code, too many projects going on to manually rely on people to remember to do the testing.

**12:34 Dave Ferguson:** Yeah, definitely. So, the second one is what we refer to as parameterize queries.

**12:41 Chris Romeo:** Yep, control number 2. So, this is pretty, uh, simple, and this directly ties to the injection risk in the OWASP Top 10. So, parameterizing queries is a way for you to prevent SQL injection primarily. There's other types of injection command injection, LDAP injection, whatnot. But SQL injection is the big one and the big concern typically. So parameterizing queries is the way to defend against SQL injection. Validating data, escaping special characters is not the way to go. Parameterizing queries in Java world is called using a prepared statement, is typically the way you would do that, but it's It prevents the SQL injection attack, and so that's why it's up so high on the list here.

**13:33 Dave Ferguson:** Yeah, and it's something that I think is— there's a lot of education about this now out there, so it's hard to imagine there's developers out there who are still parsing SQL together by hand as a way of life. I'm sure there's some of them out there, But the fact that we have the ability to parameterize queries, we have even in the proactive controls, there's examples for Java, PHP, Python, .NET. All the different languages can suffer from this problem and there's a good solution for all of them. And it really boils down to don't concatenate, don't use string concatenation to build your SQL queries and use untrusted data as the source for that or bad people can manipulate your SQL queries to do stuff that they want.

**14:23 Chris Romeo:** Exactly, exactly. One of the key things when I, when I did do that developer training is string concatenation, bad. It's when you're making any kind of database query, string concatenation with untrusted data, user-supplied data, that's where you get into trouble. Parameterizing queries prevents that, and that's the general term. You know, like you said, every There are examples in the document for the proactive controls, but every language has its own sort of, you know, special keywords on how to do the parameterization, but every platform, every language has that available. Yep.

**15:01 Dave Ferguson:** Okay, that takes us to number 3, which is encode data, and I think of encode data kind of works hand in hand with parameterization of queries. Tell us about that one.

**15:12 Chris Romeo:** Yeah, it's very similar to parameterizing queries in that it makes the data safe. So when data comes into an application through some entry point, it may be dangerous, meaning there's special characters, single quotes for SQL injection, angle brackets, for cross-site scripting. So the special characters that— a lot of people try to prevent SQL injection and cross-site scripting with validating data and rejecting bad characters or something. So just like parameterizing queries prevents SQL injection, encoding data is going to prevent cross-site scripting in nearly all cases. The devil's in the details though because encoding the data is not as simple as it seems because sometimes you have to use HTML encoding, sometimes you have to use HTML attribute encoding, sometimes you have to use JavaScript escaping. There's a number of different types of encoding that have to be done. It depends on the context. Where is the data going? Where is it being output to? So that's important to understand. It's probably a good point also, Chris, where I should mention the cheat sheets at OWASP.

**16:31** Okay.

**16:32 Chris Romeo:** So the controls here are sort of general approaches to securing your code and securing your applications. The details, like for encoding data, I'm just talking about here, you would want to go to the corresponding or the appropriate cheat sheet from OWASP to do that. And so there's a cheat sheet called the Cross-Site Scripting Prevention Cheat Sheet, and it has all those details about the types of encoding, when you use this encoding depending on the context, and that. So almost everything in the proactive controls, at least as far as writing secure code and securing the application application, there's going to be a cheat sheet that supports that control.

**17:18 Dave Ferguson:** Yeah, that's good to know. That's good to know that there is because, yeah, the proactive controls seem to be a little— by design, they're more higher level. And so, they may have a couple of code examples, but they're really not giving you the prescriptive solution to what you need to do. And so, yeah, that's something we'd recommend our listeners take a look at is when you're reviewing the proactive controls, also take a look at the OWASP cheat sheets right on the OWASP website and look for— and there's probably 40 of those things now. So, there's a lot of topics that are covered there in that cheat sheet group.

**17:53 Chris Romeo:** Absolutely. Yeah. And one thing I'm going to do is on the proactive controls OWASP page, there's currently a mapping to the proactive controls to the OWASP Top 10. We need to add another column for the cheat sheets, which cheat sheet supports that control. But so that'll be coming soon.

**18:14 Dave Ferguson:** Yeah, that'll be, that'll be really valuable. So okay, that takes us to number 4, which is validate all inputs. I don't know how many times I've made this statement in my, in the last 10 years of my AppSec career, but I've probably said this, if I've said it once, I've probably said it 1,000 times in the last 10 years.

**18:31 Chris Romeo:** Yeah, control 4, validate all inputs. So, um, this one It's huge, of course. In fact, early in my AppSec career, I remember being at the SpyCon conference which was in Atlanta. It was the SpyDynamics inaugural conference. Well, they only had 2 before they got bought by HP, but Caleb Steinmeier said— he was asked a question at that conference, what's the number one thing that can be done to prevent web app vulnerabilities? And he said, validate input data. It doesn't prevent anything, but when he said that, that kind of stood out in my mind and I've remembered it to this day. So validating input data, it's not the— it doesn't answer everything, but it fixes so many different things. And just making sure the data coming in from the client side, whether that's a user input field, whether it's a hidden field, whether it's an HTTP header value, anything in that request can be forged, and so it can't be trusted. So you need to validate the data and validate it in a secure manner, typically using a whitelist approach. A lot of developers, you know, quickly will do some blacklisting data validation, but then there's— you're going to forget about something.

**19:55 Dave Ferguson:** Let's see, tell us what whitelisting is first, whitelist validation.

**20:00 Chris Romeo:** Yeah, so whitelisting approach to data validation is when you actually define what is valid data, valid characters, and also, you know, what the length, maximum length, minimum length, that sort of thing. So it's saying what is acceptable and this is allowed, and anything that doesn't fit inside that, what's allowed, is rejected.

**20:22 Dave Ferguson:** Okay.

**20:22 Chris Romeo:** So you've defined what's good. With blacklisting, it's kind of the inverse of that. As a developer, you're saying, okay, well, these characters, these are bad, they're dangerous, so I'm going to reject the input if it has any of these characters. Or if it's too long, maybe there's a length limit. But the problem is that you may not have been aware of other characters that are dangerous that the attacker knows about, and so basically you haven't necessarily thought of everything and something may get through. It's kind of like the same approach to like a fire— it's a network firewall. Typically when you set that up, you start with a default of deny all, and then you start adding in what is needed, what is acceptable from, you know, what ports should be open and so forth. But so the whitelisting approach simply covers more bases and is more secure. Yeah.

**21:18 Dave Ferguson:** Yeah, that makes sense. And as I said, I feel like I've beat that drum for a long time, and yet we still have more work to go in the input validation to get people— and I think it's a mindset issue. People, a lot of developers that I speak with, they don't realize, they won't accept that somebody bad would try to do something to their little piece of the software architecture that they're building.

**21:45 Chris Romeo:** Yes, I've heard that many times too.

**21:48 Dave Ferguson:** I mean, there are bad people out there and they're going to try to exploit your code. Well, my code's not that interesting. It doesn't do anything that important. Everything is interesting from an attack surface perspective. If I can use that to then hurdle into some other interesting piece of code, we can go through yours just as easily and use that as a beachhead to get additional access. So the big takeaway there is validate all the inputs, validate early, validate often, Validate even on holidays, I guess. Whatever you got to do to get this ingrained.

**22:20 Chris Romeo:** But don't validate client-side.

**22:22 Dave Ferguson:** Yes. Oh yeah. So that's a— I've had a debate with that, over that with some people. And I think of client-side input validation is a usability/bandwidth saving feature, but it's not a security feature. So that's a great point because some people will do their input validation on the client side not realizing that an attacker can just shut off JavaScript running in their browser, and then none of that code actually executes. And I've seen examples of that, and that's not a pretty scenario.

**22:56 Chris Romeo:** Right, exactly. I agree with you 100%. It's a nicety to have the client-side validation, you know, via JavaScript code or whatnot, but you can't rely on that for security. It's like it's not even there.

**23:07 Dave Ferguson:** Yep. Okay, the 5th one takes us to implement identity and authentication controls.

**23:15 Chris Romeo:** Yeah, so this is Control 5 here. It's really just tying directly to A2 in the OWASP Top 10, which is broken authentication and session management. Authentication, of course, is the process of verifying a person is who they say they are. It's simply the identity part of it, verifying their identity. Then also subsequent to that, there's— once that identity has been, at least for a web application, you verify their identity, there's a session management piece, meaning that, okay, they've been authenticated via their user credentials, but we still have to track them. And so typically that's done with a cookie where there's some sort of a session token set into a cookie, and that is basically the key to being authenticated. And so you have to protect that token. that's in that cookie, and there's a number of best practices, session management best practices, for protecting that session token. And so this control is all about that. It's about authenticating the user with their credentials securely, and then also doing the session management securely.

**24:25 Dave Ferguson:** Yeah, and a lot of people forget about the session management side, and I've seen some applications where They had authentication and they forgot the session management piece so that they would actually authenticate you if you came to the front pages of the website, but they actually wouldn't actually do any authentication if you just did a direct object reference to a particular spot.

**24:53 Chris Romeo:** Okay.

**24:54 Dave Ferguson:** As long as you came in the front door the way you were supposed to, authentication would prevent you from continuing. if you just forced your way into links that were supposedly inside the protected enclave of the application, they would forget to authenticate you and just give you access.

**25:09 Chris Romeo:** Right, yeah, just a forced browsing kind of attack, and then not realizing, you know, every page needs to be checking for authenticated session so that to allow that user in.

**25:25 Dave Ferguson:** And that takes us, I guess, 5 and 6 kind of rolled together nicely, 5 being authentication and then 6 being access controls. It seems like in a modern web application paradigm, you can't have authentication without access control, and you can't have access control without authentication.

**25:42 Chris Romeo:** Yeah, absolutely. So the access control piece is really the authorization part of it. A lot of people kind of mix authentication versus authorization. So authentication is just verifying the identity of the user or the entity, and authorization is enforcing permissions or authorization controls on that identified or that authenticated user. So authorization problems can come in. There's a couple of attacks, one called horizontal privilege escalation, another one called vertical privilege escalation. So these would relate to the access control. A vertical privilege escalation would be a standard user is authenticated, they are using the application, but they are able to elevate or escalate their privilege to maybe an administrator user. So they can either get to maybe a web page that is meant only for an administrator, or they can invoke functions that, you know, via POST request or something that only administrators should be able to do.

**26:51** Okay.

**26:51 Chris Romeo:** That's the vertical part of it. The horizontal is simply more like I'm logged in and I see my account, but I'm able to tamper with the request and somehow get access to another user's account. So maybe I can view their data when I'm not supposed to be or do something else, even submit requests or changes as that other user. So that's a horizontal escalation issue. These are all access controls. I like this for developers because it's very straightforward. It's implement access controls. That seems pretty self-explanatory. When you look at the OWASP Top 10, these map to a couple of very esoterically named— so they map to A4 and A7. A4 is insecure direct object references. As a developer, what does insecure direct object reference mean?

**27:43 Dave Ferguson:** Yep.

**27:44 Chris Romeo:** And the other one is A7, which is missing function-level access control. Missing function-level access control. Okay, you know, I kind of know what that means, but just implement access controls is a much better way to explain this type of thing to—

**28:00 Dave Ferguson:** Yeah, it makes me think about a global. So when I read missing function-level access control, that makes me feel like or think like I have to create a bunch of different access controls. for the different pieces. Whereas when you say implement access controls, that sounds like a global solution that's going to be application-wide. And I think that's really what we want people to do. We want one access control authorization policy and implementation, and then we want all the pieces of the web app to call upon that existing defined policy for any of the decisions that have to be made.

**28:34 Chris Romeo:** Yeah, absolutely. I mean, the good thing is the new OWASP Top 10 that will be out later this year, 2017 edition, most likely it looks like A4 and A7 are going to be combined into simply broken access control, which I am in agreement with. I think that is a good change. So that way, proactive control number 6 is going to map directly to that other OWASP Top 10 risk. Okay.

**29:03 Dave Ferguson:** Yeah, I think that's one of the ones that's not in contention. So nobody, nobody has any nasty comments about broken access control or anything. They're like, it's kind of hard to get mad at broken access control because we all know it exists out there. So that takes us into 7, which is protect data. That seems like kind of an important— I wonder why that one's not further up on the list.

**29:23 Chris Romeo:** Yeah, I'm not sure the name of this one is the best, but control number 7, yeah, it's protect data. And what it really means is use encryption both for data at rest and data in transit. Protect data is kind of really broad, so I am not sure I agree with the name of this control, but it is really talking about encrypting the data. So when you have sensitive data that you are storing or the application is storing in the database, it needs to be using encryption. if you're storing passwords, there's a whole cheat sheet about proper ways to store password in database.

**30:08 Dave Ferguson:** Yeah.

**30:08 Chris Romeo:** Then there's other types of data that, like for example, credit card numbers, there's a whole set of PCI rules around protecting that data if you're storing it. So that's this control as well as the standard data in transit. So you should be using a TLS connection, HTTPS, over the wire. And then also, it also would be considered, what about your internal traffic, like from one internal system to another internal system? Should that data be encrypted? That's still in transit. It's not over the internet, but a lot of companies have thought very seriously about encrypting internal traffic. Once the NSA revelations and Ed Snowden information came out, there was a big move to think about encrypting data internally between systems.

**31:10 Dave Ferguson:** Yeah, I think that's the future of where we're going. I mean, as an industry, it's just taken a whole lot longer for that to actually become a reality. Post-Snowden, everybody was like, oh, we're just going to— the internet's going to go dark. that people were making that statement that it's gonna go dark 'cause we're gonna encrypt everything, until they realized that key management and PKI infrastructure is some of the hardest stuff to actually do correctly and at scale as any problem in computer science these days. So I think that's been kind of what's been lagging from the encryption. But I like your idea about kind of giving this a slightly different— it's not really protecting data, it's really about encrypting data. And I think that's a good way to kind of think about it. Now, when I look at 8, I've been on board here 1 through 7 the whole way without any real contention, but I look at 8 and I see implement logging. Okay, I like that. I like to have audit logs, but then it's got this intrusion detection thing added in here. And so that seems a little weird to me. So what's your take on number 8 here?

**32:18 Chris Romeo:** Yeah, so intrusion detection, it's like we're back into the controversial subject.

**32:24 Dave Ferguson:** You knew where I was going there, that one.

**32:28 Chris Romeo:** with the proposed A7 that has been much discussed. So intrusion detection— so implement logging. Let's talk about that first because that's part of this. So that's really about, you know, you should implement some logging system. You know, obviously developers need this for troubleshooting, debugging, and whatnot. But part of the logging, you can also tailored towards security events or things that you may want to know about if someone is attacking your application. So I agree, the logging part is a no-brainer. If someone has submitted a login request 1,000 times with the same username but a different password in a short period of time, applications can see that and they could take some action to prevent that. They could log the information first of all and then maybe alert based on that type of security event. So the logging part is good. You do want to avoid another type of vulnerability called log injection, so you still need to encode the data if you're incorporating untrusted data into the logs. You want to make sure to encode that properly. But then intrusion detection So what does that mean? There's a technology called RASP, or Runtime Application Self-Protection. It kind of seems similar to that, but I'll just use it for my own personal example of what this could mean. So I was pen testing an application when I was with Fishnet, and I was trying to find vulnerabilities. I had an authenticated session. So I was logged in. Every time I would try to tamper with the data in the request, the application would log me out and send me away. It was very, very frustrating. So if I would, like, say a numerical parameter in the request, I would try SQL injection in there. Well, obviously, for SQL injection, you have to inject non-numeric characters. So the application saw that and said, okay, why is a non-numeric value coming in this account ID value. Then it basically said, well, there must be some sort of attack, so I'm going to kill this user session and send them back to the login page. So it was almost impossible to test this application. That's the kind of thing that I think could be done on this particular control.

**35:03 Dave Ferguson:** I guess I'll give the counterpoint to the other side of the argument of of why I think that's kind of a bad idea. I think that's a better— I would hate to see that level of intelligence to actually be written and included within a whole enterprise's worth of applications. So from a custom perspective, I believe that you're going in the right direction to have that capability within applications, but I would hate to see it done individually. from one application. Think of the enterprise that has 10,000 applications. You've just created— say you want to make a change to that. So, custom— so, I don't like the idea of custom solutions to do this. I like the idea of some technology platform that allows to kind of wrap— and I'm not saying RASP or IAST or any of the many different terms that are out there is the best way to do it. But I would like to see it not be kind of a singular approach, but more of something that could be embraced across an entire enterprise.

**36:09 Chris Romeo:** Yeah, yeah. For scalability, it's got to be that way. I mean, the product I work on at Qualys, it's all about scalability and we're testing thousands of applications on a weekly basis at single customers. There's no way all those applications could have that level of sophistication. So I totally agree with you on that aspect.

**36:32 Dave Ferguson:** Okay. Then number 9 takes us to what I think is one of the items on this list that wraps a lot of the other things together, and that's leverage security frameworks and libraries.

**36:44 Chris Romeo:** Yeah, so control number 9, just take advantage of any kind of security controls or features in the platform or the libraries that you're using. I mean, they're free security controls basically because you don't have to do anything extra. You just have to make sure to leverage them or take advantage of them. It prevents a lot of types of vulnerabilities. For example, cross-site scripting. A lot of the frameworks provide built-in encoding mechanisms to prevent cross-site scripting. Cross-site request forgery. Almost every development platform or web framework has some sort of an anti-CSRF token that you can make sure to enable.

**37:27 Dave Ferguson:** And you're— Yeah, I think that's the reason why we've seen such a, such a diminishing number of CSRF-style attacks, because the frameworks have gotten to the point where they've almost eradicated CSRF just using the, the tokens that are, that are automatically appended to each individual stream of data that's going back and forth in HTTP requests. So So, I think the frameworks are huge, and that's some of the basic advice I give to anybody when I start working with them is, what are the frameworks that you're relying on for your developers, and what is the security functionality within those frameworks that are providing the basis for the security that you're trying to put forward here? Because writing stuff from scratch right now is like so 1992 or something.

**38:16 Chris Romeo:** It is. development teams, at least in my experience, they may not be taking advantage of these features. Maybe they don't know about them. So just, you know, being aware of those features that you can turn on and get for free.

**38:33 Dave Ferguson:** Yeah, definitely. Okay, number 10. I feel like there should be a drum roll or something here, but maybe I'll add one after. But hey, number 10, error and exception handling. So this is— it shouldn't be forgotten because it's at the end of this list because it's It's easy to do this badly.

**38:50 Chris Romeo:** Yeah, it's kind of the least sexy, least exciting one, but error and exception handling is a best practice across the board. You want to prevent technical information from being disclosed unnecessarily to potential attackers. That's anything. That's stack traces. It's any sort of error messages that you— typically for debugging, they're meaningless to normal individuals, but for attackers, somebody that's really doing some sort of a reconnaissance to learn about the application and how to best attack it, you don't want to reveal that information via the application. So just make sure you're logging any details on the server side, and on the client side, just have generic error messages. And the best practice around that is, well, if— or the complaint you hear is like, well, I still need to be able to trace down what happened. And so the best practice there is to create some sort of a reference number that you log with the details, and then display that reference number to the client side in case the user wants to, you know, log a ticket or something with that reference number.

**40:10 Dave Ferguson:** One of the other attacks I've seen as I was reading through some of the other OWASP documents and things that you have to worry about from an exception perspective is if you have an access control decision and you assume that— say you set the user's role to administrator as the first thing you do, and then you have some other code, and then further down you have an exception handler If you by default set that user to administrator thinking you're going to check and then update it with the actual role information later if they're not administrator, and then you have an exception hit, you can actually end up with a condition where somebody has a higher level of privilege because they generated an error inside of a particular routine. That's the other thing I think about when I think exceptions. People have to— you have to think a little bit about what's the flow going to look like if this exception actually fires. And am I somehow leaving something in an insecure state that could get me in more trouble?

**41:11 Chris Romeo:** Yeah, yeah, it needs to fail safely, uh, not in an— not fail in an open insecure state.

**41:18 Dave Ferguson:** So yeah, I mean, the, the OWASP Top 10 web application security risks gets all the love in the press, it gets all the attention, it gets included within all the products, but I really think this proactive controls is something that's a lot more hard— should be a lot more hard-hitting for a developer because these are actionable things that the developer can take away to actually make their software more secure. And they may not ever— if you do these 10 things, arguably you won't have to worry about the OWASP Top 10.

**41:49 Chris Romeo:** It should just naturally— your application should naturally fall out not prone to those risks. Yep, that's right.

**41:56 Dave Ferguson:** Yeah, we need to make t-shirts with proactive controls and like go to conferences and try and And try and get everybody like, you know, forget about the top 10 risks, let's talk about the proactive controls. So I think that's— you've already been doing that as a mission, but I think that's something that others of us should be also trumpeting how nice of a— and how useful of an actual project this is. I know I'll be doing that here moving forward. So Dave, thanks for taking the time to share this with our listeners, and always great to have a chance to catch up with you. So thank you very much.

**42:28 Chris Romeo:** Yeah, Chris. Well, thank you for having me. I enjoyed it.

**42:31** 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 Kartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/dave-ferguson-the-owasp-top-10-proactive-controls/