Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk

Is it Phylicity or Toolkit? Hey there, my name is Matt Simon. I'm a Solutions Engineer with Snyk, so I'm working with customers of Snyk in order to basically improve the security posture using Snyk as their tooling of choice. Effectively, today's session is going to be primarily focused on open source in general and using open source inside of JavaScript and NPM in order to basically improve your applications and also make them more secure at the same time. This is primarily going to be from a security perspective.

So, without further ado, I'll get on to the agenda. So the first part of the day is going to be focusing on open source, and then what we're going to do is actually get into booting up an application and actually hacking it as well. So, if you're interested, you can follow along and hack the application alongside it. So, I'll quickly boot up the repo. So it's actually, I think it's Node.js.-goof. I'll quickly find it. It should be in my recent. There we go. And I'll send this through. If anyone's interested, I'll send this through in the Zoom chat, and feel free to get it up alongside it. And you can start hacking as well in the meantime. To run it, you need either MongoDB installed, or you'll just need Docker installed. So you can do one or the other. And I'll be running through... There's some example exploits in here, and there's also some more exploits inside of this folder that you can start playing with on your own side. I'll only be focusing on a couple of those in the meantime. But feel free to have a crack at this if you're in spare time of interest. So, without further ado, I'll go into the rest of it. After hacking into these, then we'll take about a 50 minute interval just to have a comfort break. And then we'll be going into kind of what you can do about actually fixing the vulnerabilities that we've exploited. And then I'm going to do a basic introduction at high level into Snick and kind of how we help secure things in your environment. I hope that all makes sense. Please feel free to stop me as I go along this presentation. I want it to be interactive. And I want you to guys to get something out of it rather than just talk in a monologue. So, please feel free to interact with me. Hit me up in the Zoom chat, or just come off mute and say hi. Yeah. Cool. I'll get started.

So, just to start off with, this is just a basic introduction to open source. And obviously, everyone knows what open source is and like the power of it and why we actually care about it. The main idea is that it's awesome because it helps us develop things in a quick, easy way. And it also allows us to do things in a more standardized way as well, because we can iterate over each other's processes and find out communitively, what is the best practice for doing things. So, as an example of that, I was on the hunt yesterday or over the weekend to buy new computer parts. And we've got a website in the UK called scan, which is the scan.co.uk. And this is a platform for buying computer parts as such. So, what I'd like to do as a bit of an exercise is to kind of, even if you haven't seen this website before, if you could come off mute, just shout out what you think certain parts of this web application are hosted via or supported via open source, just to name a few functions or name like different ways in which you can automatically know. Let's say for example, clicking on the help ticket, what they would actually do and how that can be supported by open source. Does that make sense? Yeah, for sure. The basket. It's something which, you know, every basically commerce website has, and it's something which is standardised across them. Yeah, like a lot of it, Joe. It's like the more you look, the more you realize that, yeah, it's definitely powered by open source as far as things like your login, for example. Like you've got this little help button down here, which will open up like its own window and widget and then have like a chatbot features inside of it. And while the chatbot may not be free, it may also be powered by some other kind of service.

These could be external advertisements. So they could be kind of you click them and they redirect you to another site. And the process of logging that and kind of tracking the monetary, like the clicks and like how much money that's actually generated would all be done by open source projects.

Rather than, you know, if we were to sit down and say, I want to design a new website from scratch. And I want it to look like this. Like you're not going to have to start actually from scratch. You're going to start implementing different kinds of open source packages in order to automate a lot of the work that goes into this.

So what that actually means in terms of reality is that when you actually think of your application and how it functions, it's like quite a large chunk of like, data and ability and raw power that this application has as a web app. But in reality, like the actual things which you're contributing to it and the ways which you're manipulating things is like a very small part of the overall picture for how data is flowing throughout the application.

And it's really useful to be able to do this in the way that we've explained how you can quickly boot something up or quickly replicate something like this, and get that function across. But it also means that you don't have to own the entirety of this site in the sense that you don't have to own how the basket works and how the Elasticsearch works. If there's any kind of issue with it from like a... like you get bugs or you get some kind of like security vulnerability in it, you yourself as the developer who built that website isn't the one ultimate who's going to be responsible for everything because it's community-driven.

So, it's something where, you know, you get the ability to crowd source that kind of tech help and that kind of support as far as actually like fixing things goes. But that also works out like quite scary in a way, which we'll talk about later.

This is a little bit about how you basically can see NPM and open-source in general has taken off over the last couple of years. You can see NPM in particular is gaining a lot of traction as far as the amount of new packages that are being created in that region each year, where at the moment, you've got something like 1.8 million open-source packages which are currently in use. Obviously, then you have vulnerabilities inside of those as well.

What this stat is here is it's representative of how many vulnerabilities can actually be found in indirect dependencies. What I mean by that is specifically... If you bear in mind that you can find 86% of all vulnerabilities are found in indirect dependencies, if I show this slide, it should be clear what a dependency is. In this case, I've got a package being used called express, which calls in accepts, which calls in MIME, which calls in MIME DB.

What this is effectively like, if you can imagine, let's say I'm a kid, and my parents are out of town for the weekend, and I'm inviting over a friend. That could be my express in this case. I trust him. I know him really well ever since childhood. I feel comfortable letting him into my house. Then he brings over a plus one. I'm like, oh, okay, I trust his judgment. He vouches for this character, I'll let him in. Then the plus one brings over a plus one, and then the plus ones bring over another plus one. Then you end up with this series of escalating uncertainty with regards to what you're actually bringing into your application and what you're not actually being able to see about and have confidence in their security standards and their practices overall.

That's basically what's happening when we see like, when we look into all the vulnerabilities here, where you may trust the parent dependency which you've got inside of your package. I may trust express in this case, but the reality is that I can't see all of the transit dependencies which express will be pulling in very easily. I also can't vouch and look into the security for all of those. You ultimately end up with a situation where you just have a lot of uncertainty in the overall security of that application.

The question is then, we've taken into the consideration like what the risks are with using open source, and we've considered taking into the benefits of using it as well. The question is now like, what is the overall security posture with using open source? Effectively, in the same way which you have crowdsource value out of open source in the same way that everyone's contributing to these projects, you also have people contributing towards databases which uphold information around vulnerabilities.

Effectively, the answer to how can we trust things is basically you trust others again in order to provide open source vulnerability data. People are very open with doing this and they're very proactive with it as well. But it has to be done in a way which you can actually like you have visibility of as well because you're not just going to sit there and kind of watch all the threads and order the different packages which you're using on GitHub because nobody has time for that. You have a life at the end of the day.

We'll go into a little bit about what that actually looks like with Sneak in general, and there are other tools and ways of doing that, but I'll save that to the end. We'll leave that to the end in the meantime.

At the moment, what we're going to do is go into a little bit of Q&A or a little bit of a guess the number kind of thing. So the question is here, what is the percentage of packages on npm that have no dependencies and no dependents? So these are in this case packages which just sit on their own and then they don't have, okay, 6% coming out from pizza, 12%. So these are things which are just independent, you don't need anything to run them, and they aren't used by anyone else. So 28% of packages are actually not using any kind of dependence and they also don't have any dependencies based upon them. But these are the things which aren't necessarily gaining a lot of traction. So these aren't the most popular packages.

They're just kind of packages which are spun up in order to achieve certain things, and then they're used via other kind of community members. So that was an interesting stat for me to learn personally because I, like most of you, I would have said 6% of this.

Another one is what is the average depth of a package dependency chain on npm? So this is specifically packages which have dependencies. How long is that usual chain? We've got 2, 3, 4, 3, 3, 3, 3. Okay. Average is about three. So the answer here is actually four. So once again, we're kind of just looking at stats. It's a bit strange to look at that, actually. I probably should have put like five and some extra options to make four look like the median option. But yeah. Four is the actual correct answer here in terms of the average chain of the dependencies.

And then, finally, how many packages in npm could be considered abandoned? So this is basically, out of all the packages which we saw at the start, that was 1.8 million, how many of these haven't been updated or touched in the last year? And these aren't things which are put on, I guess, maintenance level. These are ones which actively haven't had an update or haven't had any notice about them or bug fixing in the last year. So 61%, that'd be scary, 27%, 15%, 27%, okay. We're being a bit more of a spread here. Yeah, the answer is actually 15%. So that's an interesting stat as well. So out of the 15% of all open source packages, they were kind of brought up as a, yeah, it's good isn't it? But yeah, 15% of all packages just aren't being touched anymore. They weren't put on a watch list. They aren't being maintained in any kind of capacity. So completely abandoned, no sign of life. It doesn't mean that they're vulnerable, but it means that like the maintainers, the people who actually originally worked on it, they just aren't actively looking at that project and reviewing any kind of pitfall about it.

Yeah, I'm responsible. Yeah. Well, as long as, I think the main thing is that if you get notifications about people finding issues inside of it and bugs specifically around security, I think you should have at least some kind of eye kept on them to make sure that actually, if someone's doing the work of promoting like a pull request, which would fix things, put a little bit of effort in just to kind of validate that and do some regression testing and merge it, because it goes a long way, as we've seen before, to kind of supporting the whole ecosystem because you've got chains of four. So your open-source package might be used in a lot of things.

But yeah, so here's another thing about open-source in general. This is another guessing game here. So this is about once you've actually figured out like, you know, what kind of packages you've got coming in from this chain in terms of you've got your Accept MIME and MIME DB. And we've already established that those might not be ones that you necessarily trust, especially considering the stats most vulnerabilities are inside of your transitive dependencies. But the question is then like how can things get vulnerable inside of those parent dependencies? So in that example of Express in that case, we have the kind of attack known as typosquatting. So this is basically where somebody has actually named or created a new package which is very similar to a well-known and well-trusted package in the hopes of basically tricking people into using a slightly different name prevention, or making a typo and installing the wrong kind of package and deliberately putting something malicious in the case.

So have a quick guess, can anybody guess what the correct actual type of package is here? So this is the official package in this case. I'm looking for, is everyone familiar with crossenvironment? Has anyone used it before in the past? Effectively, one of these is the right answer. Okay, cool. So the answer I can tell you is actually C in this case, which nobody actually said. So this is the correct package in this case. So a lot of people, if they Googled it and crossenvironment, like for example, with Outlet Space, was still showing up and were still malicious, MPM has since removed it, would cause a lot of problems and so would A in this case. A and C are actually very similar. And if you referenced A on its own, then it would be fine, like your MPM would go and grab the correct version C in this case. But that's only because MPM has locked out a name and convention of cross-environment to stop people from creating that and so that it defaults to.javascript. But the official name is actually crossenvironment.javascript.

But the main reason I wanted to bring this up and kind of play that game is because it emphasizes how easy it is to make these kind of mistakes as a human. And if you weren't writing this yourself and you were just kind of reading through a package.json to find, let's say, look at, in my express case, for example, I want to look at this structure of dependencies and express a used environment, cross-environment without the dash.json. And it's just use cross-environment. You could very easily just not realize that that was a malicious package being installed. And then the other kind of vulnerability that could end up happening and causing a parent dependency to be vulnerable, vulnerability in that case, could be in the case of where accounts are compromised. So this is basically known trusted maintainers lose their privileges or lose their publishing rights and they actually become compromised.

So this is basically known trusted maintainers lose their privileges or lose their publishing rights and they actually become compromised. So people start uploading malicious code to very well-trusted packages. And this is like a real thing. And it has happened in the past. So one thing which I'd say, if you are maintaining any open source libraries, what I would do on these libraries is make sure that they have two-factor authentication enabled on them. So this can literally be a case of making sure that before anyone pushes anything to your GitHub repository, maybe they have to have a setup, second kind of touchpoint in order to enable that. So that if your secrets, for example, get released and people have access to your GitHub account, they can't actually make changes to that without using two-factor authentication to prevent your exposure becoming like a wider problem, especially if you're maintaining lots of open source projects then effectively, and those are getting downloaded millions of times, that can cause like a much bigger widespread problem. And that's ultimately what people are fishing for those secrets for to gain ever greater privileges elsewhere. So that's two of the ways in which you can basically start maybe doubting the way packages are maintained.

I also want to tell you a little bit about cross environment as a case study as well. So across environment was and still is a very popular NPM package. It's used for handling environment variables across platforms. So this is in the case where let's say, for example, the difference between Linux and Windows, if I wanted a reference and environment variable in Windows, effectively, it'd be very different to referencing that environment or creating a new environment variable in Linux. And so, in order to smooth out that process, rather than doing like an if, you know, and checking the system process and processes in order to figure out what the platform is, and then changing your commands based upon that with a case switch, effectively, you can use this variable or this open source package to handle that for you and just give it the command which you want to, or the environment variable you want to create. So it makes it smooths out that process.

As of today, it's getting about 4 million downloads per week. And I checked this literally yesterday. Over 5000 of those downloads are actually packages which are dependent on that. So it's built into a lot of chains. But back in 2017, it was actually exposed to basically a typo squatting attack. where somebody created the environment, or the package name, Cross Environment. Where basically this was released, and it was only available for about 12 days before somebody found it, reported it, and ultimately was taken down by NPM. But during that time of 12 days, it had nearly 700 different downloads. So 700 people were potentially exposed because they literally used a typo, and they didn't put a hyphen in there. And basically because this was obviously being downloaded via other packages, effectively, that could be exposed to a lot more people inside of that. So it was a very real risk associated with it. What it was doing was effectively wrapping the core functionality of Cross Environment. So if people were to kind of spin this up inside of the application, it would work as normal, and it would be very easy to go ahead and like not notice what was happening. But what it was also doing is it was capturing the environment variables, and it was sending them over to a remote server that was hosted by the attacker. So effectively, as you are going to create environment variables like keys and tokens, and whatever else you needed to save, it was also being pushed to an attacker as well as from the IP address, which is being sent from it. So people were able to actually figure out what your individual tokens were if you downloaded this package and used it. So it's a very real risk in the industry in that case.

Thankfully, this is the part of the talk which I hope you will come to see. We're just going to be hacking an application live. So we're going to go on to the actual security side of things rather than just factoids. So this is a little bit of an introduction to what SQL injection is. So I'm sure lots of you know what SQL injection is, and this is just going to be very high level just to introduce it. But SQL injection is basically where you can break out of a normal SQL string and basically populate it with all kinds of variables in order to perform malicious acts. So this can be impersonating users and potentially dropping tables or installing your own things or even kind of creating new tables yourself if you want to. So this is our example in this case where, in this case, I've got this user.find function here, which is being passed to it of a username and a password directly. So this is going off and creating a SQL query where I'm basically looking to log in. So in this case, I'm being passed a username, being passed a password, it will go ahead and find if there is a user in this case. And if there is a user, then the length of that user returned is greater than zero because there is somebody found in that case. And then what it will do is it will redirect the page to an account. And then it will say you have logged in as this person. So that's what we're going to exploit in this case. And I'll quickly run through that over here. So this is my vulnerable application. For those of you who weren't here at the start, I linked out and I'll share it again real quick. I linked up this vulnerable application. It's hosted here, and we actually have walkthroughs in this app on the ReadMe on how you can exploit things yourself. So feel free to download it, play around with it yourself and hack it. But what I'm going to be doing is it's going to be used as a to-do list. So I'll say, hello everyone. And what this is, is basically a to-do list. So I can just create lists inside of it. I can upload files, I can look into like the about page, which is just like, you know, it's very basic at the moment. It's just for the sake of kind of being able to break it. And what I've got over here is, let's open this up, is this is the term that is being hosted here.

So what I'm going to do is I'm going to try and log into it just using Curl in this case. So just to show you what it should work like, and this is going to be logging into the website in this case, which is my local host. And I'm not going to type anything in because I'm on camera and I don't want to make too many typos. It's not fun.

So what this is doing is it's going Curl, it's going creating a cookie jar and it's going into the content type of application, JSON. And inside of that, I'm passing variables to it. So I'm trying to reach the login page here, which by the way, I'll be sure that looks like, looks like this. And inside of these variables, I'm passing my username and my password, which in this case is an admin username and the super secret password. So this is very literal in this case. I'll just enter that in and you can see here on the left or you can see here I've been redirected to admin and you can see here on the left, I have this user logged into admin message. I'll just make this a bit bigger so it's easy to read.

So the question is now, what will happen if I try and pass in a wrong password? And the answer to that would be, obviously it should come back and just give me an error message saying that it's not been found or that the user can't be found. So in this case, I'm getting 401, so I'm not authorizing those to access that. And that's basically a proof of concept that this works as a very basic function in the sense that if I go back to here, this actually works to validate, to find that this was the incorrect password in this case, so it didn't log me in.

Now, the question would be, how I can start going in and hacking this. And in this case, does anyone have an example or have any suggestions while I can start entering into Hackett? Well, if not, you can write it down. Anything in the chat if you wanted to write it down? Null-identified password? Yeah, you could start trying to enter something in like that. I think in this case, it wouldn't work because we're checking to find the exact case of the password. So, it wouldn't come back saying it's been found. It's going to say, it's a null-identified password. It's going to say the exact match in that case. So, what you would need to do is actually break out of this command here. What you can actually do inside of this, and I'll show you now, is you could enter in. Yeah, you could try and break out of it with a one equals one. It's not going to work in this case because I haven't shown this to you, so, I'll go ahead and show you what the answer to, it is in this case. Then I'll show you at the end how you can actually fix it. So, I've just got this predone. So it's over here. So, what I'm entering in in the password field in this case is actually an object. So, you can see here, this is just the way which is annotated. So, this curly bracket here is closing the original data binary. And then, so is this is closing the data binary we've been entered in. But in the password field, rather than entering in a string, because I'm not validating for a string in this case, I'm literally passing an object with it. And then in the way which this works is effectively because we're validating for a length being found, we're going to come back and say it's actually greater than one or greater than zero in this case, and just force it to log in. So, it's partly vulnerable because we're not actually sanitizing for a string. We're not validating that the string's in there, but it's also vulnerable by design in the way in which this greater than zero function works in the first place. So, while it works in practice, it's not necessarily the most robust method of authenticating and logging people in. So, if we go ahead and run that, you can see it's now been redirected to admin. And that we've got this message back saying that we're now logged in as an admin in this case. And that was a little bit of an introduction into SQL injection. The next step now that we've got admin privileges is to start doing things a little bit more malicious and start grabbing things, we could do a couple of things in here, like grabbing cookies, or start introducing like cross-site scripting kind of things by uploading files, which we might not necessarily have access to. What we're going to do is do a password reversal or a directory deversal. So, what this is going to be is because we have access to a file, but we can basically, which is the, let's show you what that looks like on this system, we now have access to account details. So we have the ability to edit our own. Why did that come up? Oh, it's because I haven't logged in with this terminal yet. So let me log in again real quick. And I'm just going to log in using the super secret password and a new email, just on this browser real quick, because it's not, I think it should be saved. So once I've logged in, I should then have access to the account details, like so, and effectively what I can do is I can go into here and start populating them with my own things. What a partial issue is, if anyone's heard of this before, is effectively by entering in a variable, you can start going into a directory and start accessing things which you don't necessarily have access to. And the way you do this is by providing variable names with basically sequels of backslashes and dots.

So you're basically navigating up. So if I was to enter something into the account details, effectively, what it would do is go away from the account details and go back up to where the structure of the application lives well, not maybe able to access. And in this case, it's going to go over to my definition of my application so I can start looking at things like my source code and start looking at things like my package JSON, which is what I'm about to do. Ways in which you can secure this or ways in which this has tried to secure it is effectively it's actually got some kind of validation built into the variables here. So if I was to go ahead and do something like that and then look for let's go back again and the sort. And then type in like package Jason or something, it's not actually going to be able to pass anything through that, it's not going to be able to bring anything back because inside of these individual variables in the way it's hardcoded, we are processing them and we're validating using things like our trim validator and we're using like escape as well in order to escape out of these special characters. But one thing that we're not doing inside of this is we're not validating any new variables which are created. And obviously, in the way this is given to us, I can't enter in variables in this format, I can literally create new variables inside my terminal when I'm passing in curl objects. So what I can do is let me run over and I've got another command and just on the side, just bear with me. It's coming up somewhere. Here we go. So I've got, in this case, I'm accessing this type of page here. So I'm doing a pull or post against the account details of this site here but what I'm also doing is I'm providing the name of the email. I'm providing the name of the first name, last name. I've got the country phone number, but then I'm also adding an additional field here, this layout field. And because this isn't something which is hardcoded in and I'm not expecting this, then I haven't got literally inside of my application I haven't got any validation being run against this input or this variable. So what I can then do is basically see what these variables end up looking like and you'll see I've got my name. That's a little bit... So this is my package.json, I've got my name, I've got my first name, I've got my phone number. And then it's got this package.json, which is kind of, it's gone back up the chain in terms of my file directory. And it's grabbed out this package.json, which is obviously containing all the information around my open source packages. So what I've actually been able to do from this is by typing this in to curl and basically having an admin permissions in order to make changes to my details is I've been able to go into it and get access to something which I shouldn't do, which in this case is packaged.json files. And with that, I can see information around other kinds of vulnerabilities using this. So because I know what these do and because I know how they interact with things, I can basically learn how to exploit them even further and do other malicious things. So one thing which I can look at, if I can find an example here, I know we use Mark as well. Yeah, we use Mark to version zero point three five, which has a vulnerability. So I can then go ahead and exploit Mark. So if I go back over to my slides, then you can also see that Mark has a example of a cross-site scripting injection. Or cross-site scripting is is effectively the ability to host code on the actual web page itself. So I can literally run in a script, inject it into the main page here, and then we people click on it and activate it on their client side. That's when something we'll get something malicious can activate. And this is very much like a very, very common type of vulnerability. If you're ever on a website and you click on something and some pop up flashes on your screen, then disappears and tries to hide itself in different ways. That's probably what's happening. It's probably like your HTML or your browser is being told to basically perform a script. And then it's happening on your server side rather than happening inside of the application. It's not like a code injection. It's literally something is happening inside of my client. So that's what cross-site scripting is. And the way in which we can make this happen is because we've got this vulnerability inside of Marked. So Marked is a very, very popular open source package. It's being used in about six million downloads a week, and it's got seven thousand different dependents on it. So seven thousand products are using Marked in order to make it work. And then you also have this vulnerability. So we're using version 0.35. This version was fixed a long time ago in 2016, but even though it was publicly disclosed in 2016, it took nearly a year for the actual maintainers of Marked to update their version here. So there was a sitting of pull request inside of Marked where somebody said, please, can you update this? This fixes the vulnerability. It took them nearly a year in order to actually patch this vulnerability. And this is something which allows cross-site scripting in this case. So you should all be very familiar with Marked.

It uses basically everything, uses it in order to kind of allow for HTML and fancy writing inside of their browsers. So things like Reddit uses it. GitHub, readmi's user as well. So it's very widely used in terms of like across the industry to make content very readable and very workable so you can do things like add HTML inside of it. That kind of thing. But, yeah, the main draw for using it is obviously being able to do content creation. But what we can do is actually exploit it as well. So I'll quickly go on and show you what that looks like. So inside of my GOOF, and you saw before I typed in a command, what I can start doing is start using Marked, which is the markup language, in order to start trying to inject some SQL inside of it. Sorry. Not some SQL, some cross-site scripting inside of it. So what I'll do is I'll start off with showing you why you want to use Marked. So in this case, what I'm going to do is post this. So this is basically the name of the text. And then inside of that, Mark knows that this is going to be a HTML link. So what it's going to do is it's going to process that, and it's going to allow me to add this as a interactable pop-up. So I can now HTML or hyperlink up the website, which I wanted to name. And you can do things like add like bold, for example, and then let that go into it and then suddenly I'll get bold text. It's very useful from managing a page and allowing people to create interactive things on your website. But obviously with that interaction it comes with a lot of risks, so they have to do a lot of validating on things. They do do quite a lot of validating themselves. So if I try and enter something in which is like JavaScript in this case, it will actually stop JavaScript from being executed inside of it or sanitize out. It will see you're trying to use JavaScript and you're trying to create this and it will actually block me from doing that. The only thing that will get through in this case if I go back is just this extra bracket inside of that because we're sanitizing the rest of them effectively. So this is you know it shows that the maintainers at this point in time were very security conscious and they had sanitized for use cases in this case. But if we go further down and try breaking it in some other ways, so if I try this iteration here. What we're doing here is we are trying to use some rejects in this case, so we're trying to break out of it and provide with extra content around kind of just tricking it and trying to add some extra content like different colors for example. This is still being sanitized so we're still being able to get through it like that. But in this particular vulnerability they had a an issue where they weren't sanitizing a disk amount and the way which this worked. So if I quickly open this and if you don't know what this is inside of JavaScript effectively the way it's working is inside of this it's basically creating or it's referencing an object itself but it's not being closed off in this case. So what we're doing because it's only looking for this being activated in a way which is like successfully closed or like accurately being used. So the way which the regex works is it's going through and it's saying look for an instance of of this and if it's closed off then maybe it's actually trying to do some JavaScript stuff and JavaScript would interact with that. But what they'll say is because this isn't closed off in a way which is accepting it it may manage to get through the validator. And the significance of this is it wouldn't actually matter because it would just be broken JavaScript in this case but what's happening is effectively while a validator doesn't pick this up and while the application runs this what are browsers doing very helpfully or not helpfully in this case is it's seeing that there's a problem with the JavaScript in here and seeing this being on represented or be unclosed and it's actually going ahead and saying this looks like human error. So I'm just going to remove that for you and what the product of that looks like is something like this. So you end up with being able to get through and create your own little demo or the code you've made to show that it's correct to run on it. So it gives us the ability to update our experience while we're on the source code, if there are problems in the backend. We got an alert for something. What we are just doing is deleting the warnings because we don't want the message to be on something that this isn't mentioned anywhere and it's not actually being used inside of it because well it's not it's basically just not being represented by our HTML browser isn't loading it because they're trying to grab some variables from the user and send them off somewhere, then I can start gathering information around the users that are actually interacting with this website. So that's one way in which cross-site scripting can be exploited in this particular example. And this is all because marked itself was vulnerable in this particular version. And if you have a look at marked and you go to the different kinds of versions inside of it. It's like a pretty old version. It was 3.5, 3.6. It's an old version of this, and it took literally a year between these two different versions to be updated. So there was a year worth of instances, where people actually knew about this vulnerability and they were actually able to exploit people using this as well. In terms of where I get all this information from, in terms of like what kind of vulnerabilities exist inside of that. You actually can go and publicly access Snyk's vulnerability database. So I'll just type this up and then I've got the database and then I'll quickly search for the... See this is why I don't type live because I'm not very good at it.

But in this case, this was the, I was using, I think it was, 3.6 or something like that. I think it was this one, in this kind of vulnerability here. So because I knew if I go back to my terminal here, because I knew the type of open source packages I've gotten here and I could spot which one was vulnerable in the form of that marked version here, I could go and exploit that further.

There's another vulnerability in here, which I'll go into now, which is inside of Validator. So Validator in this particular version is actually vulnerable to a redos or a redirected denial of service attack. So if I go into what that looks like, or regular expressions denial of service. Effectively, what denial of service is, is it's kind of exactly what it sounds like. It's basically when you're trying to stop a service from running, an application from running as intended. So you might want to take an app down, it could be used inside of ransomware in order to stop things working such as a user making a political statement, or stopping some kind of service so you can have access to another effectively. So that's why denial of service exists as far as a type of attack occurs. The way in which regular expressions denial of service works is effectively it uses regular expressions when you're validating information inside of a string, for example. So what validator does in this case, is it's used for all kinds of different types of validation when you're looking at strings and saying, I want to make sure it's a type email, for example. What that's actually doing behind the scenes is it's basically looking for regular expressions in order to see if strings or inputs which you're putting in match up to the certain characters that are being expected. But the way in which it works as an engine is effectively it scales based upon the complexity of the different kinds of variables you're putting in.

So in this case, you can see at the bottom here that I've got an increasing number of steps basically to handle different kinds of strings. And in this case where I've got 14 different C's in a row, and I can show you on our website what the regex behind this looks like, which takes this time to validate it, but you can see basically this takes 65,000 steps to process this. And the reason for this is because effectively there's three different ways or four different ways in which we can group up the C's. So what will happen is, it will start going through and validating and saying, first of all, we're finding an A, then we're finding a C, then we're finding another C, then we're finding another C. And what it's expecting to find after that is an X, and then it will carry on going until it finds an X. And basically each time it goes through, it will have to perform another step in order to back loop through it. I don't want to get too deep on regular expression here because it can take up a long time in terms of actually explaining the engine behind it and why this cascades into like a massive computationally heavy load. But effectively, if a regular expression is unable to find a group which it's expecting to, and it can't handle a type of character that you're putting into it, effectively, what we'll then have to do is, it will have to backtrack to the previous characters and the previous characters before that went to the point where it can put that character or that string into a certain group which is expecting. And this is known as catastrophic backtracking. And this is basically how you can perform some kind of redos on an application. That was probably very heavy, a lot of talking on my behalf. So what I'm going to do is I'm just going to quickly show you what that actually looks like in practice. So this is a particular version of Validator that this was vulnerable to. It was version below 13.7. I think it was the actual vulnerable version. So literally anything but the latest version. And if we go to Validator here, you can see that there's about 6,000 or sorry, six million different weekly downloads per week. And there's also 5,000 projects which are dependent on it. And there, the latest version, which was fixed in 2021, it took about three or four months for it to get fixed. It was first released, published as a vulnerability at the end of April. And then the fix was pushed through at the end of November. But even still today, there's over 400,000 weekly downloads of the vulnerable version side of that. So that's a massive kind of performance loss seen inside of that, where people can use it to constantly ping up a ping up the endpoint and basically break the logic, which is inside of your Validator in order to exploit it. The particular method, which is vulnerable in this case is rtrim. And the way it's being used is in this case, you can see an example here. What we're doing in Validator with rtrim is we're basically going through and we were removing blank spaces. So what this actually looks like, let's go over to the readme real quick and find validator. Sorry, find rtrim. See if we can find it. I should just control F. There's quite a lot of different ways Validator is being used. There we go, rtrim. So what it's doing is it's trimming characters from the right hand side of the input. So the input being like characters that aren't white spaces in this case. So what this ends up looking like inside of this is basically if I was to enter in an input like hi, or like my name's Matt or just Matt in this case, and then I enter a hundred different white spaces after I've entered in the input, then I can remove any different white spaces afterwards. It's going to basically go through them and then see after this next character is a white space.

And therefore remove anything after that and remove anything after that if it's a white space and basically just try and shrink it down to the point where there's no white spaces inside of it. The way in which this was actually vulnerable is effectively I can show you what the exploit looks like now. So I'll go over to my console again and I'm going to enter in a new query into it. I'm going to post against the account details again, and this time instead of populating it with a vulnerable file or anything like that, I'm just going to enter in a variable that's expecting to see, so it's gonna be in that first name where I'm doing this validation against with Arturum. And what I'm gonna do inside of that is I'm going to post to it and I'm gonna put a thousand or 10,000 different white spaces followed by an exclamation mark. And what this is gonna end up doing is it's effectively going to look like a massive open space and an exclamation mark. And the reason why it can't handle this is because the white spaces are at the front of the string. And also, then it can't understand that it's just a known exclamation mark because that's a special character which is not representative of the name. But the result in this is basically it's going to go all the way and look through and hold in its memory all of the different white spaces before it gets in the exclamation mark and realize that that's not actually part of like a group which it understands and then have to backtrack through them going the other way. And in doing so, basically take up a lot of computational time and basically just out the service for a significant period. So you can see like I've already entered the sim and I'm still not getting any response. If I was to refresh this, it would just be down. And it takes about 20 seconds in order to actually run this. So it's come back with a response now and the response ends up looking like this. I can't even get to the top of the screen because it's all just white spaces followed by an exclamation mark. Basically it's ended up falling on its place and not removing the white spaces there. So that's a way in which this is vulnerable.

Cool. I'm just conscious of time. We've used up quite a lot of it so far. Unfortunately, literally we just don't have a way of seeing that it's just a very basic app under the scene. So I can't actually enter into the account details and not see it. How can I get that package for Jason? So let me run back to what that ends up looking like. So what is it doing? And I'll quickly run over here and I'll get up my command again and talk through the way it works. Effectively, the package.json. So you've seen like this entry input. So the account details have been posted back to me in this case. But the package.json here is basically we're creating this new file or this new variable type layouts. And this is something that we can only do with JavaScript simply because it's effectively like, it's a variable in the object itself of the account details. And what we're able to do is basically providing the content of the package.json. So it's going ahead, our account, our page or our object is saying what is account details we're providing it with the definition from first name, last name and each of these we're going through and we're saying make sure it's a string, make sure it's a string, make sure it's a string except on and remove white spaces, but except on layouts. When layout is a new variable, we aren't hard explicitly trying to validate it. And because of that, we can provide it with a path, like a file directory. And what this is doing is it's going, Oh, I recognize what these are. I'm gonna go and grab that from this file over here. And it's going back up the chain of directories and it's going to grab the package.json and taking that as the object. So it's simply just not assuming that's a string. That's the problem with this. Is that answer? Does that is that clear? Why wouldn't it? Well unfortunately, it's just the nature of how JavaScript works in the sense that like it's not smart enough to. It's the problem with having a dynamically types language. It's just effectively just taking this and then running that against what it knows. Yeah. Yeah, I can share this PowerPoint as well. I'll just make a copy of it. What I'll do, all of the resources which I'm mentioning today in terms of and also the application and all of the references are as far as kind of in our database and inside of NPM itself. I'll send them through on the Discord channel so that they can persist after this, after the Zoom session ends. So you can have that reference there. And there's a thread in it inside for this chat inside of Discord. Cool. On the chat coming up. If you basically, I don't know. No. The only reason we're getting around the validator in this case is because it's a path which is not accepted. It's not, it's not encountered before. So what would happen is if we put in more information other than just like the bunch of white space and then the exclamation mark at the end, and we try to enter into JavaScript or something or like SQL, then we would pick up that there's SQL inside of it. That would flag up against the validator. What we're doing in this case, and what we're doing with the rtrim isn't validating to make sure it's a string or SQL or not. It's simply validating, it's simply trying to remove white spaces and that's where the bug was. When we looked into this, there wasn't any issue with the actual validator for SQL in this case, so it would flag up and first go through the validator for SQL injection, and then it would go through the validator for white spaces after that. So it would simply just not be passed over to the console.

Okay, so hello again. This is gonna be the second half of the talk, so in the first half, I just wanted to quickly do a summary of what we've done so far. And so blank, so it's gonna be from memory. But effectively, what we did is we did a little bit of a general introduction about open source and the security of open source in general and how it can basically cause some problems, especially when you consider that all of the facts we talked about regarding how things are not necessarily maintained to the highest standards where things have been abandoned and the way in which you could have problems with basically transitive dependencies and how you dependencies which are calling in, call in other dependencies, but you don't necessarily have a lot of visibility of it. And this can be like a very real threat.

So, and then what we did in the second part of the first half of the session. So what we did, first of all was go through and actually exploit a few of the bits of code that we've got inside of this application. One of them was an actual SQL injection, which was a vulnerability inside of the way it should design this application. But then the other two were based on open source as well. So what we're going to do now is we're going to go through and fix it and show you like how you can basically update things and fix them as well. But then what we're gonna do is talk a little bit about SNK in general, and how as a platform it can be used in order to help secure your applications and with your projects.

So just to start off with, what we're going to do is go back into my application. And I'll show you quickly what I've got is this engine here, which is run by SNK. So this is my SNK plugin. And by the way, I'd recommend everyone to just try this out and try it yourselves. The cool thing about it is that you don't need to have a paid license in order to do this. You just need to set up a free account and then you get 200 free tests a month. Which if you're just using it on a personal basis, you know it's plenty. Effectively, you can set it up and just run a quick test and it's going to go through and do a scan on not only my open source packages, and also my own application code here. So one vulnerability which I'm going to focus on is this one here. And this is a very vulnerable application. So there's a lot more in here, which we'll have a look at. But this is the way in which we actually hacked into the application and injected SQL by basically letting ourselves be an admin user. So what we did is we exploited the fact that this is being parsed and taken for granted as a string, as a direct object, rather than actually being validated to be a string. So what we can do inside of this, and does anyone have any guesses on like, you know, what we do in terms of the format for fixing this? That's okay. I'll quickly, people are slow to type, that's fine. It's hard. I've got a pre-typed one, so it makes it a little easier for me, is we're basically gonna go through and validate that this is in fact a string. So inside of this engine here, so when we call in this first function of this LoginHandler, we're gonna go through and create new variables, this username and password, and basically, we're gonna look at the login, which is a string, and basically, force it to become a string. So by providing this extra string on the end, this concatenation here, and providing it with an empty string inside of it, JavaScript will now know automatically that this is now a string. Well, this is basically of type string, and it forces it to be that object. So what that means is effectively, it's gonna go through and even if it was like an object which we passed in the form of that original vulnerability, you know, when I provided a password and said, this isn't an object, and then my SQL treated it as an object as such and then evaluate it as length. What we're gonna do is basically force that to become a, if I quickly save that. I'm going to force that to become a string. So now I SQL will have to evaluate it or JavaScript will have to evaluate it as if it's a string. Oh, sorry, I also forgot I need to change this. So now that I've created these new constants of userName, I can get rid of that and now I can also get rid of this. Now I can get rid of this as well. And by the way, I'm just gonna press Control S and it's gonna redo a scan. It only takes like 20 or 30 seconds because it's quite a simple app, but it's still like a relatively quick tool to work. And the cool thing which you may have noticed just before it disappeared was that it shows you examples of how you can fix things. So one of the examples which actually this fix is based on was basically providing new variables and performing like a two-string on them as well, which is effectively what this is achieving. So now that I've gone ahead and saved this, this vulnerability that was showing up has disappeared. So now the engine or the SAS tool, which I was using to find this has actually gone through and shown me actually that we can update and fix it based upon this kind of method. Now if I was to go ahead and close this down and rerun it, let's just get this out of the way. And I'm gonna quickly boot it up on the other screen, just a second. And... I think now it's booting. So just to show you that I restarted it, it's there. And now what I'll do is I'll try and log in again using my object password.

So let me go and grab that original command which I used at start. And I'll show you that effectively that has now been secured by doing this method. So here it is. Just make that a bit bigger. And shrink that down quite a bit, make a bit more readable. So it's very similar to the paths which we did at the start. Inside of this we're providing a curl post and we're creating this cookie jar again. And inside of that we're then going through and we're basically providing data binaries for this endpoint, this login point. So here we've got a username which is the one we're expecting. And this is like the original hack which I did right at the start which is we're providing this object inside of it. So we're saying because it's in this format it is basically being registered as an object originally. And now that we've validated it and added a string to the end of it and concatenated it that JavaScript will now evaluate it to be in type of string which means that it can no longer pass out and be interpreted by SQL as an object so it can no longer have a link greater than one and therefore not be true when we evaluate this link. So in this case, it's come back now and it's provided me with a 401 and it's saying this is obviously no longer reachable. It's being denied. So that's one way of evaluating it and that's one way in which you can fix it by using this SAS tool which is showing you where it is. Well, obviously there's other ways of kind of seeing information around it but effectively in terms of actually securing like the process which I've done so far by stopping myself from getting admin access like I've prevented quite a lot of vulnerabilities but also what you can do is you can get information around your open source vulnerabilities as well. So if I go ahead and have a look at that database which I showed up earlier and go back to npm and marked you can see that the version of marked which you need to do in order to fix something. So because we have, let me open up my package.json and let's go back to my files, just a second. Where is it? Yep. And then let's find where validator is. So yeah, we can find the version of validator that we're asking for. And we can also find the version of marked, which is here. And you also see that sneak is also showing me that I've got 11 different kinds of vulnerabilities associated with this package as well. So what I would do now that I've found this and I know that this is vulnerable, I can basically go in and call a fixed version of this. So I could go up to like version six now and then I'll quickly run that in a second. And then also the other one, which was for validator. I think the newest version is the one which has it fixed in it. So I'll quickly go and double check about. So it's version, it's this denial of service. This is the vulnerability that was found with rtrim. There's also another vulnerability, which I haven't gone through before, but it's a very similar process, but it is with isslug. So it's validating when we're providing a URL in order to validate, this is to do with the, when we go through and create a page, basically making sure that it's in the correct format and it's easily readable to the human eye. But effectively it was a very similar issue within the form of a redos. So it was just causing timeouts with that method of evaluating the string generated there. So what I can do is effectively, I can update and be explicit with a version that a data wants. And I can say, rather than how allow conversion to 13.5 and up, I could say, I just want 13.7 exactly, or I can say 13.7 and up. And there's an argument for having both hard types and dynamic types or dynamic versions allowed. That's what this little hat is by the way, obviously, it's saying the versions which I'm allowing and above. So if I had another version being called in there, which NPM deemed to be a valid version or they want support able to grab a different version there, then I see there's a question. Oh, sorry, just seen that was from you, Chris. Effectively, this could be a way in which I can basically start securing things. So what I can do, if I go through and I save this now, I need to go and exit out of my application again. Let's just terminate that and reboot it. And then I'll quickly navigate my directory of screen just a second. And then this is, there's my... So what I'm gonna need to do is rebuild nodes or my package.json, I'm gonna need to run like a NPM install before I actually start the service. And what this will do is it will update the installed packages based upon my changes here. And then all I can do is start the service again using these new versions. And I can actually show you that this is being fixed in this case. So if I go through and run that, I'll quickly run against it.

And I was exploiting validator, which is different from what we get in NPM. Yes. So let me quickly show you what that looks like. So this is a tall run by sneak test. And you can see by running, I literally just ran NPM install. I think I still have visibility a bit up here. And you can see that I get information around 76 vulnerabilities, two which low, 15 medium, 43 high. So 73 total. Just a quick glance, we won't go into too many differences here cause I don't want it to be like an exhausted differences between us and NPM audit. But effectively sneak has its own database, which it maintains of different vulnerabilities. And you'll find that it can be a lot more in depth to the kinds of vulnerabilities that we find. And the reason is for that is because sneak is very good at basically figuring out transit dependencies and things that you're pulling in. So you can see here that versus NPM audit which brings in fine 76 issues this fines for 105, so it can be a lot more detailed in regards. So yes, I'll carry on with that. What was it going to show you? I was going to show you that validator and marked are able to be fixed now.

So in order to exploit validator, what I was doing was I was passing information in via a redirect, sorry, to activate a Redos. So if I go back and I'll try and enter in my, I won't actually be able to do it now because I need to log in real quick as an admin. So give me one second. So because we fixed the issue where the SQL injection doesn't work, I need to enter in the correct password this time rather than entering it as an object. And now that I've done that, I can go through and I can enter in something into the archer which was in this case, entering into the account details, entering in basically an extremely long series of white spaces followed by an exclamation mark in that case. And you can see it instantly just ran. So there's no delay this time, got no delay or anything, it's like 21 milliseconds. So literally between those two versions, they basically updated their regex to be able to handle this situation. So no longer can you keep pulling against this and cause like an infinite cascade of backtracking and causing a service to go down and it's very quick now. And then the other kind of vulnerability was inside of mocked. So if I go back to mocked and we had an instance where we were able to go through and create an alert or execute some kind of cross site scripting by updating that version. Then basically we've stopped that from being found. So if we go through and provide the same information on this here, let me paste. So we'll equip this runback, what that looked like. You can see that we were entering into this JavaScript term and then we were entering it this term. It was finding that this was being referenced and then being able to say, actually this isn't valid as far as valid JavaScript. So it wasn't being able to enter into like a certain type of group. And then mocked was basically allowing that to pass off and assuming that it was safe to do so as a string. Our browser was basically picking it up and seeing this was there and like saying, ah, that's obviously wrong, JavaScript is there, I know what to do with that. And they'd pass them off as a executable script. But because they updated marked now inside of this version, now that's actually been passed through as something that can't make its way through the validator because they made a change inside of that version. So that's ways in which you can basically fix these exploits. One of which was coming in from our own engine. So it was coming in from my own app, sorry. And I basically updated that inside of here. And then the other two components were being brought in via open source packages. And obviously those have been updated now, so, that's great. The question is, is obviously like, in this case, I knew exactly what versions to go to because I knew what kind of vulnerabilities I had inside of it. But the reality is is that you guys aren't gonna be able to keep track of all the different dependencies and all the different kinds of vulnerabilities you've got with your dependencies. And this was in the case, in my case here, for the sake of example and updating things, these were all indirect dependencies as well. These are where the vulnerability is found. Rather than any transitive dependencies which were necessarily brought in. So the question is, is like, how do you actually secure and prevent yourself from getting vulnerable to those things? And the answer is with using a tool like Sneak, where we can basically go through and find indirect dependencies. So I showed it off there in terms of the way that the Sneak test works. What you can also do inside of this is you can run a monitor command. So test command, which I just did, will come through and I think I should probably close this cause it's going to eat up unnecessary CPU but carry on nonetheless, it will go through and it will show me all my different kinds of vulnerabilities and how I can fix things. If I run a monitor command, this is the exact same response in terms of the core content, which I just received but it's going to push it up to the sneak GUI or to our website. And when you see this, it's actually like a very easy to work with UI, let's show you what that looks like. So if I go ahead and go to this, this is a saved instance of that scan which I just did and you can see it was already scanned a few seconds ago and it's showing me what might the results of my scan were like, but in terms of this UI. So what I can do with this UI is actually see in a graphical way where my transitive dependencies is coming from. And this is like a really valuable point of view from understanding like where your risks lie and understanding what things are coming in. So I can see in this case, all of the transitive dependencies which I've got coming in and which ones don't have vulnerabilities in them. And then what we do is basically we go one step further in terms of actually telling you what you can do about it. So what a lot of tools out there will do is they'll basically tell you like, you have a transitive dependency such as Negotiator in this case which has a vulnerability. And this vulnerability, which it has, it may have a fixed version. So it could go to version like seven or something then fix Negotiator in it. But the problem is then, is that you're not actually calling in Negotiator yourselves, you're calling in something like Excepts. And sorry, you're calling an Express, which is calling an Accepts, which is calling Negotiator. So the hard part in what Sleek helps with in this case is basically we'll tell you the version of Express to go to, which calls in the higher version of Accepts, which calls in the exact fixed version of Negotiator and actually validates that for you. So if we go have a look about inside of here, we'll go through and we'll actually show you in this case Express was the original version of Express that I was calling and was calling in this version of Negotiator.

The fixed version of Negotiator is 0.61. And then the exact version of Express calls in this fixed version is 4.14. And that's basically enter in how I could affect and basically reduce the vulnerabilities inside of my application. The other thing that we do, which is really cool is basically provide you with context for when things are exploitable. So what this means is basically like what I've shown today in terms of like an end-to-end exploit. We can basically, and then if you have a look inside of the README for this application, we go through and we exploit each of these vulnerabilities if I go through them like that. And we can actually show you how you can fix them as well. So AMD zip, for example, which has a directory traversal or a path traversal which we've gone through today. This is one, and it's a very infamous zip slip it's also known as, but you can have a look in our website and we have a very robust informatics about like how this works and also how this can be exploited. And the cool thing I like about this is that it also gives you direct links to where you can find like where the conversations around this have happened. So you can talk about it or you can share it amongst your peers in order to get more information around how zip slip actually works. And this is actually something powered by Snyk. So this will walk you through what zip slip is and how it can be exploited, but if we go back to this, you can actually see that we've got this priority score and this basically pushes information to you guys based upon not only a CVSS which is like a very standard thing. So, that's like how normal tools basically rate between like critical, high, medium and low. And we are an accredited CVSS scoring system or scoring organisation. So, when our security experts basically find a vulnerability we can give it its own score based upon what we rate it as. But what we do before we enter that into our database, we see whether or not a vulnerability has an actual exploit in it. And this means basically mature vulnerability or a mature exploit. Basically we've got documented evidence that an attacker has used it maliciously on this particular package. So, we know that this is actually really vulnerable. And then a proof of concept is basically when there's a white paper associated with while somebody might not be exploited with this in like a live environment, we have like a white paper showing like an end to end how it can be exploited. So, with these two metrics you get like an ideal like measure of risk associated with it. You get a measure of severity with a CVSS, and then you also get like a measure of how easy it's to fix something based upon whether something has a fix then. That's probably the easiest way of using Snyk at the moment, especially if you don't have a proper account or like a paid membership, effectively any project which you're working on, you can just go run to your directory, install Snyk. And this is where you have to have NPM installed or you can install it by binaries and just run this NPM I-G Snyk. Or what you can do is install it as a extension in Visual Studio. So I can go over to my extensions and literally just type in Snyk and it will be the first hit as you find it and then you can just install it. And then you can scan things in your working environment and scan things like that.

Has anyone got any questions with regards to using Snyk at all? Do you have any engineers actively looking for it on their Edge Once? Yes, we do. So two things, Stuart. We have engineers which are using our SAS engine. So this engine which goes through and actually sorry, that's the wrong id. Which goes through and scans like source code itself. And we scan thousands of projects time including open source projects and private projects but also projects which you might not realize like could be vulnerable like on the app store, for example. And we release updates around kind of... We update our database on like a daily basis and we also, you know, update the maintainers of those projects in order to let them know about it. And yes, I might have Jack, kind of leaked IntelliJ back send. Yes, we do have IntelliJ and the rest of JetBrain support as well. One thing we also do, which if I quickly go back to my slides, is we release blogs as well. So let's have a quick look at that. Give me a second now. And basically these are blogs by our security engineers as they find things, they will do blogs and you can subscribe to this as like an email newsletter. But I'm going to have a quick look at the application side of things, application security. And these will basically be like new hot topics as things are emerging. It's a very, if you stay on top of this and sign up for it, it's a very easy and like digestible way of staying on top of kind of what's newest in the industry in terms of new security threats as we're finding them. You know, we've got things, articles on like ransomware and things like that, where for example, new kind of vulnerabilities are being encountered because of the war in Ukraine where people are purposely making their, it's called protest where, sorry that's the term where basically people are making their applications purposely malicious for people that installed them and they're inside of a Russia geolocation. So they're going in and they're updating their own packages and saying, if you're inside of Russia, delete all the files on your computer and things like that. And basically we're keeping on top of kind of everything that's happening from like a political landscape as well as new vulnerabilities being found. If express hasn't had a version of the fixed transit dependency do you recommend using the modular resolution? No. So we explicitly stay away from modular resolution.

We, for NPM exclusively, what we do is we offer patches where we will go in and basically provide quick fixes for that particular vulnerability. So what it will do is, it won't go through and say, let's say for example, if it's a transitive issue, we would provide a patch inside of the transitive issue. So let me go back to a visual aid. The patch would lie, it was here, the patch would lie inside of mine in that case, if there was a vulnerability inside of it and there was a transitive dependency, which had an issue, it wouldn't be a case of using modules in order to tie the version of Express, it would be an update to the version of mine you are using directly in order to basically have the fix involved in it, we released quite a few patches, but ultimately it's not really like, it's kind of a stopgap because obviously you lose a lot of the core functionality when you freeze to a point in time like a patch version of mine and you don't go to the later versions. So what we'll do is we can patch it for you and then okay, so you have a patch module, effectively yes. Let me show you what patches actually look like. So we can go ahead and open this up. I don't know if I have an actual example where things are patched. Partially fixable, is this fixable via a patch or is this patchable? We don't have a patch for this one. I don't think I have an example for you. What I'll do is I'll reach out on the Discord thread for this. Send you an example. I'll send you, yeah, I've got a patch in this particular example. I'll send you through our documentation on how our patching system works, if that would be helpful. But yeah. Is there any other questions with regards to practically how it works? Otherwise I can talk a little bit about securing the environment as far as the whole holistic process works.

Okay. I'll carry on with a little bit about the whole environment in terms of what we've seen so far from like a picture, wider picture view. So what we talked about so far is just working with things on the local level and scanning things in terms of scanning them in the IDE and scanning things in my terminal here. But what you can actually do is integrate Snyk into your Git repository. So if you're using things like GitHub, what you can do is you can integrate into it. And once you've done that, what it will do is it will actually monitor branches inside of that. And if I go here, I can show you. I can basically monitor different branches. In this case, it's a feature branch, but I can have a branch of like a developer branch, for example. And then what I can do inside of those is whenever I make a pull request inside of this. So let's say try and change something, like at the start of the day, I finish writing some code and then I go to upload it via Git push. And basically what will happen is making that change, we'll do a scan based upon the differences between at the start of the day when I checked the code out and at the end of the day, when I'm checking the code in, it will basically do a delta and find out what the differences are technically from a security perspective between version A and version B. And it allows you to basically very quickly look back over your day and understand what it is that you've introduced from a security perspective so you can go ahead and fix things. And we can show you exact examples of how you can fix this, in this case, going to a two string method rather than just providing it as a standard variable. So that's one way in which you can start basically using Sneak as far as like in an integrated way.

And then the other thing what you can do is integrate it into your pipelines as well. So inside of things like GitHub pipelines or get back to the story inside of Jenkins, TeamCity, anything that you really use for pipelines, you can basically install the Sneak CLI tool so this tool here, which has, which I've just installed inside of it and running Sneak test and Sneak monitor commands, you can basically break builds based upon the definition of what we find inside of them.

So what you could do is you could say I want to break a build based upon something which has a high severity vulnerability inside of it. So what that practically ends up looking like and we can even do it based on a critical vulnerability is it works out meaning that any changes that you push up to your platform don't have any kind of critical severity inside of them. So you want to make sure that you're not entering things into your system which have critical issues inside of them. And you can be very granular with how this works. So what you can do is you can actually enter in filters, I'll quickly get up a filter in the meantime just to show you what that looks like.

Just a second. I think that's it. Yeah, this is my filter. I'm just going to do a sneak test. And what I do then is I pass it out into a JSON and then I'm entering it into another tool which is hosting GitHub. It's an open source tool which we maintain called a sneak filter. And what this is doing is it's passing out the JSON format with JQ filter and then pushing that into a filter which I've defined inside of this directory. So what I can do is I can assign this file either as a global variable accessible via my pipeline or I can assign this and save this file inside of my projects themselves. So I can specify different filters based on them. What this filter is achieving in my case is it's doing the same filter which I was showing on our GUI where I was going through and I was filtering things based upon what was fixable and whether things have a mature exploit or a proof of concept and whether things are critical and high severity issues. So rather than breaking a build based upon 105 different issues which stops you from actually working and makes you have to go back and fix things for like the rest of the day, effectively what you'd only break the build on is things which you can a, fix in a very quick and easy manner and b, things which are exploitable which have a severe level of risk associated with them and also have a high level of severity as well. So now that it's done that, effectively you can see that these are the vulnerabilities which it would break a build upon and you can basically then after that run a monitor command and find out how you can actually fix these things. It shows you where in the path these dependencies need to go, these dependencies out of date, I have history dependency, okay? Basically telling me how I can fix this as I go with that. And this is something which you can put inside of your pipelines, and then ultimately, this is how you can secure the entirety of the software development lifecycle. The idea is that rather than using it just as a security gate and basically slowing yourself down at the point of delivering things, what you should end up doing is basically using a tool like this at the very start of basically building something. Let's say, for example, I want to see if I can install the newest version of Express, right? So what I can do is, I can do a sleek test command, and maybe not Express, but any kind of open source library which I'm going to be using, which I started from scratch with a new project. Let's say I'm not familiar with it, and I think I need to achieve this inside of my project, I'm gonna Google the best kind of library which can help me achieve that. And what I'll do is I'll actually go ahead and do a test of those. So let's say, for example, I test colors. What will then happen is I can do a sneak test, and it will find the latest version of colors inside of that. And it will come back, and it will show me, let's see, Project Path Colors. I don't actually, wait, no. We reopen that. Close that. I don't think it found the version of colors in the Tracker. Okay, yeah. So it's registered it as a packaged item. No. Might need to specify the exact version. Let me go find a version of colors real quick. Let's go to version. Let's go to version from last, so let's do version 1.4. Let's do a sneak around. So type it in, sorry about this. Let's try this. Cool, it's not seeming to find that particular package. Effectively, what you should be able to do is before you even start using an open-source package, you should be able to test it, and then from there basically get an idea of what it looks like in terms of like from an open source perspective, if you want to use it or not. The engine isn't running it, but what you can do is use our database. So let's run over to the database and go here. And then I'll search for colors real quick. So, I mean, it helps if you specify versions with it, but this is an example of a denial of service attack which occurred in anything less than 1.4.0. So you would know kind of the versions of colors which you should start using instead. And then the other resource which I wanted to point out to you is a Sneak Advisor.

So this is a completely, by the way, the database in terms of accessing this, it's completely free to do so. And so is the Advisor. So if we go ahead and look at this and I type for colors in this case, look for npm, and then what you can see is colors here, we actually have the ability to score this as well. So you can see like ahead of time what kind of packages you're committing to, and you can see alternative versions of packages which you might want to use instead. So the idea behind this is that it gives you an idea of the kind of libraries which you're committing to before you actually start doing so. Because if I'm gonna start building any kind of application which builds on top of this resource, then I'm gonna start using methods and using arguments which it relies upon. And if I was to then find out in a couple of months time that there was a vulnerability in it, and these guys aren't very hot at releasing frequency like maintenance and releasing new updates, then it's gonna be a problem because effectively, there's no guarantee that these people are actually still active, they could be potentially not actually updating vulnerabilities and fixing things if there's bugs. So what you could end up doing is having to rip this out and replacing it with a similar package to achieve the same functionality. So even though this is something that might be familiar to you, like using colors in this case, what you might end up having to do is rip this out, so you might as well do that anyway to go for a package which is more sustainable and has a better overall coverage. So one which I'd recommend instead is using Chalk. This is something which came up actually quite recently. So if you go to Chalk, which has a very good health score, it achieves basically the same thing in terms of the core functionality behind it, but it has a lot more recent commitments and it also has a wider community and it's also funded. So there is actual sustainable practice in mind for using this because it has so many contributors. These contributors are compensated for their time in keeping this up to date. So that's why it's basically recommended as like a very healthy package to use as well. The other thing you can do is you can basically check which ones of these are. Let's go ahead and look for a package JSON, which ones of these are recommended as unhealthy or not healthy.

Is there any questions, by the way? I see I've missed the chat for a little bit. Let me have a quick look at the, why isn't this loading? I'll just wait a second for that to load in. And check out the chat for fixes.

Are the CLI tools linked to the dashboard? Yes, they are. Yep, absolutely. So if you ignore something, it's agnostic, and we can go through that in a bit more detail in a second. But yep, you can test things and it will be consistent.

Sneak Advisor is super cool, especially it might be useful to use when you use cases in the library, yep. Does sneak have similar packages? Better health score. Yes, it does. This is what I wanted to show you in terms of how the Advisor works. So this is actually inside of IntelliJ, and this is something which is just inside of IntelliJ at the moment. We're planning to release this across the rest of the IDs, but it's currently just a beta feature at the moment.

Yes, we do. Mostly focused on JavaScript because of the event that we're doing today, but effectively we have very good support for things like Java, Python, Go, C-Sharp. What other big languages are there, like Ruby, I guess? Effectively, quite a lot of languages. We have a list longer of the support that we have than the list of the languages that we don't support. So if you have any specific questions, Stuart, then throw them over, and then we can address how good the support is for those. But yeah, we have a lot of languages supported.

But inside of here, you can see, for example, that it will give me advice based upon this kind of sneak advisor score, and then this has opened it up on the side here, and then this will show me, basically, like how well this compares to other things. This community and this maintenance is completely unmanaged, so it may be a good idea to potentially use alternative kinds of packages instead, and it should give me examples of different kinds of packages, which I could use. I'm not sure why this isn't showing them but effectively, like, you would know from this that you would have to go through and change a version of Code Roku.

Like, the reality is that there's no such thing as a, yeah, you can have patches for sure, especially if it's an abandoned project. That's when we typically step in with patching things. But in the reality, most things aren't gonna have patches because of the scale of which open sources like being adopted and the ways in which these packages do get made abandoned at a pretty exhaustive rate as we've seen. So the reality is that there's no such thing as a completely secure application. And what that works like in terms of how you deal with that is effectively you have to have, like, some kind of triage process in place and there's no one shoe fits all and it should be something which you guys continually address and continually check yourselves.

But for example, if I was to find, let's say something which isn't fixable and I go into it and look at something like this prototype pollution here, so the other thing worth mentioning is that we have an online course in terms of what you can start learning yourself today about specific vulnerabilities. So we have this tool called sneak learn and it's linked up to our platform and so if we find a vulnerability which we have a lesson on, then you can directly open it up and get a lesson. It's a virtual environment where you can test things out and try to break things and understand kind of how this actually gets exploited and it will show you the definition of it under the hood.

But there are also examples where the reality is is that there will not necessarily ever be a fix for this. And the reason is for that is because these packages could maybe be potentially not maintained or just simply, it's like a very new vulnerability which people haven't had the chance to address yet. And the reality is you will have to go through and assess it yourselves and make your own opinion about it. So what you could do is we have a lot of information around these kinds of vulnerabilities in our information bio. So it will go through and tell you the type of vulnerability associated with it, how you can exploit it yourself and how you could do a proof of concept in your own environment. So the reality is you should probably just run like a mini penetration test to see if you can exploit it yourself to understand like how vulnerable it is for you. It may be that in this particular instance, so you can see the method which has been called a set value. The package that creates nested values and interprets any intermediates using dot protection. Okay, cool. So the way this is working is when the user provided keys keys used in the path parameter arrays. Okay, cool. So what you could do is effectively you could go through and ensure that the object itself isn't susceptible to pollution. And what I mean by this is effectively, this is something specific to prototype pollution as an example. But the way prototype pollution works is effectively it's populating an object which I'm able to enter in and change the definition of what its prototype is. So it's only really exploited via certain set of methods. And these methods are considered like add unsafe methods to do. And they're typically around recursive measures. So like this in this case, it is a recursive measure which this, which the set value is basically executing the logic in which it's the core application itself and why it's vulnerable and why there isn't a fix is just that it's using in a very unsafe method to merge things in a recursive manner. That's just simply the nature of it and it's vulnerable to, and it's just simply vulnerable to prototype pollution because of the ways in which recursive measure actually works inside of JavaScript.

The reason is for this if you can go through and look at either this content or look at it in terms of the sneak learn lesson, if you want to learn up a little bit more about it and how this can actually be exploited. But at the end of the day, this is something which you have direct control over because you are at the end of the day writing these applications. You may be using the methods which is calling but what you can do is you can go through and when you're referencing them is you can basically control the parameters in which they can be exploited. So what you can do is effectively go into it and we'll show you the different ways in which these type of attacks can occur.

So remote execution and denial of service injection. So denial of service, you can do something like, just overwrite the two string method or value which are extremely popular functions of an object and by overwriting these things you're almost certainly going to break an application by basically removing an object's properties because anytime you call an object and then try to make it into a string or make it into a value, it's just gonna fall flat on its face and you're just gonna break the application. It's not gonna work as intended. You could do remote code execution by basically defining a object's prototype. The way in which the subject is made up by basically inject something which you want to inject into it. So you can enter in this whole other class of operations inside of it. And when the objects instantiated, it then instantiates its own code as well. And there's other kinds of things which you do with it in terms of like property. This is just, you know, assigning variables to assign it permissions, which are then later used. I mean, this is a really, really relevant in the situation where you know how these variables are being executed. If this is never called, then it's not really a problem and you haven't got the name convention correct. So you could inject an ISAdmin, but if you're not evaluating against ISAdmin to get permissions, it doesn't really matter. But what the way in which you can handle this is by basically freezing the object. So when you're creating and recursively merging an object. So the function ultimately what you're using this for, this set value, when you're starting to do this, you basically freeze the object at that time and you specifically freeze this object prototype. And in doing so, this recursive merger, this whole problem which I've been talking about, that is no longer relevant because it's just simply not allowing for any kind of change even though the function still works. So you have to go through and triage things one by one, unfortunately there is a one size fits all for all kinds of vulnerabilities, but what you can do is basically add the context of the triaging you've done and just add it to the raw contents. So in this case, I could say not vulnerable because when I'm using set value and I could name the ways in which I'm calling it so I could be calling set value, something like that and name the object and the parameters being passed into it. And then going in using like an object.3 as well. With that I can be confident that I'm not actually exposed to any kind of prototype pollution. But adding this context of the three steps which you're doing in order to triage something and say whether it's vulnerable or not is effectively the process. It's not like a case of you can't fix everything but it is the steps taken to fix things and to ensure that things aren't vulnerable. So if you save this it will show up inside of your reports and I'll go quickly and save it now and it will show up. It won't show up in break builds or anything like that because I've processed it but it will show up and let's just wait until this is loaded and let's just have a look at ignored. Yeah, so it will show up and show me the different ways in which this has been basically, I've ignored a couple of them in prototype because it's not something which is, which I'm going through and actually changing for things like that but effectively you can add the context of why you're freezing things or why you're saying that it's not vulnerable and in doing so it's not gonna show up that's basically like a very long winded answer of saying, what will happen if things aren't fixable? The answer is, you just have to kind of grip your teeth understand like the context of what is actually being shown to me as vulnerable and then evaluating it to see if it's a threat in your case or not. It may be a threat, it may be there's nothing you can do about it from a user perspective and the reality is you should just be moving to a more secure better maintained open-source package which can be addressing that. But yeah, the answer is not really that simple, unfortunately, but this is the process which you would need in order to undertake it and this is how you can do it with these tools. Did that make sense? I might have gone a bit too deep there, the specific issue. Yeah, thank you. Cool. Has anyone else got any other specific questions? Yeah, thanks. Yeah, Peter, in terms of the example of colors to chalk. Yeah, that was the example which I was thinking of as well back when Node was actually vulnerable, just version of Node itself was vulnerable to denial of service. I ended up getting stung by that for a whole weekend, wasn't fun, but if I go back to Pfizer, I'll have a quick look for colors, I think it was other colors or colors.js. Wait for this to show up, and then you can see different kinds of packages that you can look to instead. So in this case it's got a colors.js, I could go to chalk in this case, and then potentially use that as method to find what kind of packages do very similar things but are a lot more secure. So like that's a quick back-and-forth. Okay, cool. I think that's all we have time for. I want to quickly also mention some of the other thing, resources which I've got inside of here. So I've gone over the Snyk database, Snyk Learns, Snyk Advisor. The other thing worth looking at is we have this cheat sheet which is specifically going into NPM that you can take a look through and kind of understand like some ways in which you can start working with things from best practice.