Node.js Node.js Interactive North America 2016, 15 Dec 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Surviving Web Security Using Node.js by Gergely Nemeth, RisingStack

Description

Surviving Web Security Using Node.js - Gergely Nemeth, RisingStack

Security - the elephant in the room. Everyone agrees that it is very important but few takes it seriously: in the recent past a huge number of companies leaked massive amounts of user data. Let's take a look how we can survive web security - from an application developer's point of view. In this talk we are going to touch the most common web security issues as well as some advanded attack vectors and learn how to defend our applications against them, like:
* cross-site scripting,
* injection attacks,
* storing passwords,
* cross-site request forgery,
* securing dependencies,
* timing attacks

A

Hello everyone, so my name is Jurgen Emmett and I'm, one of the founders of rising stack and today I'm here to talk about surviving web security at rising stack, we are building a tool called trace which helps you to monitor and debug your node.js applications as well as micro services and a trace. We are dealing with a lot of sensitive information, whether they are CPU profiles, memory, heaved and stack traces, so our customers trust us with sensitive information.

A

This is why security is one of our topmost priorities than building trace, but when we are working and security a trace, it's really hard to figure out what kind of attack vectors we should protect our application against. So when we do that, we usually use attack trees, and this is a methodology. I want to show you today so attack. Trees are metabolically of how you can describe security of systems based numbering the text. First, it was described by Bruce Schneier. So what does this definition even means?

A

So imagine real life case of opening a physical, safe. This three here shows us how an attacker could open that given safe. So, in this case to open the safe, he either have to pick lock. It learn the combo or use a bad setup of the trade of the safe to learn the combo either have to find it somewhere written or learn it from the target and to learn from the target either had to blackmail it bribe him or eavesdrop on him.

A

So this is how he could get to open the safe, but based on who your attacker might be. These three can vary a lot. So if your attackers are university, student or groups, backed by huge corporations, they are totally different, have have totally different tools at the disposal. So what we can do here is the modifier attack tree to reflect that so the way I modified this attack tree for now is that I marked with P read the possible bus from an attackers point of view, and this is right right also here.

A

The blue means that it's impossible for a given attacker. So, in this case, the happy pass from an attackers point of view is to open the safe by learning the combo by learning in from the target and by bribing him. Of course. In this case, this means that you should protect yourself against this attack you, because this is what possible, from an attackers point of view, but to grab an example for you, from our industry and from technology.

A

First I've picked the I of service attacks, how you could actually model it using the batteries, so I just picked a really exact simple example here, in this case, to make the service not respond to user requests. The attacker could either use a distributed version of the night of service attacks or using ego reg axis and today, I peep, to talk about a little bit more details about Eva reg axis and what are them, but first I'd like to explain a little bit how reg X is work, so you have a better picture on it.

A

So imagine that you have this really simple, brag X, which basically tries to match swings which starts and end with an A. So this is the tree here which is drawn with the reg X implementation, not just any other stream. Java should be most of the languages run. So when you enter an input, the reg X engine try to match the input with this finish ultimatum. So, let's take out an example and whites, it can be problematic.

A

So imagine you have a short input like only four A's and an axe and the end in this case. There are 16 possible parts on this tree. But what happens if you have a lot longer input, so we have like 14 days here and an axe at the end. In this case there are more than 60,000 possible parts to match against. So some implementations of Java revs engines can really reach extreme situations.

A

We're comparing matching against them can take a lot of time, so these rag axes actually have a name which I mentioned. First. They are called Eva rag axes, so they can be like the following ones: looping with repetition or another one is inside the repeated group. There is either repetition or alteration with overlapping right. Extreme is problematic when we are using not GS that we have a single thread, so just take the following example here, so we have the rag ex that we talked about.

A

We have a quad root handler which basically just matches this user input against that reg X and tries to UM say that hello, not interactive, let's see how it would work or not. So what I'm going to show you in this video if I can play it yeah? So what you see here is that.

A

A

Okay, so, but you would see here, is that first I entered the ax to the parameter, and in this case it would just load in a couple of milliseconds, then on the next step.

A

I would enter the long version which would take like 16 milliseconds, to fulfill the given request, but even if, in the meantime, I go back to the first step and try to reload the short one which took like 2 milliseconds previously, then in that case, that request would have been halted as well, because our engine, our JavaScript engine in that case, would work on matching the long version. So even especially crafted a single strategy. Crafted input could bring down a whole service because of this. So just as a reminder.

A

You should always check whether your reg axes have this kind of path terms inside them, because with damn you make you, your attackers would expose them and bring down your services without thousands of devices, but one especially if you have to the input.

A

So the next thing, which is, which should be a little bit more complex example for attack trees, will be about actually how an attacker could get access to user account. So for that, I have a little bit more complex attack tree here. The attacker could get access to a user account by either modify the conditions in database and to do that, he either had to be at access to the database or use sometimes social engineering or to get access.

A

The database learn the password, interesting and transport layer or guessing it somehow or bypass the access control by exposing some kind of insecure dependency. So first, let's pick the guessing here, so the most common guessing the tag that you can think of. Of course, the brute force attacks, so basically, a brute force attack enumerate all possible candidates for a given password 3. It finds the good one.

A

The problem with this with an ethics point of view, is that it takes a lot of time, but luckily, for you, it's kind of easy to defend against, so you have to make sure that it takes even more time. So this is why it's really easy to just add a rate limiter for your application for the endpoint, and with that you can say that how many login attempts can a given user take, for example. So, just a really quick example how you could use that this is the null limiter module from NPM.

A

Here we use the email address to limit how many login attempts a user can do. But what's more interesting, is timing, attacks, use timing, attacks to guess something so timing attacks are side-channel attacks which expose the underlying physical systems characteristic to get information about, given, for example, in this case lyft ography operations. How much time do they take? So a really quick example for them.

A

If you, if you have API keys, entered by some user or API key stored somewhere, then you would say that okay, let's compare them using the equal operation, but this is something you should never do. Let's see what hi Y so to fully understand this, we have to first understand how we eight compare streams.

A

So what I'm going to do here is that explain how string comparison works so the very first iteration, but first of all it will compare letters by letters, so the very first operation would be T in this case when comparing two strings they match the second one will match as well and so on for the third and fourth until the fifth operation as well.

A

So we have five iterations to compare strings the next one is two strings that are not the same, so in this case the first iteration, still, okay, we have a match and the second position we still have a match, but on the third one we don't so in this case because of performance optimizations. We actually stop doing this perishing and it will say after the first one that it's a mismatch. It makes no sense to actually continue it so comparing strings that match. She takes more time that comparing strings that are not the same.

A

So this is why you should never use legal operator to compare API keys passwords so on so to circumvent the problem. You should always use some kind of fixed and comparison to compare API keys. For example. The only thing yet you have to do is use the trip, tiles module, which can be found on NPM and instead of using the equal operator, you should just use crib tiles that fix them comparison and it should solve your problem.

A

The next thing which I wanted to mention are insecure dependencies just too big a part actually so in this case insecure dependencies caused by past access control, vulnerability. This is how the attacker could get access. The user account.

A

You know there are more than 300,000 would use an NPM, which is quite a lot so picking the right from them and which don't have any issue can be quite challenging, but still it's the consumers responsibility to know if it has an issue or not, so you are basically what you're requiring into, but luckily for you, there are a couple of great projects that can help you with so the first one was the last security project which we learned yesterday that it will be part of the Foundation, which is really great news.

A

Also, you have sneaked as well just give you better an understanding of why it's really a huge problem. So imagine that actually it's a fact that last week the node UUID module had some problems, which is actually downloading more than a quarter million times daily and more than four thousand modules depend on it. So if the not UDID module has a security problem, surely more than 4000 modules have a security problem.

A

So, given all these facts and how security is currently not part of our daily workflow, this was the reason why we added sneak a security feature to our to trace. So, if you're, using an APM, if you're using trace, you can just go to the security page, and we will tell you if you have any known issues in your modules, which actually brings us to the last thing which I wanted to mention. What one of the most important ones is the human factor when talking about security, so from the attack tree that we saw previously.

A

This is the way where the modify that credential modification was actually done by some kind of social engineering, so human error and what was quite surprising, at least for me- it was that more than 95 percent of all security incidents, if involve some kind of human error, so it means that something was forgotten. Something was not coded the way it should be. So a lot of factors contribute to this huge number of issues.

A

So it's safe to say that in our security chain we are the weakest link and because of this, I am saying that security must be part of the agile workflow. What you are working on every day, so just take it one step further stories or stories should include acceptance, criteria for security as well, which can be as easy as the following example.

A

So, for example, if there is a profile page which you want to implement- or you have to implement in this case, for example, given an unauthenticated user when she tries to view the profile page entries are not authenticated that she gets redirected to a login page. Of course, it's a really simply simple example, but this is how it should look like and, as I mentioned, that most of us code a lot open-source projects as well, but not just open source.

A

Our companies depend on the code that we are shipping, so security is part of our job. Security is part of your job. So if you are shipping a new feature fixing something you should always think about the security aspects of it as well, so which actually brings us to the end of this presentation, if you like it and you'd like to learn more I have a couple of resources for you. There is the node.js security check list which can be found on our blog.

A

Also, the advisories of NSP and the OD value at ESCP top down list is a great resource to start with as well. Thank you.