Name: StrangerDanger。セキュリティの脆弱性を見つかる前に見つけよう！ by リラン・タル｜JSConf BP 2019 (StrangerDanger: Finding Security Vulnerabilities Before They Find You! by Liran Tal | JSConf BP 2019)
Uploaded: 2021-01-14T10:27:16.000Z
Duration: 23 min 46 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

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

再帰代名詞

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

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.

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.

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.

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.

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

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.

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

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.

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 also understand and realize that we do not know who wrote them and you know what is their proficiency?

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

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.

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.

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.

Maybe I could do in excess several things, Right?

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

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, 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?

StrangerDanger。セキュリティの脆弱性を見つかる前に見つけよう！ by リラン・タル｜JSConf BP 2019 (StrangerDanger: Finding Security Vulnerabilities Before They Find You! by Liran Tal | JSConf BP 2019)

字幕リスト動画再生

StrangerDanger。セキュリティの脆弱性を見つかる前に見つけよう！ by リラン・タル｜JSConf BP 2019 (StrangerDanger: Finding Security Vulnerabilities Before They Find You! by Liran Tal | JSConf BP 2019)

stuff

vulnerable

conscious

process