Writing Secure Node Code: Understanding and Avoiding the Most Common Node.js Security Mistakes

hi everybody thanks for waking up this morning so to be in second session here I'm guy pajara our guy poet sneaked and I'm here today to talk about security to talk about writing secure node code just for context a little bit of history about me is I am at guy but at Twitter right now I work on snake the deals with open source security and I have a lot of experience in the web security space application security and the web performance space prior to that and I talk a lot on a conference circles Twitter blogging etc so javascript is awesome right I think everybody said it here would probably concur you're sort of coming to this office this conference and we like to talk about how javascript has won and you know it's kind of the dominant language in many metrics and there's a lot of reasons for it there are a bunch of these notable JavaScript traits that we can point out that make it great like some built-in memory management so we don't worry about that as compared to maybe some other languages has some built-in native serialization like Jason it's naturally scalable and a variety of other properties that make it powerful that make us productive and it'll build in it and these are great and they make us productive but sometimes the very things that make JavaScript awesome make node awesome also make it vulnerable so you might look at that list and talk about the productivity but I look at that list and I might see some flaws I might see some potential security risks if you have built-in memory management but is that comprehensive is there are places where you might leak some information out can I manipulate types in this dynamic typing environments and triggers and vulnerabilities there's a bunch of these types of flaws and it's important as we build applications in JavaScript to be aware of those and to try and avoid them to the extent we can the so a lot of this talk is going to be around those components but another important piece of context is that these types of capabilities as well as flaws are not just in your own code when we develop in node we also use NPM and the PM is also awesome it also makes us productive and lets us run faster and as a result NPM usage has exploded right like this the numbers on the slides just keep getting more and more ridiculous every time I need to update it just in terms of sheer volume and it leads to the situation where this is your app and this is your code and you know I like to kind of point out that this might seem like a negative slide but it's actually a positive slide because all you have to do is write that little purple dots to get all of that orange ish value and it's a good thing but it's also a scary thing it also implies some diminished controlled so most of your applications code comes from NPM which also means most of your applications vulnerabilities come from NPM from all this code that you're pulling it that runs in your system it's just important to understand this is not a theoretical problem we see that about 1 in 7 packages in NPM carries a known vulnerability in there in its own code or in one of the dependencies that that package in turn uses so it's a very real problem and most of your applications probably have use of some of these vulnerable components and this implies - this applies to node and applications which is where I'll focus today but it also applies to front-end applications as more and more third-party code makes its way into that space as well so what we're going to do in this talk just with this context is actually leave a keynote here leave the presentation and we will see we'll do some live hacking - though oh it's fun and what we'll do is we will use real vulnerabilities in real NPM packages and understand them exploit them a little bit to understand their impact and then use those both on one hand as awareness to the potential risks that might come in that NPM package as well as a learning vehicle to understand how should we write secure code ourselves and then we will focus on node but again this sort of applies to client-side - so with that let me move over here I'll switch to the browser loaded well ok so this is a JavaScript talk so of course I have to do MVC application in it this is called goof and it's a vulnerable to do application it is vulnerable by virtue of pulling in some of these vulnerable packages and it allows us to do it's a to do application right so you can call it by milk or you can say call mom or all sorts of reminders for you to do and goof is an open-source application it's on sneak slash goof and you can try it so what we're going to do is we're going to test it and see which vulnerable packages does it use and then we'll see what is the implication of it I'm going to use sneak for this we'll go off choose the relevant application so over here snake would have tested the different packages that I have or different repos for vulnerable packages and I will choose goof and see that I have a bunch of these vulnerable packages on it right so this is sort of step one just to understand that you have those vulnerable components in your system and there's a bunch of them here and I'm going to pick a few that I have sort of easy exploits to show but there's a bunch of these vulnerabilities they can read up on including a fairly recent one that was just published on ejs remote code execution in the enterprise in the EGS templating form so we're going to start with a simple export here on SD so SD has a directory traversal vulnerability and typically you would read the advisory on this but you don't need that because you have me so I can show it instead so we use SD in our application to serve static resources public like CSS and stylesheet and JavaScript files as well as to show kind of our awesome about page which is just sort of demonstrates how awesome goof is so to exploit it we're going to switch to the command line because the browser is just not sufficiently friendly for a hacking activity to go and um just gonna have some shortcuts for me we're just going to go off and we'll do a bit of a curl so we'll switch to sort of warm up and get our about page via curl so far so good now we know there's a directory traversal vulnerability so when you have that when attacker would watch what an attacker would try to do is break out of the folder where the static resources are and try to get outside so it's going to try to do something like this and if you do that you will get nothing actually you'll see that you got redirected to the goof to do home page and the reason for that is that st is a good package was written by isaac from NPM and it has some security consciousness in it and it did try to avoid the specific concern however it has a vulnerability and that vulnerability is in not factoring in all the different encoding paths that you could have so what's another way I can represent a dot in the URL anybody oh sorry didn't catch the whole thing I will assume that you said URL encoding although I'm not sure if that's the one which is I can do a percent tui and 3% to 80% 2e % to e and I can just go back as much as I want because I can just do dot dot at the root folder as much as I want and then say I tacked on et Cie passwd and voila I've got DTC passwd file so we're just getting warmed up this is a very simple vulnerability but just sort of shows it's a good package it has secured consciousness but it has a flaw which was fixed at a later version of this package so getting started first package you know first lesson is just beware encoding second package we're going to look at is marked who here has heard of marked okay a good number of hands it's a markdown parsing library and we use it in goof to be able to do things like you know emphasis like if I want to say buy beer and I want to give it a sort of the proper attention that it deserves then I can use it for emphasis as a variety and other components in it and a goof uses mark then marked is you know it gets about two million downloads a month and it has a vulnerability that is a cross-site scripting vulnerability and how it processes it so it's got to go through a little bit and understand it again typically you would read the advisory so if I know there's a cross that scripting vulnerability here what's the first thing I will try scrape alert one /script and I don't get anything I just get into text once again marked has a security controller in it unfortunately is not on by default called sanitize but if you turn on sanitize like we did here it would capture this and it's really comprehensive even if I went ahead and I did something like this and said JavaScript : alert 1 which is another way to sort of embed a link it would still catch it so sanitize is a pretty good function but again there's a vulnerability in here and that's because once again encoding was overlooked so how can i encode something in the HTML no not as well-known as a as a your own encoding is HTML encoding HTML entities so I can do something like this and I can do a percent 41 I think and these are basically just equivalent ways to represent a character ASCII or otherwise and the browser would interpret them the same way toward regular code so if I do this sigh still catches it so it really is a very comprehensive and sort of spec compliant type of defense mechanism there sanitization function and marked so marked was actually fine however browsers not so much so browsers say I do something like this and I add like this over here browsers go here and so well you know I see the ampersand they see the hash mark I see the 58 you didn't go all the way and kind of add that semicolon there but I know what you want you know I've got your back that's okay this is a call it so if I do this if Walla suddenly I do manage to get through it so marked was actually good you know they sort of did the right thing and they are very spec compliant but the browsers with their flexibility and just like this complex world of evaluating pages did allow that to do it and we got server script into it so again both examples are all about encoding and encoding and be able to sort of circumvent existing sanitization logic is a very very common problem in NPM packages any node code as a whole and it's something to be alert of kind of aware of so these were two packages let's look at a couple more and then we'll kind of conclude a little bit more and we're going to get fancier as we go kind of get a little bit more complex the next one we want to look at is ms who here has heard of ms okay a little bit less it's actually also very popular and we use it it is a package that converts all sorts of date strings to to the number of milliseconds so we can say you know call mom in two days and it would figure out that the two days means so many milliseconds so we can set a reminder for it so it's a nice little package very widely used and it is susceptible to a regular regular expression denial of service vulnerability so here is probably worth stepping back a moment and talking about the event loop so one of JavaScript's claim to fame is the fact that it runs on the event loop and it's very therefore naturally scalable if you want to serve many clients you don't need a thread per client you launch one thread and all of the blocking actions all of the i/o functions are event-driven so therefore that threat that single thread can process many many different clients and that's true and it's a good thing but it means that if our code misbehaved if we ran an infinite loop or if ran a very slow running algorithm it would take up that thread and it would now deny service to all of these different clients at once so it's just a tiny bit more fragile and well we don't think of them as algorithms the most popular algorithms or more frequent most frequent - algorithm that we run in our code is a regular expression and actually let me go back a little bit to my slides just to sort of explain this in an example so regular expressions are algorithms and they're really a state machine they run through a string and they typically take a nonlinear amount of time to process input nonlinear to the length of the input that they got so let's look at this fairly simple looking type of regular expression it just says you know ABCDE and C can be multiple times because of the c plus or it could be multiple times because of the brackets and what that means is that when we give the regular expression engine something that is almost there that almost matches a regular expressions are greedy they really they aim to please right then they would run through it and they would get all the way to the end just to realize that they could not match and then they would backtrack and try another permutations and then backtrack and if you did this model you would trigger what's called as catastrophic backtracking and in this case the problem is that this C letter can show up either as like multiple occurrences can show up as the plus or they can show up in the capture group there and that leads to many many many different permutations and it means that even a short string like this this is thirtyish strings may take a second to process and every character you would add my double that amount of time clearly this is on a computer but you know it would take down threads very easily so this is an extreme example of regular expression denial-of-service and basically this happened on moment which is another popular package which we using marked but I don't have a handy exploit to it and you could take down a server with even 30 or 40 characters in the case of MS it required a slightly longer exploit and if we're going to do this what we will do is we would switch to the command line again and we would just run this little action here so we're going to print 60,000 fives as the raishin of time and that would again sort of trigger a long string that goes into into that regular expression and the other thing we're going to do is we're going to change the s here to an a so it almost matches it gets all the way to the end but doesn't quite and if we do this it takes a long time to respond and in the meantime what's maybe more interesting is if we go to the application and we try to do things here nothing happens it's stuck and it's because the thread is now occupied processing this long regular expression now you might think hey 60,000 characters is a an abnormal length of input and you'd be right except somebody needs to actually ask that question and block the long input coming in and in most cases that doesn't exist and unless you explicitly put that in there so hopefully if I added a zero then this would have taken basically the entire length of the presentation hopefully this is now done and the pretend the system cannot run again the the fourth former ability and the last one I want to show is in Mongoose who here is heard of Mongoose probably everybody someone goes clearly the way to interact with MongoDB and one of us has a slightly more elaborate vulnerability triggered by buffer buffer is a tricky object in the world of node that you might have heard of and the reason it's tricky is that it deals with memory so if I just a run node here I was assuming of it even more buffer supports two constructors so I can do a constructor that says buffer new buffer 100 with a string and it would give me 3 characters 1 0 0 or I can do new buffer with a hundred like this and it would allocate a hundred bytes and that's fine it's a little bit weird that you can pre allocate things in JavaScript so it's a bit of a unique entity in the server JavaScript world but what's more interesting is that if you look at this you see that every time I allocate the memory I get a different type of content that's because buffer does not by default 0 the memory that it allocates it just takes up whatever chunk of memory and just uses up those 100 bytes so if now as an attacker if I can leak that information out that allocation out and get that to me as an attacker I have remote memory exposure I suddenly can access server-side memory and if I do that enough I will basically expose pretty much all these secrets that's it in the node processes memory including source code and keys and the likes this is what happened with heartbleed in open SSL this is remote memory exposure so because buffer is so tricky because the constructor is like this it tripped up quite a few packages Mongoose being one of them and we use we use buffer as a part of our database schema here to hold our content entities so what we need to do is we need to somehow trigger the allocation of the use of the integer buffer and we're going to do that using a technique called type manipulation so if I go here and I do this what we'll do is we will switch from using a curl a form posting to another type of input that our application supports which is JSON very popular very prevalent again in the world of node right one of our advantages we could take JSON as input but what we might have forgotten is the new JSON while I can do something like this and I can say oops I can say content 800 like this and I will get if I go back to my application here and I reload I will get a string 800 with the JSON relation I can also do this and what this will do is when I serialize or when when this object gets created in JavaScript this would now have a type integer and again unless anybody verified it in the process that type integer would now be passed into that buffer would be stored into that database and now that record holds some real-world memory and I'm just going to get some binary craft here and if I did this again I'm just going to get a bunch of those and sometimes you might start seeing some source code in it but it'll be a different chunk of memory every time so this is a remote memory exposure not good you know very problematic again a bunch of popular packages have fell for it including a request and I think WS so something to be wary of so these were just a few examples of vulnerabilities what I want to do is just spend the last couple of minutes talking about remediation right hopefully there are some examples here but things that you should do in general reminder that you should care about security when you write note code and some specific examples of things you can take care of the other aspect is that all of these vulnerabilities were in NPM packages goof actually has you know a couple of vulnerabilities in its own code with most of the vulnerabilities in it are from NPM packages seems so talking a little bit about that the way that you would address that is first test for it so you can use sneak you can use whatever tool that you want to try and know that you're using a vulnerable package and second is you want to fix it the way that we do it and in snake is you just click here to do an open fix PR which would prompt you which fixes do you want to do and then click this and it will generate a pull request with the necessary changes we have patches for some of these vulnerabilities and we have guided upgrades to various others so this is really with the intents that you can kind of build this in to your workflow and make it a natural part of your github workflow or or CLI workflow or whatever workflow that you have on an ongoing basis and then you want to make sure that you do this continuously and that you once you are vulnerability free but you stay that way right that you don't just you know if you want to first identify the problems that you have today and fix them and then subsequently you want to do that in a continuous fashion and the last thing you want is you want to be set up to be able to get alerts or be reminded about new vulnerabilities because once a vulnerability in code gets disclosed it is now known to the attackers as well and it is that much more likely to be exploited so there's a bit of a race once the disclosure occurs then there's this race that kicks in to say you know who do the defender fix first does the defender fix first or does the attacker exploit first so you can stay on top of these vulnerabilities again using sneak it'll be on your specific application or you can check out our database on synchros flash foam and follow the components there so to recap back to my slides first of all don't go start hacking websites in it it's not gonna end well and if you really really want to you can go to a github slash sneak slash goof and download this vulnerable application and just sort of have at it that is on your machine and you're fine with it hopefully this talk is giving you some takeaways around secure coding so you know just to recap what we've seen is encoding is tricky think about all the different encoding paths that you do when you have to build it be careful of long algorithm runs and specifically for regular expressions try to contain the input length and think about what you allow in and just when you're building a regular expression C you know can you make it limited in length beware tide manipulation type manipulation can actually happen through the Q s package through various other aspects it's a little bit more unique to scripting languages it's not as well understood but it is a very dangerous type of attack and beware buffer buffer does have in the newer nodes there is a buffer dot Alex safe and buffer dot a lock unsafe option that you should use those instead of the default constructor and in the different packages and unfortunately you have existing code that uses those default constructors you could choose to zero the buffers as a command line with the risk of breaking some functionality but increasing security I'll kind of leave that decision to you about using NPM packages I would encourage you to find those vulnerabilities be aware right get the head at his hand you know accept this is part of building a secure equality application and find those vulnerabilities fix them prevent adding new vulnerable packages once you've done that and then respond to vulnerabilities new vulnerabilities quickly a lot of different ways to do it I'm biased I'd say you sneak for it but just make sure that it's a part of your workflow that's it Jeff an NPM are awesome but please enjoy them responsibly thank [Applause] come and and I have I'll take some questions here and I'll also say that because we like to say that snake fixes vulnerabilities like magic we actually have magic ones that a hope that you could catch in it so if you want one of those just catch me after the talk look if you won any questions I think we can do a couple of minutes sure do you want to actually step up over here just do you guys do any auditing of private packages within organizations to discover vulnerabilities so we ourselves Nick we don't do like we're not a services company we don't do auditing we do sort of recommend that you get a security consultant to do that for your code so you know happy to chat afterwards about specific entities you're talking to I do think like it's very important to secure your own code that said I think dynamics are changing and today the majority of code that you deploy is third-party code and that's also the easier code for attackers to exploit because you know they have access to it it's just dramatically easier and that's why today anywhere between 80 and 95 percent of successful exploits happened through unpatched known components like unpatched vulnerabilities and you know it's because it's the low-hanging fruit so hopefully do that other questions well let you get back to the break I'm gonna be here if anybody has any questions anyone step up thank you

Channel: node.js

Views: 93,609

Rating: 4.9841895 out of 5

Keywords:

Id: QSMbk2nLTBk

Length: 22min 30sec (1350 seconds)

Published: Thu Dec 15 2016