Writing Secure JavaScript

[Music] hi everybody thanks for uh for having me here so I'm gonna talk today about writing secure JavaScript code just a little bit about me just for history is that I come from kind of a a long time security application security type of experience through the Israeli army and a bunch of application security companies and then did about six years in performance so for some people here I know through that world and that kind of back into a security startup dealing with using open-source securely so kind of jumping into it we all know I think probably everybody here agrees that javascript is awesome right you know we all love it and we like to talk about how javascript is one and it's the most popular language and it's a kind of out there by any metric kind of growing faster than anything else and there's a lot of reasons for it right there's a lot of goodness in it and all sorts of core javascript rates some are just sort of scripting traits and some are specific to JavaScript around you know built-in memory management and native C relation with JSON and the fact that it's naturally scalable various sort of great capabilities that help us be productive right helps us runs run faster and those are amazing capabilities and their core right and they are indeed parts of the reason that javascript is is so successful and that in general we can create these awesome things but sometimes the same capabilities that are sort of unique and make it awesome also make it vulnerable right so you look at these different capabilities and you know while you might see kind of built-in memory management I would look for the flaws there and I will see you know buffer object kind of leaking memory from server side if you talk about native serialization attackers would look and they would say well you can do some type manipulation because types are decided in runtime can I manipulate those can I change so a lot of this talk today is just going to be understanding a little bit about how these capabilities can be abused right how can attackers use them to to understand the weaknesses in your system and run forward the other thing that's important to remember is that these vulnerabilities in these types of flaws don't just happen in your code as part of a core a kind of a core part of the javascript echo system our packages are libraries then PME node you know it doesn't matter if you use bower if you use javascript libraries if you just downloaded a jQuery away much and much of your code is third-party code open source code that you are using and you know NPM is also awesome and as a result its usage has exploded I'm kind of picking on NPM but really this is true for package management as a whole and it has some like ridiculous number of times and packages every time and it's sort of updated slide and the result is that a typical application now will focus on node but this is increasingly the pattern in in front and javascript as well has a ton of dependencies hundreds oftentimes thousands one study put it at 350 on average and it leads to the situation where this is your app and this is your code and and this may seem like a negative slide but it's actually not right you could create all that orange value by just writing that little purplish dot orangish value so it's a good thing but it also is a risky one or a slightly frightening one from a security perspective it gives an entirely different meaning to javascript has one definitely on the dependency metrics javascript is also leading the charts so so with that context when you think about security it's also remembered to understand that most of your app's code comes from NPM which also means that most of your apps of vulnerabilities come from NPM or come from these packages so it's they're different sources that can lead into your system this is not a theoretical problem it's practical roughly one in seven when in eight packages in NPM carries a known vulnerability doesn't mean that 14% of them are vulnerable but the packages themselves use other packages that use other packages and within that ecosystem roughly 14% would bring in a vulnerability with them and we see that pretty much every node shop has those and this risks node apps and this is kind of the focus that I talk about here but when you talk about JavaScript it's not limited to just node it's also true for front-end application with jQuery has a very prevalent cross-site scripting vulnerability for using a specific component of it you know in react and angular in in with browserify with all of these components you pull in NPM packages and again the same concepts apply for Bower and it also risks the internet-of-things so there's a lot of chatter today about Mariah but all these like DDoS attacks massive attacks that take down the internet that are built on these devices many of these devices run node apps or very small lightweight apps and those could have vulnerabilities so those are that's kind of setting the stage and most of the time not going to spend in presentation but what we're gonna do is we're going to try and combine those two and what we'll do is we'll look at real-world vulnerabilities in these NPM packages it's I find it more useful than fabricating an example these are real packages with real vulnerabilities then you may actually be using and has a bit of a dual purpose one of it one aspect of it is to see the vulnerabilities and how can you kind of code to not have them and on the other side understand a little bit the security risks you might be pulling in through those packages and we're gonna focus on node but as I said this is sort of applicable more broadly so with that let me switch out of this and introduce goof so this is a JavaScript talk clearly it needs some surprise I'm the first one to have a model view control like I'm a VC app in a JavaScript conference and it allows you to do great things like you know to-do lists say you know call mom and you know it has some markdown supports to emphasize important things and you know just just sort of some features and it uses a bunch of packages on it I'm gonna use our tool snake it's on github by the way and on snake slash goof and you're welcome to clone this and play with this after and run those expose yourselves so we're gonna use snake to to test this application to try and find some of these vulnerabilities and I have some pre opened tabs just in case it doesn't play ball as we go so we will test our different repositories and we will find our little vulnerable app here and we'll see that goof has a bunch of these vulnerable dependencies so we're gonna pick on that and expand and I will kind of randomly choose a specific set not randomly you know I've chosen a set of these and show a bunch of exploits and they're you know each of these there would be some explanation that says if this is a vulnerable package this is the vulnerability on it and how it manifests we're gonna start with this one with SD who here is familiar with st not that many it's a it's a package written by Isaac from from NPM it's used to serve static resources j/s and CSS and are are website as well as our about page and it serves static resources from the the / public URL so to attack st st is susceptible to a directory traversal vulnerability and typically it would read the the adviser here but you have me so you don't need to see if this font is big enough so what happens is you know if we have some aliases to spare instant typing but if we go on and we do a curl and we fetch the about HTML page we're switching to the to the terminal because the browser has all sorts of convenience features around normalization and things like that that kind of get in the way of attackers so we can get the about page through here as well and as an attacker if there's a if I know where I suspect there's a directory traversal attack then the first thing I'm going to do is try to break out of the static file folder this is these are components that are supposed to serve a set of static resources but you don't want them to to serve more than those resources so I will put a dot dot slash dot dot slash dot dot slash and if I do that I will get nothing actually so if you kind of scroll up you will see that I just got redirected to the home page of it because st is a smart package and it has a security control on it it's not that they didn't think about security it just emitted something there's another way that I can represent a dot in a URL which is thoughts you're all encoding so I can do % to e % to e % to e % to E and that would get me all the way up to the root and I can do as many of those that I want and then I might want to add some sensitive files say like an et Cie passwd and voila I get they D say passwd so okay so this is just we're just getting started simple simple vulnerability and and you know sort of prevalence enough so we're getting roomed up we're gonna go from simple to complex right vulnerability at its core the vulnerability that SD had here and this is a common vulnerability we see around is just not dealing with encoding so you have to think about the different ways that a character can get represented in your system so this was on the URL side so we show it a bit of a URL encoding vulnerability but let's look at another one in Marr which is morning the HTML side so who here is familiar with marked a few more hands so marked is one of the more popular marked down parsing libraries out there and it's it gets about two million downloads a month you know it's it's quite prevalent and we use it to sort of do that you know emphasize beer and things like that in our system now we know that it's susceptible to a cross-site scripting vulnerability so what's the first thing we're gonna do yeah an alert script so we're gonna try to do something like this will say alert one slash script and we'll try to do this because markdown oftentimes many dispatchers including marked actually support some HTML snippets in there as well so we're gonna do this and nothing we're just going to get the text that's because marked has a sanitize function in it now surprisingly or not sanitize is actually turned off by default so that's something to consider many of these packages actually have insecurity faults so they might have a security feature might not be on all the time but in this case we did turn it on we wanted to be secure but there are other ways to get a script onto a page how else can I invoke a script thoughts yeah I can do a link so I can do there's a bunch of these I can also do like attributes I can do a non error I'm gonna focus on this right I might do a script like this so this is I'm still within markdown and I will do an alert one and then what happens here if I do this no nothing because mark catches this and again the sanitize function is quite comprehensive in fact it is fully spec compliant so even if I try to do get fancy here and I will try to use an HTML entity so HTML entity is kind of the HTML little sister version of URL encoding or maybe the other way around and I will represent this Colin with ampersand in a hash and I think it's a 51 and also from kind of past experience I know that I also need to encode this thing - I think of 40 so cheat here a little bit oh sorry this is 41 and the other one needed to be 48 58 and these are just sort of ASCII representation just numeric representations of this character and if I do this I'm now evading some of the security controls and if I do this I get nothing so again like security controls can be pretty tricky and this is on the HTML side something that's important to understand is mark is actually fully Spector compliant and it catches these things and there's no known exploits that are not SPECT compliant but browsers not so much so browsers tend to be very tolerant towards HTML mistakes and if I come here say after this eight and I say I'm just gonna zoom in further and I add the word this so the browser sort of season oh you know you said an ampersand and you had like the hash mark and had 58 it didn't go all the way but I kind of know what you mean you know I think I think you mean a Colin and they would pull a call in there and then the remainder of that is just script and this is a valid thing to call in script and I get a link here and we got our alert so vulnerability number two okay so kind of first lesson from those components you know one is just again think about those think about the different encodings and there's the URL side of it and there's the HTML side of it let's get fancier so in both of those cases we've talked about encoding former abilities but there are other properties of all the JavaScript one of JavaScript's kind of bigger claims to fame is is that it's naturally scalable right it is event-driven so it doesn't require a thread for processing every incoming request and it also means that it's a bit of a point of fragility because if one of those threads if there is an action on the thread that makes makes the thread take a long time some algorithm some you know infinite loop like the wild true that Jake showed before right if you had the wrong conditions you get those prompts in the browser that says this script is you know running for too long or you might take down a thread on the server and because JavaScript is naturally scalable even high scale production systems have a very relatively small number of threads so it can quickly lead to a denial of service vulnerabilities now the most prevalent type of algorithm that we run although we don't think about it that way often is a regular expression it's an algorithm it runs and depending on how you write the algorithm but almost always true to an extent the the time it takes to calculator sort of apply a regular expression is nonlinear to the length of the input string now that linearity may be hard or may be low so depending on your regular expression let me kind of switch back to the slides a moment and show you a bit of an example of this in a an aptly named problem in regular expression refer to as catastrophic backtracking so you look at this regular expression and it's it seems pretty simple right it's just of ABCDE and you could have like more of the C occurrences and then maybe a wild card but what happens here is the regular expressions are you know very stubborn they try to match so if you give them a pattern if you give them a methodology where they can almost match like almost get there but not quite they will backtrack and they will try to figure out another path and by having nested groups like this so first if you have multiple C's they could apply to the C+ inside the group or they could apply to the star outside the group and that just creates a ridiculously large set of possibilities and most regular expression engines including the ones in JavaScript will just try them all and as a result you can see that by just having this fairly short string there I don't know that's like 30 ish characters I can make calculating this reg s take a second and then every character I add would double that amount of time this is on a sample machine but it's definitely a lot of time so moment a very popular package has recently had this vulnerability I don't have an easy demo on that one but another package that's very popular that had it is M s and M s is used for yeah M s is used for calculating milliseconds or a timestamp in milliseconds so we can say you know call mom in two days and it would calculate those two days to say you know this is the number of time in milliseconds so I can set a reminder so and this has this vulnerability a little bit less extremely so it also has a regular expression now servicemen are ability but it's not quite as extreme so what we're going to do is first of all we are going to again kind of make this whole mom in 20 minutes and I'm going to use HTTP or HTTP which is the same as a curl just like with some syntax highlighting and it goes on if I go back to my application I will see that I added a little bit of a record here but what we will do is we will try to give it an especially long string so and again I'm just going to cheat because I have it just to spare myself some timing here and what we'll do here is we will print 60,000 fives as the duration and then we're gonna add another twist which is we're gonna swap the last character here instead of being an S to an a so it almost matches but doesn't quite and when I do this it takes a long time to respond now takes a long time to respond it's not a problem but the problem is then the meantime my application here isn't responsive so in this case I have a single thread and this is just taking out one heroku Dino here but you know first of all you can hike up my bill and if I add another zero you know it wouldn't complete before the end of this talk now this way it will I think in about ten or fifteen seconds a complete an end but this type of regular expression in our service is a very prevalent vulnerability and you have to be very careful about regular expressions both in your content and in code overall and now in this case you might say hey this is sixty thousand characters who in their white right mind would sort of past sixty thousand characters but if it's not explicitly blocked it is allowed there's nothing really there the fix in MMS by the way in the package is a little mediocre it they just capped it I think it's like a thousand or ten thousand characters the the right solution is to have a logical capita to allow twenty characters or thirty characters in the different sections so that you truly limit it because otherwise it doesn't take down the server but it takes a very long amount of time to process okay so our application will recover here we can just kind of go back here and we deleted a bunch of items so this was reduce and it really comes back to the event loop and the same times the problem can kind of happen on front-end for my last trick I will show a couple of other vulnerabilities so this was an MS and the last vulnerability I will show is in Mongoose who here knows of Mongoose yeah everybody so so Mongoose is know everybody knows Mongoose is the way to access money to be is kind of the top one and it has an interesting vulnerability in that it tripped over an object called buffer a buffer is a very very tricky object in the world of note typically when you wouldn't work in JavaScript don't really think about memory management right memory is this thing that's just sort of handled for us but buffer allows us to to play with a little bit and to pre allocate some memory and it has a couple of constructors actually I went to the advisory here but I can probably show you here if I just do if I just run node move this up a little bit so you can see it and if I do I can do new buffer and say 100 and I will get a buffer allocated with those 3 characters 1 0 0 but if I do a new buffer and give it 100 I will get a hundred bytes in memory that's intended however that memory is not 0 as you can tell here if I do this a few times you'll notice that you have very different values in the different items because this is just what happens to be in memory and those 100 bytes that I just allocated so as an attacker if I can make the application allocate such memory and then get access to that this is a remote memory exposure and if I do this enough times I basically can get anything that's in the system's memory including keys and source code and a lot of those components this is like heartbleed in open SSL except running in the node process so only access to the secrets that the node process has so buffer has tripped up many popular packages Mongoose included and for us we we have a little bit of a simple schema here that allows us to we use buffer as the content field and you know so we can have images and and other uploads and buffering and Mongoose indeed had a vulnerability where it did not enforce the the right type that goes into the component so what we're gonna do to exploit this is first again we're going to move to to the browser so we've already seen that we can do a curl command to invoke an item but what we will do is our application like many node applications also supports another form of input which is Jason so I can do echo with instead of a form field of content adjacent parameter of content and say fix the bike and if I do this then if I go back to my application I will see that we've indeed added an item that says fix the bike but because this is Jason I now have the ability to modify it a little bit and instead of saying fix the bike I can say 800 like this which would give me 800 as a string or because this is just naturally serializable I can say 800 like this when this gets si relized in the application it allocates 800 bytes and that memory is now a to-do item that's exposed to me and if I look here I will see just like a bunch of binary components if I just do this enough then you know it depends on the entry every demo I get something different but you might see some snippets of text and source code kind of need to trust me here that if you run this enough and you do a loop you just sort of extract those of course is an attacker you would kind of clean up after you you would delete these items right after so buffer has dripped many items it's really not just Mongoose but it's a pretty severe one because it touches on memory and allows that sort of be leaked out it also demonstrates a general a broader problem called a type manipulation which is true for any kind of type dynamic typing language and specifically JavaScript and can happen with Jason but also can happen in other components a good example of that is Q s and Q s if I parse a string like this I get a JSON object or a JavaScript object with two fields a and B but if I pass it to A's I get an array and for instance this tripped - KS which is a linked in templating library that PayPal used and actually had a real-world vulnerability on PayPal because a sanitization logic only happened on strings nobody anticipated that an input that came through the query string could be anything but a string but with Q s it can be with Jason it can be so it's just something to be aware of to say do you know which type is is the one that you're using and just sort of as a last anecdote is type manipulation can also be used to do something called no sequel injection so we've shown strings and arrays but if you have something like this where you use Mongoose to find users by username and a password and it's meant to be used like this where you have an admin and a string however if you can control adjacent input then you can do something like this and instead of a string in the password you pass it among this function that just say greater than nothing which is everything which means that if you've done this you just get basically like SQL injection you get a no SQL injection to return all the records and depending on your application logic this might have just made a pretty major thing so so just to cap off I want to show you a couple of things so before we close off here one thing I do want to show you is you know we talked about a bunch of vulnerabilities that are clearly many many more that we can talk about hopefully these give you a tidbit and the other thing you should talk about is you know on one hand you should understand the security flaws and on the other hand you should understand this application has been made vulnerable without writing any of this vulnerable code it just pulled it in externally so you know a little bit of a shameless plug you can try out snakes to help this you know help find those issues you know free for open source gonna try it out and it would also help you fix those issues just sort of open a fixed pool request with a single click like magic and just sort of try it out and take over protect yourself going back here so yeah as you sort of seen this live don't start hacking website you know you could get trampled in trouble and either way it's impolite I will encourage you above and beyond sort of general awareness to you first of all think about the JavaScript takeaways and these mistakes and and how can you avoid them in your own code and second is think about the specific vulnerabilities in these NPM packages use a tool like snake like no security project there's a bunch of these tools out there to help you find those issues use tools to help you fix those through upgrades through patches through whatever means necessary don't discount this this is a part of your job this is a part of software part of software quality these security concerns so to recap you as an NPM are awesome but please use responsibly [Applause] [Music] you [Applause] [Music]

Channel: freeCodeCamp.org

Views: 44,085

Keywords: learn to code, programming, coding, javascript, web development, web design, tutorial, python, android, security, testing, coding tutorial, javascript tutorial, web development tutorial, html, css, design, html tutorial, css tutorial, learn to program, learn how to code, learn how to program, get a programmer job, get a developer job, python tutorial, android tutorial, linux, learn programming, learn coding, linux tutorial, learn linux

Id: Xy1K8ODZC8w

Length: 24min 14sec (1454 seconds)

Published: Fri Apr 06 2018