089 JSJ The Node Security Project with Adam Baldwin

Download MP3



01:00 - Adam Baldwin Introduction


Next Week

Users Groups


AJ:  Yeah, I kept on trying to butt in and then nobody let me talk and I was like, “Why are they being so mean?”   CHUCK:  We’d tell you it wasn’t personal, but that would be a lie.   [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]    [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]    CHUCK:  Hey everybody and welcome to episode 89 of the JavaScript Jabber show. This week on our panel, we have AJ O’Neal.   AJ:  Coming at you from the present.   CHUCK:  Jamison Dance.   JAMISON:  Hey friends.   CHUCK:  Joe Eames.   JOE:  Hey everybody.   CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week, we have a special guest and that’s Adam Baldwin.   ADAM:  Hey.   CHUCK:  Do you want to introduce yourself since you’re new to the show?   ADAM:  Sure. I’m Adam Baldwin. I’m team lead at ^lift Security and I’m the founder and organizer of the Node Security Project.   CHUCK:  Awesome. So, is Node a not secure system?   ADAM:  It’s [chuckles]…   JAMISON:  Oh, geez, starting off with the hammers.   ADAM:  Man, started off with a hard one. Right, yeah.   CHUCK:  [Laughs]   ADAM:  [Chuckles] Well, it’s got its problems just like every other platform. It enables us to write software and as humans, we tend to write perfect software, right?   CHUCK:  Of course.   JOE:  Yes.   ADAM:  Bug-free.   CHUCK:  You’ve seen mine, right?   ADAM:  Yeah, bug-free. So, I think that answers it. It has all the same issues as every other web platform out there, every other development environment.   CHUCK:  So, how are people doing it wrong then?   ADAM:  So in Node, we have a lot of frontend JavaScripters that are becoming backend developers right now. They’re being sucked into Node. And I know JavaScript’s now doing things in the server. And they’re confronting a whole new class of vulnerability that they never had to deal with in the frontend. Those are the things that I’m seeing from JavaScripters that are used to the frontend.   JAMISON:  Do you think you could maybe talk about what the Node Security Project is a little bit, just to give us an intro first?   ADAM:  Sure. The Node Security Project is a community effort that I started to basically   JAMISON:  Well, for the fame and the money and the power at first.   ADAM:  What? Right, right. I had the, yeah. I had the fame.   CHUCK:  Why else do people do open source?   [Laughter]   ADAM:  Fame and money. Yeah, no, it was basically to evangelize security. That’s all I talk about, is security, security, security. And I wanted to, was getting more into the Node community. At &vet, we had started building a product and basically I had to figure out what all the security issues were with Node and the community. And so as I got more involved, I noticed the need to evangelize security. So we started this project to evangelize security and help the community out there. But we also started it to audit the modules being published in npm so that we can fix things as we find them, raise awareness around those types of things.   JAMISON:  So, is your background in security or in Node?   ADAM:  Yeah, my background is sort of all of the above. I’ve done development. I’ve done systems administration. I’ve done network ops. And I’ve done a lot of security work.   JAMISON:  Oh, cool.   ADAM:  So, I sort of have a multi-hat and I sit firmly straddled between the development world and the security world, two worlds that don’t tend to play nice together.   JAMISON:  Sure.   JOE:  How did you end up with such a varied background?   ADAM:  I didn’t come at it from a traditional -- I didn’t get to go at my career path in a traditional way. I got in trouble when I was 15 for breaking into the admin side of a bulletin board system in the middle of nowhere in Minnesota. And from there, I was given a job opportunity and it led me down the trail of internet service providers, doing network ops and system administration and things like that. And I eventually got sick of that. I ended up with Symantec and then I left there to start my own firm, Ingenuity. And eventually landed at ^lift here.   JAMISON:  So, part of what the Node Security Project is about, you said, is to audit all of the modules on npm. And that seems like a…   ADAM:  [Chuckles]   JAMISON:  A Sisyphean effort, right? You push the boulder up the hill and it rolls back down, because it’s so much easier to write a module than it is to audit it for security problems. How are you trying to do that? Are you concentrating on popularity first?   ADAM:  So, I’ve been asked this question a lot and it’s sort of an effort to boil the ocean, right?   JAMISON:  Yeah.   ADAM:  When you look at it and when I say audit all the modules in npm, people immediately go to look for all the things in all the things. And that’s not possible. We can’t sustain that growth. There are 50,000 modules on npm. It’s just impossible to keep up. What we can do though, and after a lot of debate, we can take one approach which is look for one pattern in all of the modules and we can automate that. So we can say, “Let’s do a manual analysis, then we can automate finding that pattern, creating tickets, and letting humans sort out the false positives.” So, we can keep up that way. And we can ratchet up the baseline of the community.   We can say we want to eliminate remote code execution via childProcess.exec and we can get rid of that from the module base by catching it when modules are published and evangelizing those efforts. The other thing we can do is focus heavily on those popular modules. We haven’t actually gone about it that way. We’ve just focused on our own toolkit and stuff. But we haven’t done an audit of say the top hundred. But that’s in the docket to do.   JAMISON:  Sure. That makes a lot of sense. So, it’s more like a call to action, leading by example type of thing.   ADAM:  Yeah. That’s what we’re trying to do. And it’s basically just call out things and evangelize where we can and send pull requests where we can. And worse case, even if we fail miserably, we’ve fixed some vulnerabilities and got some people to be more aware of certain security issues.   JAMISON:  So, are you involved in security issues with Node itself or are you mostly focusing on user [inaudible] stuff.   ADAM:  I’m mostly focusing on user land stuff although I’ve talked to many people on the core team about security issues and know that they’re interested in shoring up their procedures and things like that. I don’t get really involved in core other than as a distribution channel for, ”Hey, we’ve got this vulnerability,” and I’ll probably write a blog post on it or tweet about it and get people to understand, “Okay, we’ve got this release. You really need to update,” those kinds of things which we’re working on. [Chuckles]   JAMISON:  Yeah. So there are a couple, Rails is the one I’m thinking of the most. It’s a framework that has a very well-defined security policy. And it’s a little bit of an apples to oranges thing because you’re looking at the entire ecosystem for a whole platform as opposed to one framework. But do you have any kind of vulnerability disclosure thing where you expect people to email you privately? Or are you all about public [inaudible]? How do you think bugs should be disclosed?   ADAM:  Okay. So yeah, you’re definitely right that we’ve got an ‘apples to oranges comparison’ in terms of Rails is a collection of opinions and has more surface area.   JAMISON:  Yeah. So, the reason I mentioned Rails is because it’s the security policy I’m the most familiar with.   ADAM:  Yeah. And we have sort of a big problem. So, let me talk about core first. Core has a defined place where you can mail, email if you’ve got security bugs. They don’t want them publicly put in there, public disclosure issues, which is good. They have that baseline. But that hasn’t been very well evangelized. And I don’t think they’ve called it out enough, at least the last time I checked at NodeConf.eu, the policy wasn’t up on the main Node site. And the process is a little bit [inaudible] defined and we don’t know what the timelines are for disclosure and resolve and things like that. And there’s no expectation of communication and things like that. That isn’t established yet and we need to improve that.   The thing is that the core team is aware of that and I think is willing to improve on that. Now when it comes to the third-party modules, we have a giant problem. With Rails, you’ve got all these things in one spot. You’ve got a place where you can email. It’s a central source to talk about anything that’s involved in that community. With third-party modules, there’s no cohesive place to send those.   So, what we’ve kind of been doing is we’ve been a clearing house for that, as like notify the project and cc us and we’ll help deal with that through if we can. We can probably do a better job of evangelizing that and publicizing that as well. But that’s the status of things right now, which is I don’t think not as good as some other communities and we can do better at that.   JAMISON:  It’s super exciting though because it means there’s lots of work to be done, right?   ADAM:   Yeah, it’s not initially glamorous work. But it’s certainly important work to do for the Node ecosystem.   JAMISON:  So, if someone wanted to get involved with it, what would they do? Especially if they’re not someone with -- are you looking for people that have specific security backgrounds? Or what could the average Node user do?   ADAM:  So, the average Node user right now, the way they could help is we’re currently building some of our toolset. So as I said, I’m planted in between development and security. I’m more security-minded, meaning that I develop really slowly. So I need help in building some of the tools. The API to store the data and deal with the data that we’re pulling off of npm as things are published. And so I need the help building some of those tools. That’s where somebody could get started. And that’s just on GitHub.com/nodesecurity. All of the repos are up there. I have not done a good enough job architecting and detailing out what needs to be done, but the API repo is where we’re currently actively working and we can certainly guide somebody there to help out that’s good at building web APIs.   Now that said, that’s where the developer can step in. The goal however is to have anybody of a development background be able to step in and actually audit a particular issue. So the workflow would work something like this. You log into the portal. You press button receive work. So you press a button, you get a particular issue that we’ve identified as a hotspot. So something that’s potentially vulnerable but we’re not sure. The person would then have a description that would describe what the vulnerability is, an example of vulnerable code, teaching them about that particular issue.   So, it’s like a Node School type lesson, NodeSchool.io. And it’s a lesson like that, just not as interactive. And then they’d be presented with the details that we’ve found as the hotspot. And so they’d be able to basically mark that as vulnerable or not vulnerable and then it would be under review after that. So the intention is to have developers be able to do this, learn something for it, as well as contribute to the community.   JAMISON:  That’s pretty sweet. While you’re talking about the place for a web developer to work on the API, I was just thinking, “You better be really sure you write secure code because otherwise you’re going to get made fun of on the Twitters if you put some security bugs in the Node Security Project API. [Chuckles]   ADAM:  Yeah. But guess what? We’re humble. We know that software people make mistakes and security is not about not having vulnerabilities. It’s about process, right? It’s about assessing, measuring, iterating, doing better and learning from that. It’s not possible to be 100% secure. It just doesn’t happen.   CHUCK:  So, what is a good security process then?   ADAM:  So, the Ember.js project I think has a good disclosure process. I don’t know what their -- it’s Emberjs.com/security. And I think they’ve got a decent communication and hybrid based on a bunch of different historical documents. You know, some of the old [responsible] disclosure policy and things like that. They’ve mixed together. The talks about, “Here’s where you should report it. Here’s the communication expectation that you should have,” and those kinds of things. And I think that that’s a good model for an open source project to follow. I’m not so familiar with the Rails’ actual disclosure process. I should probably read that and be familiar with that. But I don’t have it memorized. But Ember’s the one I’ve been using to point projects to. [Inaudible], it seems to be a good effort.   JAMISON:  So, there were a couple of security issues recently that I’m familiar with. I was wondering if you could maybe talk about how they were handled and if there’s anything that could have been improved in the way they were handled. Because I don’t know all of the grimy details and stuff. I don’t mean to spill the dirt, but just how to improve things.   ADAM:  Sure.   JAMISON:  One of them was the recent Node 0.10.21 release. It had…   ADAM:  Denial of service, right?   JAMISON:  Some kind of HTTP vulnerability fix, yeah. And they didn’t really say what it was. They just said, “Hey ,you should really update and someday we’ll tell you what it fixed.”   ADAM:  [Chuckles] Yes.   JAMISON:  And the other one, I think a couple of months ago, wasn’t there a connect vulnerability?   ADAM:  Yeah.   JAMISON:  I don’t remember the details on this. Did you want to talk about those and about how, what good ways you’d use them as examples to talk about ways to handle Node security?   ADAM:  Sure. So, the Node core one I think could have been handled better. So what it was is there was a denial of service vulnerability and what 0.10.20, I think 21.   JAMISON:  21 was the fix.   ADAM:  Or no, 21 was, this release contained the security fix. Yeah so, 21 contains the fix. And what happened was that basically there was a security announcement and it didn’t have as much detail as it should have. I feel it should have been, “Hey here’s our release. Here are the details about the vulnerability. Go patch.” The thing is what happened was that the tests were there to reproduce the condition and the details and the notes were not. So immediately, everyone says, “Well the tests are there. I’ve got basically full disclosure right here.” And I believe a [inaudible] module was created for it pretty quickly. And I think it should have just been well-timed, we’ve got all our details, an announcement goes out to the security mailing list, the release goes out, and then it’s an arms race at that point.   But you have the security announcement list for a reason, right? There’s a place where we can strive to get knowledge about those. An announcement could have gone out on that at the same time giving all of the details that talk about the impact of the vulnerability. They don’t have to talk about how to exploit it. So that’s an important piece too, is you want those releases to not create more vulnerability but just give enough details that a business can make a decision about urgency in upgrading.   JAMISON:  So, you don’t think that they should include the steps to reproduce the vulnerability?   ADAM:  Not in the initial release to reproduce it. But I think that that should be disclosed afterwards. That’s just my opinion. People are going to reverse engineer that out of the code anyway. So it’s kind of a six of one, half of the other.   JAMISON:  Sure.   ADAM:  So, that was the Node core thing. I think that that was a lesson. There was a lot of heated conversation on Twitter, if you can call it a conversation.   JAMISON:  [Chuckles] I don’t know if you can. [Chuckles] Lots of yelling.   ADAM:  Yeah, about, “You should have done this better,” and whatever. And I think that core does a good job of filtering out the BS there and taking the proper criticism to heart and working on future releases right. And I think that we don’t have to reinvent the wheel. We’ve got open source projects that have release processes that do this all the time and do it well. And we should just adopt that model and just continue with it. So, there’s that.   JAMISON:  Sure.   CHUCK:  One thing that I’m curious about and this may be a little outside of this, since you’re focused around the libraries that are there. But I wonder a little bit about let’s say that I have an application that has a security vulnerability that I discover. What process should I have around that for disclosing and letting my users know and whatever?   ADAM:  I am of the opinion that if it’s your product, your application, I’m of the opinion transparency is best. And especially with breaches or vulnerabilities. Different people have different opinion on this. I vote for transparency and talking about, “Hey we’ve updated things where we discovered security vulnerability. We did the research. It was never exploited.” If you can’t determine that this particular issue was never exploited on your servers, you’ve got bigger problems than your operational procedures that you need to be able to ask those questions and understand how to tell if that was exploited or not.   But I think transparency’s the way to go here. Write a blog post, notify your users. But that’s just me. I think that it wins over trust versus having a problem getting exploited, not understanding that situation, then getting called out on it afterwards, basically getting busted to sort of keeping something a secret. I don’t know. It’s happened. It usually gets uglier than just being straight up.   JAMISON:  It’s such a delicate issue.   ADAM:  Yeah.   JAMISON:  Because I feel like I can understand arguments from people that want to keep them very secret. But at the same time, it’s risky. If people find out, they feel betrayed. I feel like that’s’ how I felt as a consumer when all the Sony stuff came out where it just kept getting worse and  worse and worse.   ADAM:  Yeah.   JAMISON:   I was like, “Man these guys are jokes.”   ADAM:  And the hard part of having a vulnerability is not a bad thing. And sure, in some sense it is. But not learning from that mistake, that’s the sin that’s worth paying attention to. And if you continue to have repeated offenses to a similar thing, that’s more impacting to me as somebody’s using your service or your product, your software than just having a single vulnerability, I think.   JAMISON:  Do you think that security announcements should talk about how this came to be? Should they talk about systematic things like that? Or should they just talk about the bug itself?   ADAM:  I’m not quite sure I’m with you.   JAMISON:  So, in the Node core example you mentioned a better thing to do might have been to disclose the effect of the vulnerability so that people could decide how important it was to spend no time upgrading. Should they do a postmortem in that same place?   ADAM:  I don’t know. I don’t think they [inaudible] in the same place. But I think that using those, bugs are alerting opportunities, right? And a security bug is the same type of situation, just handled with a little bit different delicacy. I think that a postmortem should be done on a process, doesn’t have to necessarily public unless there is some kind of large mistake. It can be done via mailing list or it can be done via the core team talking to one another. But I think a postmortem should be done if there’s a large consensus that, “BS. That was completely F’d up.” If there’s community backlash on it, it definitely should be talked about. It should be transparent. And something should be done to either fix it or whatever.   JAMISON:  Sure. That makes sense.   ADAM:  I don’t know. That’s just my thoughts.   CHUCK:  So, what kinds of things are you looking for generally when you audit or evaluate an npm module?   ADAM:  So we started with, like I had mentioned, childProcess.exec. We’re looking for untrusted user input put into childProcess.exec which creates shell execution. That was the first one we looked for. And we found a surprising number of those. And now we’ve moved on to things like regular expressions that are denial of serviceable, cross-site scripting, unsanitized variables, and EJS templates or JTemplates, things like that.   AJ:  What do you mean regular expression that’s deny, service, blah, blah, blah?   ADAM:  Denial of serviceable?   AJ:  Yes.   ADAM:  So, there’s a type of attack called ReDoS and I’m absolutely horrible at explaining it. It’s where you basically have, I believe the best way to describe it is when you have a large number of back references. And I can post a link.   JAMISON:  Don’t you basically make it go into a pathological case where it just spends forever processing the regex?   ADAM:  Right. That’s basically the case where you’ve got a whole bunch of, there’s a specific situation. I can’t remember the right wording. But yeah, there’s probably a site. Oh yeah, an OWASP link is probably better at explaining what it is. We can post that up there for the listeners here. But you end up getting stuck in a non-optimal pattern and it just takes a super long time to resolve. And it will eventually get there, but you use a lot of resources for basically one request. So, [inaudible] have a route handler that if you use regular expressions to setup for route matching or something, you do a poor job of writing one of those and you might be able to with a single GET request consume a lot of server load. So, that’s one example.   JAMISON:  That’s really interesting. I knew that regexes could do that, but I guess I just never thought about using it to attack a server. I mean, parsing strings is the core of what lots of server stuff does to route URLs to functions and stuff. That’s really interesting.   ADAM:  Yeah. Usually, it has to do with -- a lot of modules usually just say, “Hey, just give me a regex here and I’ll do a thing.”   JAMISON:  Sure.   ADAM:  And so oftentimes, we have a problem with that because it’s how you use it so we can’t really do anything about that because we don’t see the private applications that are using this building block. So it was kind of frustrating.   AJ:  So the basis of it is if you have a repeating group. That’s where you can become vulnerable to this.   ADAM:  Right.   AJ:  So, if you don’t have a group that has a repeater on it, then you probably don’t have vulnerabilities to this? Is that accurate?   ADAM:  That is accurate from what I know. And substack has a module called safe-regex. It’s not perfect, but if you put a regex into it, it will spit out basically if it thinks it’s safe or not.   AJ:  So, that’s something like JSLint could probably look for, too, right?   ADAM:  Correct. I’ve got an ESLint, ECMAScript Lint module or plugin that does that. I tried to patch JSHint and I got lost.   JAMISON:  [Laughs]   ADAM:  So, I didn’t do that.   JAMISON:  Are there common kinds of errors that you see at the app level, not at the module level? Or are you not really focused on those kinds of things?   ADAM:  Yeah. So, those are the things I do during my day job at ^lift.   JAMISON:  Oh, okay. So, you are an expert on those things?   ADAM:  Well, that’s basically what I do, is we do penetration testing, right? So the common things are the OWASP top ten. You link to OWASP. Those are the common things for a reason. Those are the things we see not just in Node land but in Rails and PHP and Python/Django, whatever. We see those mistakes being made and those are the most common thing out there. Cross-site scripting, cross-site request forgery, SQL injection which is becoming less common in a lot of applications because they’re not using SQL anymore, they’re using Mongo or some other key-value store or whatever. They’ve got their own injection problems. They’re just different.   CHUCK:  I’m a little curious though with PHP and Django and Rails and a lot of these others. We’re talking about web languages and web frameworks here. But do you find that their maturity leads them to be maybe a little bit ahead of Node in some of these areas? Or is Node mature enough now to have solved most of these problems as well?   ADAM:  I sort of go against the grain in the Node community when I say that I don’t think frameworks are bad. There’s a common thread in Node, small modules do independent things. And I think that’s good. And then we stay away from frameworks. But frameworks itself, you take a bunch of those modules, you put them together, you make these opinionated decisions for the end user, and then those mature over time with good security decisions. So I think that Django and Rails, I think those are good things.   I think that those, it does not necessarily make them more mature than Node, but if you compare say Rails to Express or Rails to Sails.js, they’d been around longer. And so hopefully, these frameworks in Node can learn from Django and Python or Django and Rails and some of those. But we’re seeing the same type of issues crop up. And that makes sense.   JAMISON:  That does make sense. I feel like it does a little bit of an apples to oranges comparison if you’re talking about Node to Django.   ADAM:  Yeah.   JAMISON:  You could talk about Node to Python, maybe. You write code for Node, you write code for Python.   ADAM:  Exactly.   JAMISON:  Node isn’t really a web framework.   ADAM:  Right.   JAMISON:  So, there were still some vulnerabilities in, there was a Ruby one a while ago. There was the Node one we talked about. So, the core language can still have problems.   ADAM:  That’s the interesting thing, is that the core, there was a vulnerability in core that response splitting where you can get headers from the request or whatever output into the body. And that was in a core lib. It was in Node because it was in the core, but the core HTTP module could just as easily be broken out in user land. So JavaScript is still the core language in Node. I don’t know. It’s an interesting apples to oranges sort of comparison you have to deal.   JAMISON:  You could argue that since the effort in Node seems to be more focused in people rolling their own things, there’s less wood behind more arrows type of thing. I guess you could argue that that might lead to more vulnerabilities in the specific frameworks.   ADAM:  I think rolling your own is typically, and you’ve mentioned it earlier, I think that that’s another plus for frameworks. Not everyone’s the right person to write an auth framework for their app or a cross forgery token generator and dealing with all that. Those things have been written and done and why not use one that somebody else has written? The problem that you have is that you’re going to go npm and you’re going to pick a module off the registry that maybe somebody else wrote that was also not the right person to write the thing.   AJ:  So, that becomes a question of curation.   ADAM:  Sure.   AJ:  Does the number of stars on Gittub and the number of downloads per day mean that it is a good module or does it mean that it was marketed well?   ADAM:  It means it was marketed well, yeah. I don’t think stars have shit to deal with when it comes to code quality. [Chuckles]   AJ:  So, what do you think about some sort of effort of curating modules? Like for example, you take some really popular modules that everybody uses, manually lint them for security errors, and pull them into like npms or something like that.   ADAM:  Right. So, that was an interesting discussion I have early on with some of the Node core people, was that anarchy in Node land is good in terms of best module wins. But I think we can lend as the Node Security Project some metadata to that decision. The thing is I’d rather see that solved. I don’t want to maintain a moderated list of modules to use because it’s so subjective for the use case that you’re going to use them, I guess.   And I’d rather see somebody else. Because if a maintainer falls off and stops maintain something, well then another module’s going to come in and take its place and it’s just a giant weight to bear for curating those things. I think community pretty much sorts it out, but it is a problem and I don’t know if there is actually a solution.   CHUCK:  So, that kind of leads me to another question. Because you find a security issue in a library and you send pull requests and you do some disclosure and things so people know about it. What do you do if you can’t get the maintainer to actually fix it? So for example they have disappeared or they’re busy or they’ve just abandoned the project or whatever.   AJ:  Or they hate you.   JAMISON:  They hate you.   ADAM:  Yeah well, I’ve been told that already.   JAMISON:  Or they’re the NSA and they want it to be vulnerable.   AJ:  [Chuckles] Right.   ADAM:  Yeah, there are people that do not like the Node Security Project and I will not call them out by name. But they are very prominent in the Node community.   JAMISON:  What are their objections to it?   ADAM:  They say that it actually creates more vulnerability by doing disclosures and things like that.   JAMISON:  Isn’t that kind of the age old battle in security?   [Chuckles]   ADAM:  Yeah, it is. And so basically, we’re just… So to answer that is we do not release an advisory about a module without a patch.  We haven’t run into that situation yet. But let’s say it was something extremely serious in a popular framework. Let’s say it was a popular web framework and we found something very serious and the maintainer just basically gave us the finger and said, “No, I’m not going to fix it.” Let’s say it can remotely execute code on the server or something. If it was very serious, I feel that it would get enough publicity to force the issue in the community to make a decision to either force push on their project which would be a political nightmare.   But I think that that would be a situation that may occur. The other thing is if we release an advisory, we at least have a patch attached to it and people can apply that themselves. We wouldn’t release without basically a pull request diff of some kind at that point.   CHUCK:  Are you concerned at all that that will get you into the area of having to maintain the patch?   ADAM:  Yes, that is an issue. But yeah, we haven’t had to deal with that yet [chuckles]. So I’m just stretching for making things up because we haven’t had to deal with that yet. So I haven’t put a whole lot of thought into it.   CHUCK:  Interesting.   ADAM:  Hopefully, we don’t.   CHUCK:  [Laughs] Yeah.   ADAM:  But I think that we’re going to, eventually.   CHUCK:  Well, I think we’re all hoping that for your sake.   ADAM:  [Laughs]   CHUCK:  So yeah, does it concern you at all that you’ll make a disclosure, people will use the unpatched version, and then get exploited because of what you’re putting out there? I come down more on the side of make the disclosure and hopefully it gets fixed. But I am curious about the other side of things.   ADAM:  So, the point is that we want to offer low friction for package maintainers. So the goal is to provide disclosure to the package maintainer. If we can provide a pull request or a patch for them, they can implement it. And at that point, if we do a disclosure with patch and they haven’t accepted it yet, I feel that the community will sort that out in terms of rolling that in. If there is enough vulnerability behind it, I think that there’ll be enough pressure to, the community will adopt said version with patch and then it will take over from there. I don’t know. It’s a tough call. I’m sure other communities have to deal with it. I haven’t really looked and research into how that’s been dealt with in say RubyGems or anything like that.   JOE:  You could also use this to squash your enemies.   [Laughter]   JAMISON:  Oh, man. Good thing Joe’s not the head of the Node Security Project.   JOE:  Or the NSA.   CHUCK:  [Laughs]   JAMISON:  Well, yeah.   JOE:  Because the guy in charge of the NSA would never do that.   ADAM:  Never. Lots of integrity.   JAMISON:  I trust him. He looks great. I think he’ll do a great job.   JOE:  Yeah.   [Laughter]   JAMISON:  Full confidence.   JOE:  When did we become so political?   ADAM:  I don’t know. [Inaudible] out.   JAMISON:  Two minutes ago. [Chuckles]   AJ:  So, what about utilizing all this for education for developers and stuff like that? You talked a little bit about that before. But is there some idea of really consolidating this into educating, getting good education? Because I’ll be honest, I think that by large a lot of the mistakes that are made now are the same mistakes that were made 10 years ago.   ADAM:  Yup. And we aren’t learning a damn thing. [Chuckles] And have of it is mistakes and half of it is we’re just not learning. We’re like, “Ooh look at this green field over here. It’s Node. Tromp, tromp, tromp. Let’s ride all over the thing and not bother to look back.”   [Laughter]   ADAM:  Yeah, so I don’t know. Yes, education is a huge component of this and it’s part of where I wasn’t thinking initially. I was just thinking initially, let’s audit things. Let’s disclose them. Let’s fix them. Write a blog post and education will come from there. Well we’re making education a piece of the audit process now. But we hope to consolidate. Because the Rails has the Rails security guide which has some stuff around what you should do.   And hopefully we can take some of the knowledge from other communities and stick them in a Node-specific, “Hey you’re in JavaScript land. Here are some examples for you,” rather than when you say go into the OWASP top ten you’re going to get examples about PHP and Java and nobody gives a crap. So we need examples that are relevant. So yeah, I agree.   CHUCK:  So the other question I have then is like with the Rails security guide, a lot of it is “Don’t turn off the built-in security features.”   ADAM:  [Laughs] Yeah, just don’t do that.   CHUCK:  So is there any of that with Node or maybe an npm module or two that you can actually go in and say, “Use this because it will actually turn on a bunch of stuff that you ought to be using.”   ADAM:  Yeah. So as an example, Express. You have to turn on cross-site request forgery protection. It’s not a default. Shameless plug, there’s a library called helmet for Express that turns on a bunch of security headers. And you just get those for free then. But there are a lot of things too, like Jade automatically escapes, at least for HTML context, variables to help preventing cross-site scripting. So that’s a good thing. Don’t turn that off.   But when you do that and a template is rendered, there’s no warning that gets crapped out that says, “Hey, you’ve got an unsanitized template variable, bad [inaudible],” or something. Secure by default’s a big thing and I think that we should be turning that on, especially in frameworks we’re creating. I think the Sails guys, Sails.js have that mentality and I think that they’re doing some cool stuff there. I think Express could shore up at some of that stuff.   Hapi framework from Walmart is awesome. Eran Hammer that runs that team goes so far as to even the examples that he tries to publish he does things like proper bcrypting of passwords and not just doing some shitty example. He really wants to get people doing the right things and so he’s going, taking it that far as documentation and things like that. I have to have good examples.   AJ:  That’s awesome. And that’s the first time I ever heard anybody say anything good about Walmart.   [Laughter]   ADAM:  Walmart Labs. Walmart Labs, they’re doing some awesome stuff, Eran and team.   AJ:  That’s good, looks cool.   CHUCK:  Yeah. Cheap stuff, I like Walmart. There that’s a good thing said about Walmart.   JAMISON:  We got to talk about your stickers. We can’t talk about the Node Security Project without the sweet, sweet stickers. Those are amazing.   ADAM:  Thanks.   JAMISON:  Did you come up with the stickers before you had the security project?   ADAM:  Yeah.   JAMISON:  Did the stickers lead to the security project?   ADAM:  No. Actually, I made a Twitter account. That’s one of the first things. And I took, the Node logo, the green logo and I stuck a lock on it. And that was the first iteration. And then one of our designers, Adam Brault here saw it. He was like, “Let’s make it blue.” So, we made it blue. And that’s how it stuck.   JAMISON:  It looks good.   ADAM:  And of course, it’s… I like it. We decided not to put any words on it or anything like that. People seem to really like it somehow. Thanks. It’s cool.   JAMISON:  You said before the show that putting a lock on stuff makes it secure. So that’s how you know.   ADAM:  Yes. It’s like the little locking [inaudible] in your browser there. So, if it’s there, it’s more secure.   JAMISON:  Or like the sites that just put an image tag with a lock in it.   ADAM:  Yeah, it’s more secure then.   JAMISON:  Super secure, yeah.   ADAM:  So nobody will mess with your laptop, you just stick one right on the front. It’s locked down.   [Laughter]   CHUCK:  That’s right. I need a lock sticker for my laptop.   ADAM:  Yeah, exactly.   JAMISON:  So just to reiterate, the best ways to get involved are to jump into that API repo if you want to help develop stuff?   ADAM:  API repo, follow me on Twitter.   JAMISON:  Is that the only place you’re really looking for help right now?   ADAM:  Yeah. So once we get that shored up, which is pretty far along, then we’ve got to get the frontend piece going which will talk to the API of course. And the David DM guys have been helping quite a bit on the API when they can because they want to consume it as well for say, “Here are your out of date modules. Also, these ones have known security issues,” which will be a cool side effect of the project. So yeah, you can jump on IRC. I’m not very responsive but we’ve got a couple of other guys from the team.   JAMISON:  What’s the IRC channel?   ADAM:  It’s on freenode and it’s just #nodesecurity.   JAMISON:  Oh, cool.   CHUCK:  How am I ever going to remember that?   ADAM:  I don’t know. [Chuckles] We make it difficult.   CHUCK:  Yeah, why don’t you just call it what it is?   ADAM:  #nodesecurity stickers. No, that doesn’t [inaudible].   JAMISON:  [Laughs] Not yet.   CHUCK:  So you kind of talked about the point behind a lot of the stuff that Node Security is about. Where do you see it going moving forward?   ADAM:  Going forward, basically, I’ll stop talking about it all the time and actually do more work on it [chuckles] which is, I’ve just been talking about it nonstop it seems. But going forward, I’d like to see it get some integration into npm and just keep refining our process to keep trying to make the ecosystem better, the Node community better, and push education and meet some of our ocean-boiling goals.   CHUCK:  Awesome. Alright. Well, if people want to learn more about this stuff or get a hold of you, what are the best ways to do it?   ADAM:  Hit me up on Twitter @adam_baldwin or @nodesecurity on Twitter. Or hit us up on NodeSecurity.io.   JOE:  If you just google Adam Baldwin, that’s you, right?   [Laughter]   ADAM:  Yeah, certainly. I was on Chuck and Firefly.   JOE:  Yeah, my most important question is, do you like Firefly?   ADAM:  So, I have a confession to make. I had not actually seen it until this last year.   JOE:  [Gasps]   ADAM:  And yeah, I get just the nerd gasp.   JOE:  Blasphemy!   JAMISON:  [Laughs]   ADAM:  So, I was previously content not having watched it and then I watched it. And then I’m all kinds of pissed off.   [Laughter]   CHUCK:  All kinds of pissed off.   JAMISON:  Does that mean you don’t like it?   CHUCK:  Because that guy stole your name?   ADAM:  No, because it’s over. And it was great.   CHUCK:  Yeah.   JAMISON:  Oh.   AJ:  You’ve seen the movie too, right?   ADAM:  Yeah, I haven’t watched the movie yet. I’ve heard I get closure from the movie.   JAMISON:  The movie’s great.   CHUCK:  Some. You get some closure.   ADAM:  [Chuckles] But I have exchanged tweets with Adam Baldwin. So, I guess that’s my link to glory or something.   JOE:  That man was born to play that role on Firefly.   [Laughter]   ADAM:  That’s so great.   CHUCK:  There’s really nothing else to say to that?   JOE:  No.   ADAM:  Yeah.   JAMISON:  My sister knitted me a hat, Jayne’s hat for Christmas.   JOE:  [Gasps] No.   JAMISON:  It was a couple of years ago. I wear it snowboarding and I feel super cool.   ADAM:  That’s great.   JOE:  It is.   JAMISON:  Yep. So, before we go, does ^lift support you in this or do you just do it on your own free time? Or sorry, ^lift Security. I feel like there’s, isn’t there another company named Lift?   ADAM:  There’s an app.   JAMISON:  Yeah, I thought that you were the same thing for a while. I was really confused that this app company would also have a hardcore penetration testing team.   [Laughter]   ADAM:  Yeah, so…   JAMISON:  Man, that’s one secure chat app.   [Laughter]   AJ:  Lyft is for taxi, the mustache taxis in San Francisco.   JAMISON:  There’s also a Lyft with a Y.   AJ:  Yeah, that’s the one. That’s the mustache taxis in San Francisco.   JAMISON:  Oh. Well anyways, yes.   ADAM:  We get confused for since it’s ^lift. It’s either caret lift, up lift.   JAMISON:  Yeah.   ADAM:  Yeah, there are all kinds of variance. So ^lift is a department if you will of &yet who makes web apps. So they make web apps. We break web apps.   [Chuckles]   ADAM:  And it’s basically just, we’ve got a very small team here. So I’m the lead of ^lift so of course ^lift supports us because that’s basically what I do. So yeah, ^lift gives me some time to do that and &yet basically sponsors it. ^lift organizes it. And it’s community driven.   CHUCK:  Very nice. Well, that’s cool. We’re looking forward to seeing where this goes in the future and all of your community contributions. Thank you so much for putting in the time.   ADAM:  Oh, you’re welcome. Thanks for having me on the show.   JAMISON: I’m super excited about this. I think it will be fun. And I also have the secret selfish desire to learn more about security. I know just enough about security to know that I’m bad at it.   [Laughs]   ADAM:  That’s okay. So am I. But we can do better.   JAMISON:  [Laughs] Awesome.   CHUCK:  Alright. Well, let’s do the picks then. AJ, do you want to start us off with picks?   AJ:  Yes I do. First off, when Adam mentioned that he was from Washington State that reminded me of how I used to live close to Maine State and this Canadian Border Patrol video. I don’t know what it is. It’s like a Saturday Night Live skit or something but it’s hilarious, at least I think it is. Any time you’re making fun of Canadians, it’s a good time.   [Chuckles]   AJ:  It’s basically what Americans live for.   CHUCK:  Yeah, it’s hilarious, eh?   AJ:  [Laughs] That shouldn’t have been so funny but it was.   And second, I’m going to pick Frozen and the Frozen soundtrack. Frozen was a good movie. I don’t think it was as good as Tangled. Some people think that it is. Olaf the snowman is an amazing character. His song pretty much makes the movie. He says something like, “The winter time is good to find someone and cuddle, but in the summer time I will be,” and then you expect him to say a puddle but instead he says, “A happy snowman.” And the songs are just cute and fun. And you can listen to them on Spotify, including songs that they produced that are like beta quality. What do we call that in non-computer terms? Rough draft? First cut? I don’t know. But they’re songs that never   JAMISON:  B-sides? Demos?   AJ:  What?   JAMISON:  B-sides or demos.   AJ:  Demos, yeah.   ADAM:  B-sides.   CHUCK:  Count on Jamison to know the music terminology.   JAMISON:  [inaudible] there are no B-sides.   AJ:  Thank you, Jamison.   JAMISON:  Hey, I was in a crappy band in high school. That gives me authority forever on music.   AJ:  That’s right. You probably did that before 2004, huh?   [Laughter]   JAMISON:  I sure did. Shout-out to our last episode. [Chuckles]   AJ:  Isn’t that our next episode?   JAMISON:  Oh, shoot. Next episode.   [Laughter]   AJ:  Time warp. Anyway, so they also have songs that weren’t included in the movie that are cool songs that also follow alternate plotlines. Apparently, they did the music before they finished the storyline. And so there are some songs that give this window into what the movie might have been. I’m still listening to it. So yeah, I’m going to pick those things. Picked.   CHUCK:  Alright. Joe, what are your picks?   JOE:  Alright. So, my first pick is the musical group Forte. It’s a trio of tenors that was on America’s Got Talent this year. And they just put out an album. It’s available on Spotify. And they are just absolutely fantastic. I feel like I’m listening to The Three Tenors. They’re just totally amazing, love listening to them while I work. So, I’m going to pick them.   I’m also going to pick the MLS Live subscription service which is something I’ve picked in the past. And it’s a subscription service where you can watch every soccer game played during the MLS season but you can watch a condensed 15 minute version of it, so all the really cool action for every game played every week. Of course, the season doesn’t start until March but right now until the end of the year, they’re offering a 20% off. So I figured I’d mention that.   My last pick is going to be a shameless plug. My latest Pluralsight course on Angular for .NET developers released today. And so I’m going to pick that it was a fun course to produce and it’ll be fun to get the feedback from that as well.   CHUCK:  Awesome. Jamison, what are your picks?   JAMISON:  I just have one because it’s kind of a giant one. I just found this blog called Aphyr.com. I don’t know how to pronounce it. It’s by Kyle Kingsbury who’s a distributed systems guy. And that’s a big word that I’ve always wanted to learn more about. He has this series of blog posts called Jepsen. I think that’s the series. He gave the title of something. I don’t really understand it. But anyway, it talks about distributed systems and it walks through a ton of different databases and shows you how they all react to network partitions or to just all the weird things that can happen in distributed system. And it’s amazing. It’s mind-blowing to me because I learned more about this stuff. So that’s my only pick, just this series of blog posts.   CHUCK:  Awesome. Alright, I’m going to throw out a couple of picks. So, my first pick is something that I just picked up from the Freelancer Show about an hour ago but it’s pretty funny. And it’s ClientsFromHell.net and there are some pretty good ones in there. If you’ve followed the last couple of weeks of my life, you might understand. Anyway, funny stuff. I’ve also been listening to this Shark Tank book. I don’t know if you guys are familiar with the Shark Tank TV show, but basically the idea is that entrepreneurs go in and they pitch their business to these investors who are kind of self-made millionaire/billionaire entrepreneurs.   And they all got together, the entrepreneurs that contribute to these businesses or invest into businesses, they got together and wrote a book together or had somebody write the book and then gave their feedback or input to it. And it’s pretty good. It’s just general how to build your business advice and they’ve got some stuff in there for different business models and things like that. So I thought it was pretty good. I’m about halfway through it and I’m really enjoying it. And anyway, those are my picks. Adam, what are your picks?   ADAM:  Let’s see. You guys got all kinds of interesting stuff so I’ll have to come up with something here. Of course, I’ve got to talk security first, right? A great book pick I think would be The Tangled Web by Michal Zalewski. It covers a lot of the stuff like we talked about, historical things and things coming up that you should know about in terms of security.   And then I’ve got a couple of shameless plugs for the team here. One for Talky.io which basically you can go to Talky.io/whatever and you both end up in a web RTC video/audio call, no plugins, no hassle. It’s fun, super easy.   And the other shameless plug would be for Human JavaScript. One of my teammates Henrik Joreteg wrote that. And I think that it’s, I’m no frontend JavaScript developer and it’s helped me understand how to build and how to maintain and construct single-page apps on the client side in the same way. So those are my picks.   CHUCK:  Awesome. Alright, well…   JAMISON:  Oh, I forgot one pick. I got one more plug. I’ve got to plug it again, MountainWest JavaScript Conference. It’s really cool.   CHUCK:  Yeah, please come. I want to meet you and Jamison does too.   AJ:  I was expecting Mountain West Burrito.   [Chuckles]   JAMISON:  No, I don’t pick local restaurants because I don’t [inaudible] listeners to go to Mountain West Burrito. But anyway, yeah the deadline for paper submissions I think or presentation submissions is the middle of January sometime. There’s still plenty of time to submit. We want to hear from you, especially if you’ve never talked before. It will be a great way to get your feet wet. And it will be awesome, so come.   CHUCK:  I thought the call for proposals -- did you say call for proposals or ticket sales?   JAMISON:  Call for proposals. Did I say a lie? Is it closed?   CHUCK:  I think it’s through the end of the year.   JAMISON:  Oh, well. Cool, there’s still time.   CHUCK:  They close Saturday, January 4th. So, there’s the official word.   ADAM:  So, that’s what you can do over the New Year’s.   CHUCK:  Yeah, write a proposal. And if you want to hear about something and don’t want to speak about it yourself, I am looking for some ideas because I’d like to speak at that one since it’s local and stuff. So if it’s something that I might know about, tweet me.   Alright. Well, let’s go ahead and wrap this up. Thanks for coming, Adam.   ADAM:  You’re welcome. Thanks for having me. It’s been fun.   JAMISON:  Yeah, it was great. Thanks for coming on.   CHUCK:  And thanks everyone for listening. We’ll catch you all next week.  

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.