This is a transcript of the A02 - Cryptographic Failures training session. Click here to return to the OWASP Top 10 Security Vulnerabilities page
Janez Urevc: [00:00:00] The next topic is called Cryptographic Failures. Um, in the previous edition of the top 10 list it was called Sensitive Data Exposure.
And the motivation for the name change is that cryptographic failures are the cause of the problem and sensitive data exposure is basically the result. Sometimes sensitive data exposure can also happen for non-cryptographic reasons. Um, so we should keep that in mind as well. Uh, but yeah.
Um, so if we look at the top three ones, like the most common one is use of hard-coded passwords and this kind of relates [00:01:00] to, to the thing that I mentioned before about not committing sensitive data into Git or whatever version control you're using. Um, you know, just don't do that. Like there are many other ways or choosing dot and files or Usually that's what, what we do.
Or sometimes we can also have uncommitted settles to the PHP files for various environments that, you know, store these sensitive things in them. And that's how we can avoid doing that. Um, then we also have broken or risky crypto algorithms. This refers to cryptographic algorithms [00:02:00] that are not considered safe anymore.
Um, and so here, the most obvious example would be MD5 hashing algorithm, which is it's, it's not considered safe anymore. Um, the same goes for SHA one. There maybe are situations where they are still okay to use, because you know, the nature of the problem doesn't require a secure hashing algorithm as, you know, SHA 256 or 512 are. So if you really know what you're doing, you could use them in some cases, but then there's also the fact that as soon as you use [00:03:00] one of those algorithms and you have some, either automated checks going on in your CI/CD stack, or you have outside security review that you need to pass or something like that this will be flagged for sure.
No, there's actually no reason not to use secure hashing algorithms everywhere. So my recommendation would be just use SHA 256 when you need hashing. And and don't even consider using those ones. Um, there's really no reason not to do that. And then the third one is insufficient entropy. Um, I would say in our case, this comes to using random generators that are cryptographically secure versus random [00:04:00] generators that are not.
In PHP, for example, we have this RAND function, which is a random generator, but is not cryptographic and insecure. Um, we can even look at the API page.
So RAND function and we have this, you know, pretty big caution here that this is not cryptographically secure. So random data that we got from this function should not be used with cryptographic features. Um, and this caution even suggests some other functions that are cryptographic and secure, like random in or random bytes, depending on what type of data you need or OpenSSL random bytes.
Um, and just as I recommended [00:05:00] before to simply not use MD5 , I would say simply don't use RAND function and just use one of those. Cause then, you know, you, you develop these habits. Um, and even if you know what you're doing, maybe you're in a hurry. Uh, maybe I dunno, it happens to all of us, if you develop this habit of always using cryptographically secure, random generators, you will be on the safe side no matter what.
So I, I would recommend you to do that. Like what I personally do. Um, I use these even in unit tests, cause it's just like, I'm used to using those and don't even bother using rand anymore. Um, and I know that in unit tests, that would be nothing wrong with rand, but it's just a habit and I think it's a good habit.
[00:06:00] Um, then in this Cryptographic Failures topic. We also have consideration about data that is in transit versus data that is addressed when it comes to data that is at the transit. You know, we have to ensure that we are transmitting data over safe protocols. Uh, so on the web, I see no reason whatsoever to use plain HTTP anymore.
I think that we should always use HTTPS. In the past. We, you know, we had problems with where to get certificates that would be accepted by browsers and all that. Nowadays we have Let's Encrypt which works in every major browser. Um, and even on, on most cloud hosting providers [00:07:00] they can be enabled with a single click or even enabled by default. So I think that we should always use HTTPS. Um, and even more than that, if we always use HTTPS, then we can also use HSDS header which tells browsers that this domain that we are serving from, will never transmit anything over plain HTTP which will then result in browser complaining very loudly.
If something is supposedly served from a plain text protocol from supposedly our domain, which is, could it be something that an attacker would do. So yeah, definitely. I think, and, and. I do think that for the most [00:08:00] part, we are doing pretty good job with that. Um, then when it comes to protocols, like we also, our projects will communicate with other systems to get data, to send data and all that.
Sometimes this goes over HTTP where again, we should always use HTTPS. Uh, but then sometimes we also use other protocols like FTP and bap and not. So we should try to avoid using protocols that are as secure, like plain FTP, plain SMTP and use, you know, content parties that are using secure channels instead.
Um, cause you know, every time when we use a plain protocol and sending data around in plain text, we are risking that somebody will be sniffing on the network traffic [00:09:00] somewhere. And we will pretty quickly expose either our passwords or God forbid, something even more critical, such as like personally identifiable information of our users, or financial data or, you know, many other things that we want to keep secure.
And then when it comes to data at rest, the best the best tool that we have is to actually not store the data. Um, so first question that we should ask ourselves is, do we really need to store this thing that we think we need? And if the answer is no. Then just don't store it and [00:10:00] that's the safest way to do it.
Um, if that's not the case, which, you know, a lot of times it's not, we have a few module modules that in Drupal that can help us secure this data. Uh, and I will show you a few. So first one would be the Encrypt module.
So this is a module for Drupal 8 and 9, and also for Drupal 7. Um, and it's an API module that provides tools for symmetric and asymmetric encryption. So it's quite a low level thing. Um, [00:11:00] and then there are modules that integrate with it. Um, so one interesting could be field encryption which will let you encrypt your fields and your entities.
Um, so if you, you know, if you have, let's say you have a user profile and then on the user profile, you have social security number or something like that, then you want to protect that social security number. Well, when it's in the database you could choose for the encryption module to do that. Um, Then obviously you need to make sure that your encryption keys are not exposed to everyone.
Um, [00:12:00] uh, you would have to make sure that you use different decryption keys in different environments. You have to make sure that encryption keys are obviously not committed in the Git repository and things like that. But, you know, it's, as we said, it's another layer that gives us some protection and well, if other layers failed, this layer could save us.
Um, and we also have webform encrypt, which will encrypt web form responses if that's what you need file encrypt, that will encrypt files and so on. So definitely something you can look at.
Then another module that can be useful is the key module which, you know, there it's, it's a tool to securely [00:13:00] manage various sensitive keys. Um, I personally prefer to do these things on the infrastructure level you know, either true or true local settings.php files, whatever fits better, but you know, if you like something that has a UI, it's more sorry into, towards side builders, the key modules, something you can definitely look at.
Another module that is not specifically related to cryptographic failures, but it's definitely useful it's security review module security review. We'll do numerous checks related to security and, [00:14:00] you know, list any problems that it finds. So this could be a good thing to use for example, on a checklist on a before go live checklist.
You, you enable this module and check if everything is in order, just to add another layer of security. So. Let's see if I have anything else in my notes. Yeah. Another, another thing that is very important. And in our case, it's handled very well with by Drupal itself is password hashing. Like a lot of times we would have sites, either storing passwords, plain text to the database, which is really bad or using unsecure, [00:15:00] uh, algorithms to hash passwords.
And that is important because if our hash passwords are leaked, somehow, for example, you know, by exposing our database backup, to somebody that could be used to then crack those hashes and figure out users' passwords. And since users tend to use the same password or many different sites, then this becomes a really big problem.
Um, and now if we are not, if we are not implementing this ourself and we should not in Drupal, Drupal uses PHpass to do that in a secure way. Um, so something to be aware of, it's an, an interesting algorithm to look [00:16:00] at if you want to study it how it works. Um, it's implemented in this PHpass hashed password class.
Um, but you know, if we're just using it it's basically there doing its job for us. Um, and that's it. And we are thankful for that. Um, so yeah, like a lot of, a lot of times in Drupal, like don't reinvent the wheel, don't, you know, reimplement, APIs, that Drupal already provides because that's basically the reason why we're using Drupal.
Um, sometimes this APIs are a little bit harder to understand, I'm aware of that, not in this case, because this is really just works behind the scenes out of the box. But sometimes things like form API and [00:17:00] caching API can be a little bit hard to understand, but when you, when you master it It also becomes quite easy.
And here we come back to the culture thing. Like even if it seems harder to do that, to do something in a proper way of using Drupal as APIs, it's really worth investing some time and learning things. And then even more importantly, helping other teammates to learn that same thing as well. Um, than going in and hacking your own solution from scratch is that will always end up being problematic at the end.
Um, and culture and peer reviews relate to this aspect [00:18:00] from, from the point of view that, you know, if we see something that is wrong, somebody trying to reinvent the wheel, we should . raise our, raise our voice, let them know, and, you know, talk inside the team, why this is important and how we will, you know, learn to properly use systems that we have, and that come with Drupal.
Um, because it will be better for us in the long term. It might require slightly bigger investment of time. And usually not that much at the beginning, but then long term, we will be on a much safer side and not only security wise, but also performance wise. And, you know, updates will probably be easier because if we're using APIs that come with Core, Core, won't just break stuff.
While if we do things in some weird custom way [00:19:00] Core might unintentionally break something that, you know, we took for granted. So again, culture and peer reviews and being open to learn all the time. That's also something that's very important. You know, what it means to in general.
Are there any questions?
Michael Meyers: Janez? Do you want to take a, a minute or two break before we jump into the next one, no fine. We can continue. Awesome.
Audience: I do have a question.
Janez Urevc: Sure.
Audience: Can you give any insight about the use of the HSTS header and here here's our challenge, our main application, it's not Drupal, but it is written all in PHP and we use HTTPS there throughout and we also a redirect on that, [00:20:00] but we have legacy content on our CDN that links to. Um, from our, from our main application that does not support HTTPS.
So is there any insight besides change the legacy content so you can support HTTPS with? Cause the challenge that we'd have is if we implement the HT or the HT HSTS header, we're going to start to get errors coming back from that legacy content.
Janez Urevc: No, I don't think like besides trying to move the legacy content to HTTPS, I don't think that you have any other options because this is, this is basically the point of HD.
HSDS, sorry. Um, that's the whole point. Communicating to browsers that all the content that we will be serving from this domain will come from, [00:21:00] through over a secure channel. And if we are breaking that out ourselves, then it won't work.
Um, so depending, depending how, what kind of this system is, you could know if you cannot change the system, you could maybe put like an SSL Terminator in front of it. Um, and no proxy, proxy traffic to this legacy content through that SSL Terminator, for example, this could be one solution that, this can be implemented without touching the legacy system and just, just putting something in front of it.
So maybe that's what you could do.
Audience: Actually. Thank you for that. I hadn't, I hadn't, I hadn't even thought about that as an option, but that might be something we can look at for it. Um, changing, you know, in an ideal world, we could update all the legacy content, but the, the, the that's a [00:22:00] monumental task.
So maybe you suggested proxy and SSL Terminator, might be the way to look at it.,
Janez Urevc: We, we unfortunately don't live in an ideal world, so
Audience: We don't. Okay. Thank you.
Michael Meyers: We just implemented a, a similar system. Janez, just built a proxy for a massive migration where a lot of the legacy content can't be migrated in time. So it it has to solve problems like this among many other things. So it's sort of like a dynamic translator to make it seem as if some legacy content has been migrated to the new system, to be able to launch the rest and buy them another year.
Um, so happy to share some of what we've done on that front outside of this, any other questions for Janez?[00:23:00]
Awesome. I wonder if marketing folks got involved or more involved in the OWASP. I love the rebranding of that topic to cryptographic failures as the cause, as opposed to the original, which was the, the solution. Um, I think I also love the fact that they're combining things now. It's really the P 11 cause next up is injection and cross site scripting.