From the Crypt to the Code: Web Security Explored Through Horror Movies

It's not the first time, like first time being in the States, first time giving a talk in the Planetarium. How cool is that? And I'm able to share with all of you. So this is just wonderful.

But while having a wonderful tone on this talk is a little difficult because even though Halloween is over, there are some creepy things, scary things, dreads, nightmares still there, which will not go away just because Halloween is over, right? So but have no fear. We're in it together. You are here with my first time Planetarium. So you're my companions. And let me bring you on to a journey from the crypt to the code to explore web security for horror movies.

And before I start real quick, I will have two tiny disclaimers for you. The first one will be a slight spoiler alert because of course if I try to teach web security for horror movies, I might need to touch on horror movie plot. So no worries. I will not spoil the complete films for you. But I will make sure you get what I'm talking about. Though, even when horror movies are not your cup of tea. And the other one, of course, horror movie plots are sometimes not that friendly to say it like that. So I will try to be as like kind and harmless when it comes to my voting. But if I slip sometimes, please bear with me because horror movies are sometimes intense. And yeah, I might to mention some plot points. So slight content warning just so you know.

Well, I don't know if I can see the audience that great. But maybe I can have some light because I have a question for you. If you see movies or Halloween or basically horror movies throughout the year, did you ever hear this quote, I'll be right back? And a person leaving. Yeah, I'm happy I'm not alone. I hope you're at least slightly annoyed because if I see this, I'm really annoyed because why should you split up at all? It's a bad omen. Don't do this. Don't do this in horror movies. It's so famous. It became a meme and I guess that tells you everything about this intelligent plan to split up. Right.

There are lots of people in horror movies doing weird decisions or even stupid ones. And we are like right behind our TV and saying like, ha-ha, I would do it better. But really, I really hope you will never get into a horror movie like situation. But we don't need to go that far because there are scary and important situations in our daily life as a software developer, which can become a horror movie. Right? Yes.

I do think that there are lots of parallels between web security, security issues, and horror movies. Not only people doing weird things, not listening to warnings even if they're clear and right in their face, stuff like that. So of course they are not completely the same. But there are lots of parallels we will discover later on. And even complete polar points of horror movies, mirroring complete incidents, which is really cool. Those titles here are, some might sound like movies but they are not. They are taken from the media because these are actual security issues. And they're pretty famous and pretty dangerous. For example, Heartbleed is a vulnerability in the popular open SSL. So, yeah, they're here. They're real and they cause lots of damage.

But there is a positive thing, which is they're in the real world, which will help us in horror scenarios as well, just as it helps people in horror movies. The wonderful friendly professor, a team, a nerd, a group of people, helpful and capable people helping the protagonist to survive. Like this professor I tried to draw by the movie Sinister. I don't know if I made it, but you get the point. So there are lots of people helping us no matter if it's inside of a horror movie or in the real world.

Okay. I guess you never tell anyone. Okay. The team which will help us is called OWASP. OWASP is the short term for Open Worldwide Application Security Project, and it's a bunch of people which have a goal to raise security inside of the web. So they are trying to nudge us to know what are the most dangerous risks on web. And they do a ranking, or I guess four years? Not bad. So the ranking of the most important security risk to take care of. And I guess the last ranking was in 2021, if I'm not mistaken. And I used them as a basis, because they are really helpful, to craft our security survival playbook. Just like other a little ironic horror movies like Scream or Zombieland are doing it, trying to give us roots to adhere if we are inside of a horror movie situation.

So okay. Not that much talk left. Let's get into the first horror movie. Okay. This is the first one. And at least the original movie is the oldest one. It's from 1933, I guess. But there was a remake in 2020. It's on the invisible man. And like the title already told you, it's about Griffin, who's a scientist doing an experiment and failing miserably and turning out to be invisible. At first he wants to hide because it's a bad condition, right? If nobody can see you. But of course, invisibility has some perks. So he quickly makes use of it. First by doing pranks, but then being tempted to do crimes or even worse, things such as murder. So not that kind to other people, right? So yeah. This is the fast plot summary, basically. And I do think this plot is a wonderful allegory, a wonderful example for the most important risk for us. This is called broken access control. And it's on the first rank, which basically showcase its importance for us, right? I guess when it comes to the data set they use to evaluate which risks are important and whatnot, they have the most occurrences in the realm of broken access control.

Access control generally means that a user cannot act outside their intended permissions. And a failure obviously means that a user is well capable to do that, like an invisible man who cannot be seen and can do whatever they please. So yeah. This can lead to many things, like unauthorized information disclosure, people being able to modify things they shouldn't be able to, or even distractions. Yeah. I'm looking at you, course, or took a manipulation. This could happen.

So okay. Let's get a little deeper into the parallels. Invisibility can hint to unauthorized access. Because an attacker can operate unseen, such as Griffin can. They can go in, they will not be seen, they can wreck Harvard, read stuff, access sensible data, stuff like that. And such as Griffin did by doing crimes and stuff. It's abuse of the power of inability. Or in security terms, abuse of power beyond what should be allowed. Quite good parallel.

Another one is a false sense of security. If you can see a perpetrator, you feel safe, right? Because there's nothing. And those people which are not seen, either an invisible man or an attacker, cannot be stopped. Because guards and locks cannot stop what they cannot detect, right? Pretty bad. So poorly implemented access can lead to a false sense of security. And even worse, if you don't block it, you cannot know that there is a breach, maybe. And last but not least, an invisible attacker will leave no traces. As said, when it comes to without purple locking, nothing happens. You can exploit your data. And you have a mess.

So what can we do to survive invisible man? Or broken access control? Your default mode of operation would be denying by default. If you have, for example, a default user without any assignment, for example, they shouldn't be able to do anything, unless the user or the endpoint is a public resource. You should try to minimize harm by using rate limiters in your API and in your controllers. So if people can do more than they intended to do, it's just a small area of damage.

If you have stateful session identifiers, you should invalidate them on a regular basis. As soon as possible and the faster, the better. When I think about a JWT token, you should have them short lived. And if it's not possible, you want to have more convenience for your user, try to think about using the OAuth standard. This makes the attack window a little smaller. Last but not least, you can think about implementing and reusing access control mechanisms. And there are plenty you could take a look at. This can lead to minimizing cause, without sharing on other things. A small recommendation I want to just mention here real quick is OpenFGA, which is inspired by Google Sansibar, a rule based access control, but has some RBAC and ABAC use cases as well. And it's open source, which I really like. And as far as I know, it's a cloud-native computing foundation project. So it's a reliable source you can trust.

Okay. Are you ready for the second film? Whoo-hoo. Well, I wouldn't be so happy to see this fellow, right? I'm talking about Hellraiser. It's a movie from 1987. Sorry? Pinhead is pretty famous, I think. But the plot, and especially for security, I want to take a closer look at a certain box they have, the puzzle box, which is basically the Norman configuration.

In the movie, there's a person, I guess he's called Peter or Frank, Frank, I guess Frank was his name. He's finding this box and he's basically solving it. The thing is, if you solve the puzzle, you will open a gateway to the hell-like realm of the Cenobites. And Cenobites are not that friendly. They're not coming just for dinner or for a cup of tea or something. They want to hunt people for experience. And I guess nobody was willing to be a guinea pig, right? And there's a woman, the lover of Frank, I guess, who tries to resurrect him, who solved the puzzle and became a victim.

This movie is a wonderful allegory on cryptographic failures. So basically all the failures related to cryptography, all the lack thereof. This point before, when it comes to all the over-spreading, it was previously known as sensitive data exposure, which is the most prominent symptom. But as it's not the cause, they renamed it. The movie Peril, as already hinted at, hints to this puzzle box, to the LEMON configuration, being an encryption system which is easy or easier to break. The Cenobites are the consequences of failure. So they will come and haunt you because they have your data, for example, or were able to access it. And the resurrection of Frank, it's a failed data recovery. So even if you try to recover your measures, you can never know if everything's in order, right?

Okay, how can we survive a hell-wager-like security issue? First thing is encrypt all sensitive data. Pretty easy, right? Use encryption algorithms and be really careful and thoroughly consistent. Try to classify the data you process, store, or transmit. Because this way you can identify which data is sensitive. You shouldn't store sensitive data unnecessarily, so discard it if it's not in use anymore. Use PCI DS as component tokenization or concrete it, and as I said, discard it as soon as you need it. You don't need it anymore.

The point which I would like to have you inside of your toolkit is that you try to not cache sensitive responses. Because if they are not cached, nobody can take them, right? And last but not least, use secure, strong, and up-to-date protocols such as TLS and try to avoid FTP or SMTP because they're a little old.

Okay. Now we're coming to my favorite allegory. I couldn't resist to take it in even though the movie is a little explicit to say it like that. I guess you already saw it at once or heard about it. It's on Alien. It's a movie, I guess. Its original one, the first part, was in 1988, and it's about a spaceship crew to investigate a derelict spaceship. They were a little too curious, I guess. Which led them to be hunted by a deadly extraterrestrial creature called Xenomorph. And yes, disclaimer is in place. Plot is explicit. I tried to take care of my wording. If not, I'm sorry.

The thing which made them a little curious was this cute little fellow who just wants to hug people. I guess if you're not up for a special souvenir, you should refrain, I guess, unlike the crew, which was not that careful. They explored a little too much and brung back a little souvenir. I do think Alien is a wonderful example of allegory on ejection because, yeah, the face hugger, it makes people to host. It could be a wonderful example for input validation bypass and the initial system penetration if an attacker gets their code implemented or compiled inside of your program. If you were hugged by the face hugger, the code injection takes place. I will just mention the name chestburster.

If you were hugged by the face hugger, the code injection takes place. I will just mention the name chestburster. People who saw the movie know what I'm talking about. When you become a host, there's an alien attached to you. At some point, the alien is big enough to live on its own. I don't get into detail but you can maybe see what I'm talking about. Because the alien will leave the host. And this is a wonderful example for code execution and system compromise, because the alien is out. It can wreak havoc, right?

Hello there. We haven't seen you more. And I guess it's not that friendly like the face hugger, right? Such as a complete system access is. And the resource consumption, it could be, too. So, yes, I do think Alien is perfect to explain injection. And this is the third rank in the ranking. So really important, especially for us frontend developers.

So what can we do? We should only use trusted sources, a safe API, which maybe even avoid interpreters or ORMs. So, there's less bigger injection vectors, so to say. We should try to think about server side input validation. We should use SQL features like limit or other controls so there's not that much data which will come into a compiler and escape special characters. And I know, yeah, we need to be careful when it comes to SQL structures, because users supplied structure names might be dangerous and might break some things. So it should be a combination of all those measures. The most important thing is sanitation. This is a simplified example I came up with to basically refer it back to Alien, right? It's like a defense against the injection, which is basically doing current time and decombination. So we will have a point, this if statement, where we try to detect host or patterns. And we'll throw an error if we see some, so the input is disregarded. And if not, we will do a decombination, like trying to throw away all the special characters we have. We can do it with libraries. We can build it on our own. We can do a combination of both, which I'm doing here. Like using DOM purifier to have an HTML sanitation, thinking about an SQL sanitation with the caveat of this user names.

And a command injection. I like to use Regex for that. I have a small summary, but because we have not that much time left, I will hope that can either take a picture or I will share my slides afterwards so you can just look them up. But you can catch stuff like XSS, things like script tags, SQL injections, commands, and even more.

Okay. Let's fast forward because of the time, because I have one more rank, which is not on rank 4. But in my opinion, it's really important. And I want to introduce it to you with this little movie. It's called the Blob. It's from 1958. And it's again an alien, but it does different things than a xenomorph. And it crashes on earth. And it's like a big, I don't know how to call it, blob, thingy. I don't know how to describe it, but you can see it in this poster. It's growing because it consumes things and living beings and gets bigger, bigger, bigger. It's growing more red, aggressive, and bigger. And this is bad, right?

It's my favorite allegory on vulnerable and outdated dependencies. A big blob of technical depth. A big blob of dependencies which you don't know why you choose them. You don't know when you updated last time. And yes, it becomes more and more bigger and terrifying and difficult to test and difficult to fix. The obvious parallel is the blob growth, which is dependencies or technical debt. The consumption of the victims by the blob is how vulnerabilities and like technical depth could spread to even more potential security issues or risks. Because maybe you missed out on a security fix, right? And the growth is unstoppable of the blob, such as when it comes to unmanaged dependencies.

So yeah. What can you do? I will be a little more quick now. You should remove all dependencies you don't need anymore. You should have an inventory of all version numbers. Or at least try to follow up with social media or change logs to know if there's more updates. You should try to obtain all of your packages from trusted sources and secure links and not just like somewhere on the internet.

And try to monitor if you have libraries in place or tools which are not maintained anymore. Because if it's not maintained, of course, you will not get security fixes. And last but not least, never ignore dependabot. Always update your dependencies.

Here there are some scripts you could think of, like doing the audit script, which will basically ask for a report of known vulnerabilities. You can fix it, outdated stuff. If something's outdated, you could use SNICK, which is a handy tool to test and have for security issues. And you basically update save. This is NPM check updates, helping you to upgrade all of your packages and dependencies to the latest versions.

There's a new OS branching coming in next year. As far as I know, they are collecting new data right now. So November, December this year. Okay.

I come to a close now. Let me sum it up with like general security horror movies rules. Like screen, basically. First, stay together as a team. Don't split up. Not even if you think it's a sneaky deal. For development, don't feel alone. Tackle issues with the communities. Don't be scared to ask for help. And we're all in this together when it comes to fighting security issues. Take care of your batteries.

In a horror movie, it's not that great to have an empty torch or an empty phone battery, just ask your tools. Try to check if they're up to date, if there's a new security issue or a patch, and just have a wonderful tool garden and nurture it. Double check if the killer is really defeated. So in a horror movie, sometimes people don't check if the killer's dead. And then they are super surprised that it's redescending. Same with your code.

Check your log in, test your code, test your fixes and see if it's really done. And last but not least, take your advice seriously. If there's a warning, there might be a reason for it, especially if it's clear and right in your face.

Well, thank you so much for being with me as a companion on my journey through horror movies. It made it way less scary for me. My name is Ramona, I work as a developer advocate for Auth0, and hopefully I will see you in a bit. Thank you so much for listening.

Thank you so much for listening.

Okay. So we have some questions here for you. Please. Someone is asking, how do you protect against social engineering? That's a good question. Is this virtually impossible? Well, of course you could check if some tools are on the market to help you, but of course people are people, right? I would advise to think for example, of course it's another discussion if it's effective or efficient or not, but you could always go for end-to-end testing, mimicking a user. So maybe that's a good idea. There are some AI testing tools out there, that could be an idea. And some predict things. I forgot the name, I will look it up, but these are the spontaneous things I would check out. But of course, people are being people. People are sometimes not rational. Even myself, I'm not always rational, so there's always a little uncertainty in it.

Yeah, definitely. I definitely have fallen for those internal phishing attempts. It makes it even more important to train people and to educate them.

Oh, wow. The next one is a popular question, and that is, what's your favorite horror movie? Ooh, that's an interesting one. Well, I love the A24 movies. So if you are into psychological horror movies, take a look at them. I'm not that much of a fan of Splatter or Gore, because I do think they have no better arguments to be shocking. So maybe Hereditary or Midsommar. Oh, those are really good ones. Love A24 and what they do. My first horror movie was The Ring. Oh yeah? I definitely have to check that out.

Okay, next one is from Matt. What was the open source tool you recommend for access control? It's called OpenFGA. I actually forgot to include a QR code, so just search for OpenFGA, or I guess I will add it real quick to my slides when I share them. Oh yeah, that sounds good.

Thanks for doing that.

Okay, we have questions from someone anonymous. Spooky. How do you test that something is secure? Well, there are some tools. I guess it's called ZAP by Ovaas, which you could take a look at. I'm not so sure how many open source versions of it are outside, but there are definitely some paid tools. And I actually saw a Cypress Hybrid with ZAP. It's pretty old. Hopefully, maybe I can find some time to try to update it or anyone else in the open source community. Combining test automation is a good idea, because hopefully I've already had some tests.

Yeah, so was that a call to action for the people here to update it? Oh yeah, do your tests, please. Sounds good.

Well, that's all the time we have. What a lovely talk. Lovely as in spooky, I guess that's a compliment for the talk. Thank you so much.

Yeah, thank you for your time. And you can find Ramona outside, or do you have a discussion room coming up? Is that right? No, there's no discussion room. So you should find me in the Q&A.

Every room with Ramona will be a discussion room. So all right. Thank you. Thank you so much. Applause.