This is a transcript of the A04 - Insecure design training session. Click here to return to the OWASP Top 10 Security Vulnerabilities page
Michael Meyers: [00:00:00] My name is Michael Meyers. I'm the managing director at Tag1.
We're going to be talking about the Open Web Application Security Project, the OWASP, Top 10 Vulnerabilities. I know you guys use a lot more technologies than Drupal as your organization has grown. A lot of our examples are going to focus on specific Drupal Security announcements. We're going to broaden a little bit beyond that as well, and cover more of that in the future.
Uh, today's topics. We have Insecure Design, we have Security Misconfigurations and XML entities, and we have Server Side Request Forgery. For those of you who aren't familiar with Tag1, I should do just a really quick intro.
We are a large global team of subject matter experts best known for our work creating much of the Drupal CMS, which you guys are using. And it powers around 3% of the Internet. We work with a lot of technologies. Uh, we're helping Automattic prototype real-time collaboration support into WordPress.
We're working with Google to make the internet faster through [00:01:00] optimizing things like image compression and making their JavaScript based Squoosh application embeddable into your application. Uh, in the healthcare space, we do a lot of work in Python with the University of Michigan and the state of Michigan around big data analysis for COVID statistics and we're working with one of the largest hospital groups in the nation overseeing a massive migration of hundreds of sites, just under a thousand websites where we're coordinating and overseeing multiple digital agencies and leading development on a pretty complex system. Let me introduce you to our two speakers today.
Janez, who most of you met yesterday is our senior technical architect. Um, in addition to his work and background in security he has a really diverse background: he's authored research papers and giving conference presentations on Scrum. He's a huge community leader: organized, participated in code sprints, events, meetups, and has spoken at numerous conferences.[00:02:00]
Um, he's also a leading authority on multimedia handling in Drupal where he oversaw a major rewrite of Drupal's media handling capabilities as pretty much the core of what Drupal is and does is management of content and media. So Janez, thank you for joining us. And also Fabian Franz, who's our VP of software engineering.
Fabian is a performance and scalability expert. He is the lead of our Rust based load testing framework called Goose, which is the most scalable and easiest to scale load testing framework out there. He's behind almost all of the performance and scalability code in Drupal. Um, and he oversees all of our projects including work around real-time collaboration for a top five Fortune 500 company among many other things.
So thank you Fabian as well. Um, I'll leave it to you guys as to what order you want to kick these things off in, and I'll hand it over to you.
[00:03:00]
Janez Urevc: Thank you, Michael.
The first topic that we will cover today is AO4 Insecure design. Uh, this is -
It is also a very broad category. Um, cause you know, it covers a lot of things. In a way, it also interacts with other categories to some extent, but not necessarily all of the other vulnerabilities that we are talking about are related to design, because we can have, you know, secure design that has new security implementation.
Um, and this is basically makes that design not work [00:04:00] as intended. Um, but then on the other hand, if we have insecure design we won't be able to achieve secure implementation in any case. So the reason why this category is on the list this time is to raise awareness that we should incorporate thinking about security even before we start implementing our projects.
So what kind of issues are we dealing with here? Like top three. The top three issues that they are listing is displaying error messages that contain sensitive information. So it sounds obvious, but it happens a lot of the times Drupal specifically has, you know, a nice tool, a [00:05:00] nice configuration that helps you do that, to helps you achieve that. You're not exposing sensitive information. Um, and this is like here in the UI, in the configuration development section, we have this logging and errors configuration. And here we can, we can display, we can decide what kind of errors we want to display and none would probably be the best option for production environments.
But then, you know, when you are working in your local environment, you probably want to have something more verbose. Um, and what I usually use is everything we'd backtrace information. And if we was forget to, you know, somehow forget to change this, as we're moving from local development to production, [00:06:00] um, we could be exposing a lot of information to anyone that we don't want to expose.
Um, so this is one example of good design where we have developer usability, but also like protection where we need it. Um, but this design can be misused. Uh, if we misconfigure this configuration. For example, what I usually do, or we usually do is we have like uncommitted settings, PHP files on various environments where we, you know, hardcode this configuration value.
So it cannot even be overridden through the UI. Um, and what we would typically do in local environments, we would use this [00:07:00] configuration, which is displayed for both. That would be the one with backtrace. And then, on production environment and also in UAT, for example, we would use this one which hides everything like the one here.
And then if you have these files on your environments and they are not included in Git no matter what you deploy or how you deploy or what configuration is stored in your configuration files, these values will always override everything else. And that's, you know, one way to ensure that you always have configuration that's we tend to have if you're using some other system or, you know, building your own framework, then this is something that you can think about and make sure that [00:08:00] you're displaying what you intend to display. Uh, but for example, maybe you can use Drupal as, as an inspiration and develop something similar, or if you're using some other framework get involved in the community there and figure out what the best practices for that framework are. Um, yeah.
So the next, the next issue that is quite common is unprotected storage of credentials.
We've touched on this topic yesterday already when we talked about password passwords and how passwords are hashed and things like that. Um, so again, we can see that there. There is some good design with Drupal when it comes to, to this specific [00:09:00] issue. Um, and again, if you're using some other system try to learn what best practices are there.
I'm pretty sure that they have, you know, a major framework would handle passwords, for example, in a secure way. But if you're building your own system, then again, you can either use Drupal or any other framework as an inspiration to figure out, you know, what kind of hashing functions to use to hash passwords how to use salt with those, how to use multiple iterations of hashing and things like that.
So, yeah, it's really hard. Like it's really hard to give concrete steps that you want to, that you need to do in order to achieve secure design. It's really important [00:10:00] that you're constantly learning and understanding, you know, what the current best practices are, that you model threats. So you understand how your system could be compromised.
Try to prevent these threats that you've come up with too. So it's important to constantly review and improve this threat modeling because there are always new ways that attackers use to, to try to get to our systems and we need to be on top of that and learn and constantly review what's going on and how to protect ourselves. During my career, I really found out that being involved in a major open source project like Drupal really helped [00:11:00] me do that because with a big and vibrant community with a lot of people that are smarter than me. Uh, it's much easier to learn cause you know, when you interact with, with such a community you, you get exposed to all these ideas and all this knowledge.
While on the other hand, if you just close yourself in the room and try to do everything by yourself, it's pretty hard to keep your skills sharp and knowledge up to date. Um, one thing that is really important to measure with insecure design and unfortunately we can still see that is security through obscurity. Um, or this is also one of the recommendations here in the document.
I don't know where it's mentioned but mentioned here in the doc. So security through obscurity is not security. Oh, we [00:12:00] shouldn't rely on that. We should use proper techniques. Another important aspect with secure design is working with your security professionals, whether they are in-house or maybe, you know, outside collaborators when you are designing a system, when you come up with a design let security professionals review them and and give feedback and just like we mentioned yesterday about peer reviews when you're, when you're implementing code it's also important to have similar culture in your organization that lets you know, that lets people speak up and raise their, their concerns if they have any.
Um, because only that [00:13:00] way you will achieve the best and the most rock solid design. Um, if, if comments and raising concern is not welcome, then people would just stay quiet and there might be issues that will go unnoticed, unnoticed for that reason. Also I work with security professionals. Um, and develop like secure development workflows.
Um, we can also do, like, it's not specifically, this is not specifically about the system design, but also the workflow can, can help us achieve secure application as a result. So have a defined development workflow and with security in mind. [00:14:00] And yeah, this is another layer that can help you achieve good design. Um, one thing that is really important in my opinion, and it's often overlooked are third-party dependencies. We are used to, you know, rely on so many libraries or modules or, you know, whatnot to, to achieve what we want to achieve with our applications.
Um, and sometimes we blindly trust those libraries and dependencies and modules, however we want to call them. Um, and that's probably not the best idea because, you know, even these things can have bad design or bad instrumentation. So as part of the [00:15:00] design decisions, we should really consider which dependencies to use.
Um, how many of them to use review their track record people behind them how they dealt with security issues in the past and things like. Like don't just apply the pooling, every composer or NPM package that seems to be doing what you need to do. Um, and sometimes that's really hard to do cause we have like cascading dependencies and then if we pull something in, we can get like tens or even hundreds of other libraries and that's really hard to review. Um, so maybe there's some other ways maybe, maybe there's, you know, maybe we can do this, the same thing with a simple class in like the [00:16:00] custom code or there is another dependency that doesn't depend on hundred others of which would be easier to maintain.
And these are to review. Um, let's think about this issues as well. Um, yeah, I would also like invite you to, to go through like the, the issues that are mentioned in this design, because this will give you insight into what kind of issues we need to deal with when we're designing our systems.
We already mentioned passwords and unprotected storage of other credentials as well. Um, but there's also encryption and, you know, we have to think about whether we have sensitive data. Do we want to encrypt it addressed how to do that, how to do that [00:17:00] security then classic design failure would be relying on the file name to process something that was externally supplied.
Um, things like if, if you rely on that practice shows that at some point, this will break. Cause somebody will change the file name. Even if you, I dunno, communicated it or even enforce it some, some other way. But yeah, relying on naming for things that come from the outside world is definitely a bad practice.
Yeah. Then things like restricting uploads, restricting resource utilization [00:18:00] thinking about your business logic does it really do what it needs to do? All these things are important. Like here in the document there affects scenarios. And I found this one interesting, like it talks about a cinema group that allows booking discounts for maximum of 15 attendees, but then the business logic is wrong.
Um, and that recruits book, hundreds of seats. With the discount and cause a loss of income which sounds trivial, but these things happen. So something to think about.
Fabian Franz: Yeah. That's one thing more one thing that also have to send practice is that people think of all the good things and still get [00:19:00] it wrong. And that often happens. Um, for example, when people start to implement their own cryptography or they start to implement their own password comparison function, like often it feels like as you already said big framework like Drupal other frameworks.
Um, protecting you in a way that your custom code usually cannot because while you can think of all of that, one needs to understand the Drupal and the whole internet as well, has a history of, of the new issues have been found, new attack vectors have been found, et cetera. So for example, if you used for a simple password comparison, just a simple string comparison, then it will and maybe that's covered elsewhere.
But then for example, it will easily a timing channel attack where you can determine the password just by, by checking how long it takes til the comparison breaks and, [00:20:00] um, hashing to, to one string and then comparing to the hashes to solving that particular problem. But just here, again. Um, if you ever think about implementing your own crypto: don't use a library, use certain patterns, et cetera.
And even in huge enterprise organizations, if something that everyone needs to be reminded again, because saying like, Hey, we're just encrypting this and using this and doing this ourselves quickly, it feels simple, but it's not. And there's a lot more to all of those like industry practice to ads, for example, for encryption then meets the eye, and again, using frameworks and libraries and here dependencies are very, very good.
I agree here. As Janez said, it can be a risk, but it can also be really good because a library if you're using the library and it's used by 100,000 other people, and it has security defect in his encrypt method, it's much more [00:21:00] likely it will be found before someone exploits it on your system. Then the other way around.
Janez Urevc: I definitely agree. Um, and being somebody that looked into implementable cryptography myself I can just confirm how overwhelming it can be when you start to look into all the details and different modes of algorithms and the number of details that you have to think about just flabbergasting. Um, yeah, I mean, that's mostly what I had to tell about the secure design.
It maybe sounds quite vague. Um, and I said, it's very broad topic. Um, but hopefully I was able to. [00:22:00] Um, make you start thinking about it maybe in a different way. Um, yeah. Another thing that I wanted to mention and it's is not entirely design-related, but in the Drupal communication, there is writing secure code document that if you didn't read already could be interesting.
It's not speaking specifically about design. It's more about how to use Drupal's APIs correctly. Um, but even with that, it gives some insight into the design decisions behind. Uh, Drupal and how they ensure that Drupal remains a securely designed system. Um, so learning, learning, learning, this is something that we have to [00:23:00] dedicate our lives to in this industry and those people in general, I would say are there any questions or comments you'd like to discuss this topic if you have any insights or past experience.
Michael Meyers: Awesome. Thank you.