B1 中級 5 タグ追加 保存
thankful, Right?
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.
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 injunction?
How does that really happen?
How does that impact from a library to my own application?
So the thing is, there's a user input.
You're so we can go ahead and start and doing something with it.
And, for example, I can go ahead.
And so it's maybe a quote, because maybe I'm trying to escape this whole quote condition and do something with this part of the code.
Maybe I would do something like this, except that seems to be okay.
It's probably behind the scenes and coating it doing it properly, et cetera, and we can actually see that dust has Theis escape ht m o part of the coats.
It's actually taking a string, trying to see if there's anything malicious that should be encoded.
You know, something dangerous that should go trying to encoding, and it's gonna go on encoded so it's gonna replace it with the external entity for it.
And this way, try and you know, not used the original quote or whatever Parmenter I was trying to do.
Thio circumvent the up.
This is great, except it is actually only going into this safe condition when I'm giving it a string at this point is it's so interesting to figure out howto I hacked through that and not give it a string because I need to put something else, but to bypass the sport, which is not a string.
So one example to one way to do that is to think about array parameters for the way that you could go ahead and you are request poisoning like this with an http parameter pollution.
And you would say desktop is now actually an array.
This is very common where you have, like end user, I d equals something and you're already equal something, and you want a pattern, a rage where request parameter, Or you can also use the bracket notation to go ahead and convey the same the same intense as you can see.
When I'm doing that, this continues to work just fine because when the evaluation happens over here.
Over here.
I'm just going, going ahead and doing a string for Honore.
That's gonna give me the first item under.
So it seems that the op is actually working well, but what's interesting is if I go ahead and try to put 1/4 something fails and you can already see what's going on.
So to understand, a little better What?
What is actually going on behind the hood with the security issue is this condition is actually something that gets evaluated to run time.
Because this is generally how the templates, engines work and dust has thes help or were for if it's gonna go, take that condition and evaluate it.
So knowing this, I can go ahead and figure out Well, if that condition works, maybe I can provide a specific string to do something.
Let's try to on a commander.
So we're at a request from this, Eli, so we can do this together and I'm gonna go and see that everything is okay.
I will add a quote to see that everything is okay again.
I'm gonna go and add this to do the whole thing and reproduce the whole body you know, now I have a working example I can actually work with.
And this is where the fun begins, right?
Because we know it's an evaluation statements.
So it is a simple for me.
I was doing something like Sorry, node, and then evaluating desktop equals that stuff, for example.
It's gonna be true.
But now that I know that they have a way to inject data there that is not being treated in any others safe way, I can go ahead and do something like this, which is trying to evaluate an expression for a place that expects a value.
So as I do this I don't really care about That's false or true.
I care about the fact that was actually able to invoke a function truly civil statement.
So going back to a request, I can do something similar, and I will make this a bigger so you could see I was able to go ahead and put under service side a function expression, right, a function invocation, and actually did the consul log so remote area code injection.
Now it isn't just for the example, right?
Just for us to be very fast in this example in the demo.
But imagine what I could do here.
Just require process child's process.
Invoke something that I want to get from your application or anything else.
All of this is done true dust.
If this Paige was not even authorized, you know anonymously means everyone are able to do this, so it's kind of a remote code injection.
So we're talking about all of these examples with open source libraries and how much you know how much they affect us.
And what's the reason that we have in them?
And the thing is, for Attackers, that's a really easy way to do it, because it's easy to think about Attackers and, you know, hackers us those winter who it is, you know, worrying that trying to hack the Pentagon or something else, but mostly, like easy for the low hanging foods.
The easy stuff that they can do is that figure out all of those known public vulnerability start, you know, everyone know about.
It's probably known, but people are really late in terms of patching and keeping up to date with them.
So one vulnerable is that they find in an ecosystem like NPM, for example, will mean many victims because everyone are using open source.
You know, millions of downloads for express.
Some will react whatever vulnerability that they find.
And absolutely, it's pretty hard, right?
That's one example of it.
And there's so many things that need to happen in a secure application development life cycle.
Just one example.
But what's really challenging is software delivery has sped up.
It is really fast.
Everyone trying to be really mature in terms of Sky City, pushing value, pushing data out, pushing code out et cetera.
But do we forget that we do we actually do to actually embed security testing and part of our application in modern, what we develop and what we push out?
We have this confidence that everything we push out is really tested very well and does not have any kind of security vulnerabilities like this.
We're also outnumbered in organizations, right in organizations.
The ratio that, like Gardner reports was was saying, is one security person for 100 developers.
That's actually a good example of it, because in most organization it's actually pretty worse than that.
How about the fact that as developers, we do not really get, ah any knowledge or any experience, practical experience or expertise on security, for example, these are the top computer science programs in the United States of America.
I imagine that you are able to recognize some of them.
I filter that leased to show all those that actually have requirement for software security course.
So no wonder that, you know, as developers, we sometimes feel that we do not have that knowledge in that gap that exists for us to build applications that are secure.
How quick do we fill in terms of not just finding, but actually fixing a vulnerability, actually being able to remediated?
But because at the end of the day, it is our responsibility, and it's great that it is like that open source is awesome.
We just need to do it in a very good way.
It is not so easy to fix of vulnerability.
And another thing that we learned from that state of open source security report is as we looked at the data that sneak has on all of its users, we just can't package manifest file.
So we really care just about the dependency that you're using and what we try to plot out is how does that work in terms of different ecosystems?
Like, where do we find security vulnerabilities?
So for NPM, for example, you can see that 78% off the time we will find security vulnerabilities, intransitive dependencies.
So even if you're like a conscious developer and very responsible and you track all the change logs for reactive, you whatever it is and you go through each go change one by one.
Most of the time, we'll find the issues.
Invulnerability is that those dependencies pull in and the problems that exist.
Er so what is?
Security was a bit easier, right?
What if it was something that is actionable that is really friendly from me to interact with that I as a developer, it is aligned with the way that I worked.
It's not a security system that I need to log into and find out about all of these things.
What if, for example, the same way that you have a Travis or a surgical CIA code coverage running in your, you know, full request, you would have another test, and you can replace Nick here with anything else that you want generally.
But What if you had If you add that right, What if a new developer was now introducing a security on a package that has security vulnerability?
It's weather on it or it's transitive dependency would go ahead and fill the bill because already detected it right there.
You do not need to find it.
I should go to production and find it, you know, a few months later.
What if it if that security tooling was really, really good in terms off not just opening a pool request for you and fixing it, which is a great step in doing that, but also doing that in a smart way.
So in terms off, if a dependency had a vulnerability and then a fix in a major version, it will actually try and fool the most minor and minimal aversion it can to resolve the security fix.
So to not, you know, get you through the hurdle of actually taking in a major change of raking change or future changes that you may not want to pull in with that security fix.
So I'm gonna leave you with that notion.
Open source is awesome.
Just please joint responsibly.
Thank you.


StrangerDanger: Finding Security Vulnerabilities Before They Find You! by Liran Tal | JSConf BP 2019

林宜悉 2020 年 3 月 30 日 に公開
  1. 1. クリック一つで単語を検索


  2. 2. リピート機能


  3. 3. ショートカット


  4. 4. 字幕の表示/非表示


  5. 5. 動画をブログ等でシェア


  6. 6. 全画面再生


  1. クイズ付き動画


  1. クリックしてメモを表示

  1. UrbanDictionary 俚語字典整合查詢。一般字典查詢不到你滿意的解譯,不妨使用「俚語字典」,或許會讓你有滿意的答案喔