So let's talk about a little bit about security today.

All introduce myself first.

My name is Iran Kalama, Developer Advocates at sneak come from Israel.

Ah, sleep.

We will developer tooling really for security, dealing to help developers and empower them to actually fix secretive vulnerabilities that they have in the open source projects.

I am also actively involved in a no GS security working rope to help improve the state off security off no G s and the N P.

M eco system as well, and to a lot of other projects like no goat and some books I wrote about security.

If you're interested in any of those and getting involved will be happy to help for just being you Twitter.

And we can, uh, take it offline.

So open source is awesome, right?

We're all using.

Virtually everyone is using open source in one way or the other.

It is a great way for us to go ahead and just focus on the business logic of things that we need to build.

And we use what we need, what we can from the eco system.

We can also go ahead and contribute back some of us even contribute and create and maintain project, which is amazing.

And they probably don't need to convince you that you probably already know that.

And to as a testament of that, we have seen a lot of wrote in all the NPR all the package eco systems off different languages, even Java, as it seems.

I don't know, unfortunately or not, but generally we've seen this growth going off True.

All of them, actually in just 2018 Yes, last year.

And PML is added 250 K packages to the repositories earlier this year.

In June, we already crossed one million packages on NPM.

We probably don't need to tell you that, because all of your pulling half the universe when you're done doing an NPM install.

So really, the question is, how much do we know about the N.

P m dependencies that we're pulling into the project?

Try to do a mental exercise just now yourselves, try to imagine your package.

I sent your package manifest.

How many packages do you know?

Do you recognize there was direct dependencies?

And how many of transitive dependencies do you also pull in?

So there's a lot of dependencies out of unknown that we are using in our projects and, you know, possibly involving sound risks.

An interesting article or a research paper that was actually published earlier this year that I had a chance to read and write about is something that actually compared the Python, aka system with the MP Amica system.

And it found that 61% of all NPM packages could be considered abandoned.

Now abandoned is a very open to interpretation.

You know, different people have different opinions on it for the sake of the research.

What they did is considered any package that didn't have a release in the last 12 months.

Eyes abandoned, which is arguable because you could just say that, you know, the package is well known.

It's mature, it's reached its and states and go, except in 28 in Some of us may remember the event stream incident probably the most sophisticated attack that we've seen on NPM happening happened to a package called Event Stream, which has been there for almost a decade like eight years, did not have any release for the last two or three years, depending how you count it but someone was actually able to socially engineered their way into getting into gaining.

NPM published permissions to publish a module, injected a malicious package in the dependency tree of events dream itself.

And in this way we're able to steal money from Cryptocurrency Willits.

But it's actually happened, or the whole post more than a chain of events for interested in falling that as well.

But also what?

That research paper.

Actually, you know, highlighted is an important note about the dependency tree that we are always pulling in.

So it actually found out on average, will be pulling in four mpm packages Nesta deep in every time we'll go on ahead and install and an m.

P m package.

So this actually is, you know, very interesting in terms off.

How many packages are we pulling in?

And what do we know about those packages and all of those Nestor dependencies in the tree watching Pretty vulnerable it is, they may have so as an example, and security vulnerabilities happen all the time, we just usually less hear about them as we're less conscience on this.

But there we go with you on your own is popular and being package manager, Um, it was it was found to be vulnerable to a man in the middle attack.

So, for example, if you were here on the workshop or in a coffee shop you are using, you were doing a young install, someone could actually eavesdrop their connection and get the N.

P.

M.

Talking is that you were sending off to two NPM itself because that was sent off on an insecure medium.

So not in the next GPS.

So that's that's one.

And they could probably do a safe, a safe estimation.

And guess that no one is using this latest version of yarn that was just released a few months ago.

Another example is more down mark down for J six.

This package is actually pretty popular.

It's used for our storybook you in several Gatsby teams.

Uh, obviously in several view Js and religious components as well, and it is also vulnerable to some exercise vulnerabilities which war again only recently fixed sequel eyes and even more the most opted eight example of an SQL injection a nest you'll obstruction library that is usually popularly used on O.

J s project actually was found to be vulnerable to several SQL injections and was just fixed last month.

So if you know that one of your teams is using that, you should probably Scott and make sure that you're fixing it and upgrading very quickly now this means that a lot of open, open source is amazing and it's written by humans but a CZ.

We come to think about all of this risk.

We come to also understand and realize that we do not know who wrote them and you know what is their proficiency?

What is going on with those packages?

For example, we actually conducted a state of open source security in February 2019.

We found a lot of interesting facts.

For example, this one where maintainers would feel less confident in fixing security issues once they are disclosed, because they do not think that they have a strong enough security knowledge to actually fix that and do something about it similar to that's.

For example, maintainers, usually or 26% of the time, will not audit to their packages.

They will not have any some kind of security testing, not static application, and then I make applications of urine testing not even a security code review.

So imagine your projects.

Although dependent says count one out of four that did not go any kind of security test Now that police pretty easy to doing on a direct dependency.

But just think about how all of those indirect dependencies that you're pulling in a swell so as we come to talk about, you know, the code that we have and how much we rely on open source, it's ah, it's a simple Are people based on you J s and the wife framework called Bull must We didn't have a lot of dependencies, but you can already see that.

What code is generated from my app and from the bundle of all the vendors that, you know I'm actually dependent upon, You know, it's only presents 0.2% my code to the hole up.

I think this is the most thing that you know, stroke lightning in terms off, being able to understand and realize how much we're using open source.

Because this is a common misconception for me as a developer were I'm building code pushing into production, and you know, this is my up, except my up is actually, you know it is that, but my code What I write, you know, in my own responsibility, actually, a very small piss off that whole thing when I'm pushing this whole thing and pushing a lot of code into production out of risk that you know, other people would usually catch, such as Dev Ops and security Engineers, and figure out that there's a lot of risk that I'm actually pushing in.

So at this point, I'm I guess some of us are wondering, you know, we're talking about security vulnerabilities in open source libraries, And how much are we dependent upon?

So how do we jump from a security vulnerability in a package in a dependency that we're using to a security vulnerability, our application that actually puts it into risk.

So let's go ahead and go to the hands on part of this of this presentation.

It's over here.

I have a simple ah, goof to the application.

You can do things like, um, I'm pretty nervous here, and it's basically to do up that I can just add some stuff into it.

As a security conscious developer, you might started already to think about how you could go ahead and attack this one.

So he has an extra one injection input.

Maybe I could do something around it.

Maybe I could do in excess several things, Right?

So maybe I would go ahead and add something like that.

Maybe it works.

Maybe it doesn't work.

I don't think that we should know about this is a bill this using marked so marked Go ahead and increase that you can see Mark is a fairly Popolare Azul package for doing more down.

One example of understanding security and being aware of this is this is a bad example of it.

In terms off, you need to opt into security, right to sanitize the data that's coming in when you use it.

So it's not turned on by default.

You actually need to know to do that.

So, as a developer, if you're reading days, you have to, like, understand the FBI's, read any security disclosure and then turn it on.

So we have marked her and I have marked down support so I can go ahead and do stuff and actually scanned is up with ah snake.

And I can see that, you know, I have I am vulnerable to cross site scripting, right and part of, like, 448 libraries that I have re so again, like, what could I do next to go ahead and cause maybe an ex assess as of sin?

How about if we try a different vector?

We know that there is marked down so I can do like this and get something bold.

But then I also have this victor of attack, or I can add Link.

So imagine someone adding a JavaScript link interests.

So maybe something like this, right?

And then we have links.

So now you can go ahead and take this one step further.

And perhaps I want to change this with something else.

It's a good way to start, except it doesn't work because Mark down is actually sanitizing it as we actually provided it.

So it's doing something with the data.

Just, you know, we're not yet there.

One thing that is common is to go ahead and represent data in a different way so we can go ahead and say colon on a webpage could represent that by the HTML entity for that so we could go ahead and do something like this represent this as well and do it and the way that I noticed.

I do not need to reverse engineer something that is very difficult because mark down his open source.

I can just go to the reported Torrey figure out what sanitize true does and just reverse in the nude out.

So it's pretty easy to figure this out so I can do this.

I can already see that something different is happening.

So perhaps some on the right path and at this point again, I can go into mark down source code and figure out why did this get sanitized in a different way?

The truth is, the Senate ization process in marked worked its way that it actually reject, says disco part of the string.

So it actually looks for this kind of code and strips this out.

So while I'm trying to be outsmarting it, it is actually someone as a developer there, that road it was able to actually think about this victor as well.

What they hadn't took into account is something that that happens in the browser and that is rather are usually very nice in terms of if they help us, too, if we write like, bad code.

But, you know, broken lives or forgotten dealer stuff like that, they would go ahead and complete that.

So if it would just write something like this like literally this.

I know it's hard Angeles will bear with me.

But if I hurt, if I put a volley JavaScript statement like this as a key word, it will go ahead and pastor sensitization process by marked because marked does not look for this.

It looks for a specific string as someone trying to talk this out.

So when I do this, I get this link actually working.

And what the router does is it says, Well, I think you meant to end that 58 character with a semicolon so that you do that for you.

It adds it.

And because this is a volley JavaScript statement, the whole thing gets really did as valid as well.

And we have an excess in our application.

So one example of dust off that is this we can go ahead and figure out some other examples.

For example, I have this about page which is based on.

So this is I'm not doing anything dynamically.

I'm actually using a template engine for know Js called dust Js developed by Lincoln for ah, framework old cracker.

And it's actually pretty secure project cetera, but we'd have all the reference here.

Anyway, What I have is in about page on this out and you can see how I'm, like, really great at CSS because they have the skill.

Do make it big.

Make it all right.

So let's go back to this.

So it is a mobile first application.

You can see it actually response reactively to what I do.

And at this point again, I'm trying to figure out what can I do with dust as a template ing engine on this application, so give you a bit more context into what's going on?

No, this is a template for it, right?

About you.

It has the dust extension.

I have this condition where if something is a device equals desktop or mobile, it's gonna want to one of those branching statements in my conditions and draw Brody, draw the HMO for this.

So pretty straightforward.

But the question is what we can do with this.

If we were to figure out what is what is that's vulnerable for?

You know, if you would scan you're up, you could cut it with whatever you want.

Sneaker and PM audit or always dependency check doesn't really matter.

But you would find something like this like Dust is vulnerable to a code injection.

What is it mean, a court inj