I'd like to work on the security best practices section. Apart from independent modules/npm solutions already stated in the main README what do you think would be further important aspects? I think of adding important tips for the crypto core module first.
Oh and if somebody is already working on it we could share some ideas here
I've added a security guideline for comparing objects timing-safe using default Node.js functions
@BrunoScheufler what ideas we have for other security bullets? can we fill a section of ~7-10 items? have friends with a security-related startup, maybe join forces and ask them to write come or consult?
@i0natan that would be awesome! I thought of maybe adding guidelines to prevent access tokens or db passwords to be pushed to the internet but rather using tools like dotenv. They can join and help out of course!
How about a stern warning about new Buffer(...)?
So although this is important, constructing Buffer objects is explicitly marked as deprecated in the Node.js docs for some time now. I am not entirely sure whether we would need this as a best practice, @i0natan what would you say?
I also thought of maybe adding a description and possible solutions against directory/path traversal attacks for node web servers. Although this is against 5.11, so I'd like your opinions on this @i0natan @idori @refack before I start preparing the detailed section.
@BrunoScheufler take the lead on that list.
Time-wise we won't publish it the next 3 weeks as we just uploaded a mass content and should focus on improving it. Take your time to gather at least 7-10 items from multiple sources (blogs, youtuve, NPM packages) and once we're ready with a comprehensive list - let's push forward toward publication.
Makse sense?
@i0natan totally, also takes out some pressure 馃憤 . I'll wait and look for good items internal (so in this repository through issues and other community interaction) and external by looking at some common risks
Maybe we can create a branch and work on it together.
I can think of a few topics that are security related (other than the one mention in issue #51)
There are probably a few more but that's just from the top of my head.
Yeah we could totally do this! I'll create a branch for us to work on and push to, later when I've got time!
@yonjah I've also thought about these. So for the crypto best practices I've already prepared a section about timing safe equality comparison using the crypto core module. We could share the other ones and work on them together!
Hi Guys, Here is one suggestion for NPM package: helmet. Helps with many topics which come up in tool based security reviews.
Also here is one blog post which goes into details on some topics listed by @yonjah. Hope this helps a bit in your research.
So I've created a branch for the initial security best practices. This will be merged and deleted later on when the most important content is integrated into the section. All security section updates via pull requests should be made into this branch.
I have some suggestions, I'll probably have to find articles or write my own on SSL and crypto. Let me know if anyone already started.
Not a fan of helmet but I can cover why :)
Just cover the things you want to 馃憤 Also it would be good to mark what each one of us is working on and don't switch topics on the fly so we don't work on the same topic!
@BrunoScheufler we shall publish improvements milestones soon with a timeline, 'security' seems beefy enough to be released soon
@i0natan a timeline with milestones would be good, the question would be which points we could do in a timely manner, when do you plan on releasing the security section?
Perhaps some info on implementing a content security policy?
@snypelife that would be a good addition to the XSS prevention guideline for the top OWASP attacks!
I'll start off with the crypto best practices for now. Is anyone else already working on a point? Just for organizing this milestone.
You may consider few items from this list as well:
https://blog.risingstack.com/node-js-security-checklist/
@i0natan that's a really good resource! Some points mentioned in the post are already listed above, but we can try to add the other ones too.
鉁旓笍 Security-related headers are added to the security section
鉁旓笍 Best practice for using HTTPS with Node.js is added too
@BrunoScheufler about the content, I would like to make the following changes, let me know what you think:
6.12. Avoid eval statements with unsanitized inputs to avoiding eval statements with user input, or avoid all eval function invocations with any variable altogether.6.6. Hide 'X-Powered-By=Express/Koa/etc' headers and push it to the generic 6.14. Using common methods to secure your application section@lirantal 6.12 - absolutely makes sense
6.6 - I just afraid that if we push any minor/cross-platform advice under the generic bullet will end up with very few tips. So I thought that (A) any advice that has Node interpretation (e.g. X-Powered-By=Express) where we can provide some insights how it should be implemented in Node -
should get its own bullet and (B) any advice that has no Node interpretation (e.g. use VPN) should be located in the generic bullet
These are just my thoughts, we can adjust this
@lirantal I'd also agree to rephrase it to avoiding eval in general
We'd all have to agree which points we classify as generic advice and which we use as Node.js-specific points
@BrunoScheufler I'll begin pushing a PR soon with some changes and we can collaborate on it then with the relevant context, it should be easier.
@i0natan don't worry, there is going to be enough content :-)
the server fingerprinting advice for express is really generic and common sense. It's one of these things that is obvious and you would like to cover more important items instead of it.
Let's do this - I will add items on top of what we have today without making any changes, and then we can review what to group and how.
@lirantal awesome, I'm on a trip right now, will look into it occasionally though!
@lirantal sounds great
@lirantal @BrunoScheufler what do you think about sharing the current draft with the community (not a mass campaign, just share in few forums) to solicit feedback and ideas for other bullets?
@i0natan We could at least create some links to the upcoming changes (for example link to the security-best-practices branch in the ToC) for users to get an impression of the new section. Would be the question whether we share the section on social media and places alike.
I'm good with a fast feedback loop 馃憤
Adding more 'inner content' for the rest of the bullets would be a great enhancement.
@BrunoScheufler let's do both.
Let's share the current branch link (direct link to the security items) in few FB/reddit groups + Twitter?
@i0natan sounds good! This way we can pull in feedback from other readers and maybe excite new people about the project!
@lirantal @BrunoScheufler to differentiate ourself from few security practices lists on the web, would be great to add 2-3 bullets more. Currently, our list contain ~2-3 items that don't exist in common list. Any ideas? scan base docker images? replace bcrypt with argoni (see link)? install NPM without sudo?
I'm not sure about those options as they are very generic and I think we already have variation of the sudo thing on the list already.
Hopefully will come up with some more soon.
@lirantal @BrunoScheufler see here:
https://www.reddit.com/r/node/comments/7xrpj8/20_node_security_best_practices_draft/
I would embrace the idea about error handling
Yep, saw it and that's indeed a good advice, but it again falls on the border of being true for every language and platform, not unique to Node.js. Maybe we can tie it up to express generic error handler and this way to connect it to the story.
Most helpful comment
@BrunoScheufler I'll begin pushing a PR soon with some changes and we can collaborate on it then with the relevant context, it should be easier.
@i0natan don't worry, there is going to be enough content :-)
the server fingerprinting advice for express is really generic and common sense. It's one of these things that is obvious and you would like to cover more important items instead of it.
Let's do this - I will add items on top of what we have today without making any changes, and then we can review what to group and how.