security-wg
security-wg copied to clipboard
nodejs
What security guidance would be most useful for Node.js developers?
Background
Currently the Guides section of the Node.js documentation does not have any documentation around security. I think it's fair to say that such guidance would be a useful and welcome addition to the documentation.
Based on my experience there are two target groups for such guidance: programmers working on Node.js applications and application security engineers supporting Node.js applications. I think the focus here should be on the first group.
The second group already has a very useful resource in the form of Node.js Security Roadmap. See #101 for background on this document.
This issue was inspired by #478.
Expected outcome
I would like to use this issue to solicit input both from the Security Working Group as well as from the broader Node.js community. An ideal outcome would be a list of security aspects to take into account when writing Node.js programs that we could turn into guides or a set of guides on the Node.js website.
Scope
Ideally, the guidance should be limited to the JavaScript programming techniques, the Node.js runtime and its core libraries.
How to move forward
If you have an idea, describe it and post as a comment under this issue. If you like an already existing idea, use 👍 to express support. This way we can gauge the demand for guidance on a given aspect.
Idea 1: Managing dependencies to minimize the attack surface and make upgrading vulnerable dependencies a manageable problem.
Idea 2: working with regular expressions to avoid Regular Expression Denial of Service (ReDoS) attacks.
Idea 3: working with filenames and paths in a secure way to avoid Path Traversal attacks and similar.
Idea 4: logging the errors to log management and preventing complete stacktrace printing in the response
idea 5: use the whitelist variables/names for the server-side rendering/template of data that can reduce RCE/LFI attacks
idea 6:
- Use regex ( safer regex ) and datatype validation as middleware before reaching the routes
- using appropriate content-type for rendering data in frontend
- use helmet npm to add relevant security headers by default to all response
@shivasurya Thanks for those ideas! Is there a way to narrow them down so that we don't go into the details of specific libraries and frameworks? I strongly believe the guidance on the official Node.js site should be limited to JavaScript itself, the Node.js runtime and its core libraries.
Idea 7: How to execute external binaries/scripts with user-controlled arguments safely.
eg. execFile vs exec
Idea 8: How to safely craft user-influenced HTTP requests. (Prevent SSRF vulns, etc)
@MarcinHoppe I'll stick to the core lib and runtime and share possible ideas
@rikaardhosein Idea 8 remains me of this pdf https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
Where node.js has been mentioned by Orange abusing URL parser and Unicode failure. Just bringing to the notice and how can we mitigate such attacks or fuzz vectors.
@MarcinHoppe sorry for going more detailed, but what do you think about this?
I strongly believe the guidance on the official Node.js site should be limited to JavaScript itself, the Node.js runtime and its core libraries.
I would love to better understand your opposition to this!
The Website Redesign initiative work currently going on around Guides is taking the opposite stance, fwiw.
Suggestions:
- Automatically updating your dependencies
- Monitoring for known vulnerabilities in CI/CD
- Updating your runtimes to the minimum secure versions
@bnb My take on:
I would love to better understand your opposition to this!
is about controlling the scope, primarily. I feel that we should not go into general (Web) security guidance because there are more authoritative sources (e.g. OWASP) and I am not even sure if we should dive into security aspects of specific frameworks (e.g. Express). I feel that documentation for libraries and frameworks are better suited to deliver this kind of guidance.
I am happy to be convinced otherwise on both fronts.
The Website Redesign initiative work currently going on around Guides is taking the opposite stance, fwiw.
I would love to know more about that. I will ping you directly.
Idea 9: Cryptography guidelines
- Working with secure random values (RNG)
- Secure checks for initialisation vectors (IVs)
- Working with passwords (bcrypt, scrypt, pbkdf2, salting etc.)
- Timing attacks (side-channel)
Idea 10: Node.js event loop security [1]
refs: [1] https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ - it's really comprehensive guide but from the security perspective it could be useful to capture the essence of that text.
@MarcinHoppe not-so-brief response:
I would love to know more about that. I will ping you directly. It'll be helpful if I answer this first.
Basically, what we've been doing with the Guides section is approaching it as "How would you use Node.js in the real world?" At this point, this means you're using libraries, tools, CLIs, and services that are explicitly outside of Node.js core, but are effectively needed in the modern Node.js workflows to do anything. You're probably not going to be hosting your FaaS on a PC under your desk or rolling your own authentication tooling, for example... and if you are doing that at scale, it would be awesome to share how to do that with others 😅
This is something I've personally been pushing us toward. If you look at our contributor base, we're all passionate about certain technologies are are writing guides about Node.js as a project independently of Node.js. We all have expertise in various scenarios that others don't. I take the stance that we should be leveraging our community and providing a source of education for our ecosystem about real-world Node.js.
One key piece of this is that it's neutral, not agnostic.
- If someone wants to write guides about how to monitor Node.js with { Dynatrace || DataDog || Elastic || KeyMetrics || N|Solid }, they can.
- If someone wants to write about how to manage Node.js versions with { nvm || nvs || fnm || n }, they can.
- If someone wants to write about how to deploy Node.js to production with { AWS || OpenShift || Heroku || IBM Cloud || ZEIT Now || GCP || Netlify || Azure }, they can.
- If someone wants to write about how to addres vulnerabilities with { npm audit || Snyk || BlackDuck || Source Clear }, they can.
This has been done very intentionally. Who is better motivated and able to write from a place of expertise around Node.js + ${x} than the people who work on and maintain these platforms and projects?
Okay, now for the response to your response 😅
is about controlling the scope, primarily. I feel that we should not go into general (Web) security guidance because there are more authoritative sources (e.g. OWASP)
Definitely get where you're coming from here – it's certainly aligned with The Node.js Way™️ and how our ecosystem has built itself up successfully, I think.
I am not even sure if we should dive into security aspects of specific frameworks (e.g. Express).
I get where you're coming from with this. However, the place we've been coming from in the Website Redesign Initiative has been the opposite. The first thing you ask someone who is using Express – which means they're also using Node.js – is "are you using Helmet?" Even though this is something about Express, it still ends up deeply involving Node.js and reflecting on us. Providing a space for this content is – IMO – a good approach.
idea: managing dependencies guideline:
run npm audit, npm audit fix locally and/or CI to find and address vulnerabilities.
In terms of scope I think there are a couple of considerations:
-
keeping it manageable to start. This could mean that we start with a tighter focus but only to focus work not exclude content that might be added later
-
Avoiding overlap with existing authoritative sources. If there is a good source covering a particular area then avoiding duplication of conflicting guidance would be good. On the other hand if there is no existing source then I think expanding into areas that are important for the success of Node.js and the JS ecosystem (ex express) makes sense to me.
@bnb as we discussed privately, thanks for filling my gaps on the Website Redesign initiative. I think it makes a lot of sense to follow the same spirit. This is good news because we can provide broader guidance that way.
Now, getting back to @mhdawson’s point, I think keeping focus initially on JS, Node.js runtime and core libraries as a starting point will help keep the scope under control. We will be able to branch out later on.
@nodejs/security-wg I would love to hear your feedack about the plan.
Next step is for me to collect the submitted ideas and rank them based on community feedback (exact mechanism is TBD) and statistics from our ecosystem H1 program and possibly other sources that are willing to share Node.js vulnerability data.
OWASP itself have a cool section about some general guidelines on web security, so I really think that we should not overlap this sources, but at the same time, I love they format, of having a variety range of documents, where there are some of them really raw and generalistic (e.g The Top 10 project), and some of them really specific (e.g JWT best pratices in Java's Spring Boot), so, if we could create a sort of colaborative wiki, we can have a Node.js core focused guide, and the community can add more specific guides for libraries and other stuff, what do you think @MarcinHoppe?
Kind of late to the conversation, but I think missing here from #3 is the explicit mention of file-type detection - esp. considering the fact that e.g. node-mime only checks suffix not magic-numbers - and many devs consider a file suffix (instead of magic numbers) to be enough information to know what type of file they are dealing with. @lirantal knows exactly what I am referring to.
I think generally speaking, devs who leverage open source projects take a lot of risks and are paradoxically laissez-faire about their own security because they take infrastructures (and human good will) for granted.
In my point above about file suffixes, we all know how utterly simple it is to create a file that masquerades as e.g. an image - and with only superficial recon it's rather trivial to infer developer environment and hand-tune an attack.
My point (and something I always focus on during audits and trainings) is that it's important to read third party code and understand what's its doing instead of merely reading the comments and the docs (which, let's face it - are seldom perfect even if they are complete).
I think in the course of making docs for node in the context of developer security, one approach could be to help educate devs by not merely describing the interfaces, but actually showing the code - and enabling devs to understand the how instead of just the why.
This thread is great and I want to keep the discussion going. @MarcinHoppe I like this issue and I see great value in putting more security-oriented guides on the Node.js website. I'd like to work on a doc like the Node.js API DOs an DONTs (https://foundation.nodejs.org/wp-content/uploads/sites/50/2018/06/NodeJS_FieldGuide_Building_APIs_Final.pdf)
I had an experience this week that I found to be rather shocking - but also see it as an opportunity for node to shine.
In the course of a vuln triage, I discovered that the SPEC and security resources (made available by the W3C) for a specific issue I was investigating were not only painfully out of date, but also literally dangerous because of omissions.
I can't comment here in public about the specific issue yet, but the takeaway is that there are many underlying technologies that need better, more accessible security descriptions. Because of the ease with which complicated stacks can be thrown together, great deals of basic knowledge seem to be ignored - or worse - trapped in historical limbo and out of touch with the modern web.
If you could share that in a private forum on the security wg slack we could invite you. I'd be happy to learn more about this in terms of practical advice on what could be done better.
I think we are recently moving toward that goal. The idea is to use the work on the threat model as a foundation for a new user documentation (which will be security oriented).
I think however we still have no issue for this since if I remember we are waiting to finish the threat model. cc @UlisesGascon @RafaelGSS (correct me if I say something wrong 😊).
The threat model is definitely part of it, but I think @nothingismagick had also wanted general best practices for developer security, which I don't think we're going to encompass in the threat model we're building, as that's more around securely running Node.js applications, rather than secure coding conventions.