This is a transcript of the A06 - Vulnerable & Outdated Components training session. Click here to return to the OWASP Top 10 Security Vulnerabilities page
Michael Meyers: [00:00:00] In this first session, Janez is going to cover vulnerable and outdated components, identification, and authentication failures and software and data integrity failures. Then we're going to take a short break and Greg is going to join us and he's going to be covering security logging and monitoring failures, as well as infrastructure components, which again is outside of the OWASP top 10.
But it's a really critical component of building applications, the intersection of software and hardware underneath it. I'll hand it over to you, Janez. Thanks again for, for joining us, everybody.
Janez Urevc: Um, yeah, that's a good start. So, as Michael mentioned in this first session today, we have three topics.
Janez Urevc: Uh, first one is about vulnerable and outdated [00:01:00] components and let's get right into it. Um, so we are all aware that nowadays when we're moving software, we, you know, we almost always depend on a bunch of outside libraries, plugins, modules, and et cetera. And that's all nice and great because it helps us be productive and develop faster and be more efficient. But it also comes with its own set of problems and in context of security. Obviously if we are using dependencies with security problems, then these security problems [00:02:00] will affect our application as well.
Um, so we have to be careful how we handle this and most importantly think about it. Um, and my first thought or recommendation would be, is that we should think when, when we are, when we are considering bringing in a new library, a new dependency, we should really think through and decide whether we really need it, or we can achieve the same result some other way.
Um, because if we would need to bring in something huge and complex to just solve a very small business problem, something that could be done in a few lines of code of our [00:03:00] own, it probably doesn't make sense to, to, to use external libraries. Um, And I do think that we've grown used to just pulling in stuff and not thinking about it.
In fact, I'm just now I'm, I'm dealing with the problem about an external dependency on a client project. It's an API web application and we are importing a lot of data into it. And we're using the PHP library for batch importing data for various sources and it runs great. We love it. Um, it works very well, but it seems to be unmaintained at this point.
And it prevents us from upgrading to Symfony 6 because of its version constraints. And now we are faced with this, [00:04:00] uh, decision where we have this component that we use a lot. It works well, but. We- it blocks us from doing something, some other thing that we really need to do. Um, and we definitely don't want to refactor all our report code.
Uh, but we also, you know, if the, the only solution at the moment that we have is to, to fork that library and fix it so it works with the Symfony 6; but then we effectively, ended up maintaining our, our own custom project, which is exactly what we wanted to avoid to the first place. Um, and to be honest, I don't have any good, better solution for that, except I'm planning to get in touch with the maintainer and see if we can work together or something like that.
Um, and this is a realistic [00:05:00] possibility every time when you pull in some libraries, especially if it's a smaller library that doesn't have a huge community behind it. Um, maybe just a single developer working on it. It's very likely that in two or three years time, it would be unmaintained.
And then when it's unmaintained, if there are security problems, it's very likely that they won't be resolved. So another thing besides, you know, really thinking through when we're deciding to use external dependencies is to maintain continuous inventory of all the components that we have both backend and front end, especially in Drupal.
I feel that sometimes we forget about front end dependencies as our, you know, our teams cause like team development tends to go, tends to be really active when [00:06:00] projects are being built. And then in the maintenance phase you know, maybe it's just to like one CSS rule that needs to change now and then, or things like that.
And we completely forget about updating all the JavaScript dependencies that those teams might have. Um, so having an inventory and being aware which versions of packages you're running, and I'm comparing that to like most recent version and being subscribed to security, advisories being engaged with the, with the tools, with the community behind the tools that, that, that you're using.
Another very good practice is using tools to check your packages, to check your dependencies. Um, in [00:07:00] Drupal, we have a drush-pm-security command, which will check your Composer lock file and find all Drupal modules and teams in there and check that list against the security advisory database.
And it will let you know if you're running anything that is that is not secure. Then for other PHP for other PHP libraries, there is this tool called local PHP security checker which is it's a command line tool that will do a similar thing than drush-pm-security, but for all your PHP dependencies that you have in your project and you could do the best thing to do is to incorporate these tools [00:08:00] into your CI/CD pipeline and let and let your deploys uh, or merges fail.
If there are dependencies with security problems, this way you will immediately be notified and be aware that you need to upgrade something.
When it comes to Drupal, we have this Wednesday security window when typically security updates. Security advisories will be published on Wednesday. Um, it's sometime afternoon for me in Europe. It's probably morning for you in East coast. Um, and this way you can be prepared, you know, that on Wednesday something might be may [00:09:00] be published that needs your attention.
And you know, this way you can keep your projects up to date all the time. If there is like, something that is highly critical about to come out the security team will usually give an advanced notice so that we can be prepared and really quickly patch our projects. Um, so this is also something to be.
Uh, to, to pay attention to like, if there is prior announcement that something highly critical is coming out, we should really be ready. Um, one example was Drupalgeddon a few years back, was such case. And related to that if your project [00:10:00] in and, and modules and plugins in your projects are up to date, then usually applying security patches is quite easy.
You just upgrade from last word version of Drupal core or module to the most recent one that was just published and, and you're done. Um, but if you are not up to date, then updates might become tricky. Um, and then you have this decision to make whether to try and do this a little bit larger and more complex upgrade, or to try to create a patch for the version that you're running, that fixes the security problem.
Um, usually you will need to create this patch on your own which means [00:11:00] more work, more testing. Um, so. You, you've created a much more busy Wednesday that you would want to by not following the most recent versions of the modules and other dependencies you do have, and this obviously doesn't apply only to Drupal modules, but also every other dependency.
Uh, as soon as you stop following and you fall behind, it's usually much harder to to get back to most recent versions and getting back to the project that I mentioned earlier, that's exactly what happened to us there. Uh, because you know, we had this problem now, this single library prevented us from updating a lot of other things.
Um, cause you know, we have different [00:12:00] different libraries depending on the same packages and things like that. Um, so we've fallen behind and now this upgrade is way more complex than it should be. Um, and I wish we'd done it sooner.
Then if we go to JavaScript world I mentioned these common command line tools to check the packages that you're running in MPN, you have NPM audit command, which basically about the same thing. Um so yeah, once again it is recommended to include these tools into your CI/CD pipelines so that you're notified immediately when something important is available.
Um, another thing that it's really nice is GitHub's Dependabot. Um, [00:13:00] this is like a bot that is on GitHub and will scan through your repos and figure out if you're running any dependencies that are not secure anymore. And If it finds something like that, it will create- automatically create a pull request for you.
Um, and this is an example of one of those. It's asking us to, to bump post CSS to a new version, and we can see the release notes and change log, and which commits are included in the update. And there are also commands for the bot. So we can ask the bot to rebase the pull request do all sorts of other things, which [00:14:00] is really helpful.
Um, both because it's, it's easy to update things. And also because we have some other tool that notifies us when something is available. So Dependabot's definitely something you should look at. Um, should be highly recommended.
Um, yeah. And we should not forget about lower level software on our stacks, like LAMP stack. Um, and also other services that run on our operating system such as like, Varnish or DNS servers, CDN servers do virus scanners, things like that. So all of these services and then Apache, [00:15:00] mySQL or Mongo, if you're using MongoDB, all those things, like everything that we're running we should be subscribed to security advisory notifications and make sure that we are following what's going on and updating things as it's needed. Um, and that's why, I guess a lot of people opt out not to run their own servers themselves because it's quite a lot of work to do. So.
Especially like sometimes people figured that, you know, running their own hosting would let them save some money.
But when you, when you account for, for, for the, the cost of maintaining the servers it usually doesn't make sense.[00:16:00]
Yeah, so. In order to see Drupal security advisories. Uh, there is this web page on drupal.org/security, where all the advisories are published. Um, you can subscribe to newsletter and you will get notifications in your email inbox every Wednesday. And there's also a Twitter account. Uh, and it might be that there are some other sources. I personally use email.
So that's what I'm most familiar about.
So the main thing to take from this topic should be. Um, that we really need to think about components and dependencies. Um, and when we're deciding what we're going to use always think about, will it be maintained and how we will handle any advisories, and [00:17:00] in general problems that might arise related to all those projects that we're bringing in, have any experience that you want to share or questions.
Michael Meyers: Do you use these kinds of components in your CI/CD systems? We'll definitely encourage you guys to check them out, you know, regardless of the language or the tool you're using, you know, NPM, PHP, most languages and systems have these kinds of components.