Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What security guidance would be most useful for Node.js developers? #488

Open
MarcinHoppe opened this Issue Feb 9, 2019 · 20 comments

Comments

Projects
None yet
8 participants
@MarcinHoppe
Copy link
Contributor

MarcinHoppe commented Feb 9, 2019

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.

@MarcinHoppe

This comment has been minimized.

Copy link
Contributor Author

MarcinHoppe commented Feb 9, 2019

Idea 1: Managing dependencies to minimize the attack surface and make upgrading vulnerable dependencies a manageable problem.

@MarcinHoppe

This comment has been minimized.

Copy link
Contributor Author

MarcinHoppe commented Feb 9, 2019

Idea 2: working with regular expressions to avoid Regular Expression Denial of Service (ReDoS) attacks.

@MarcinHoppe

This comment has been minimized.

Copy link
Contributor Author

MarcinHoppe commented Feb 9, 2019

Idea 3: working with filenames and paths in a secure way to avoid Path Traversal attacks and similar.

@shivasurya

This comment has been minimized.

Copy link

shivasurya commented Feb 11, 2019

Idea 4: logging the errors to log management and preventing complete stacktrace printing in the response

@shivasurya

This comment has been minimized.

Copy link

shivasurya commented Feb 11, 2019

idea 5: use the whitelist variables/names for the server-side rendering/template of data that can reduce RCE/LFI attacks

@shivasurya

This comment has been minimized.

Copy link

shivasurya commented Feb 11, 2019

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
@MarcinHoppe

This comment has been minimized.

Copy link
Contributor Author

MarcinHoppe commented Feb 11, 2019

@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.

@rikaardhosein

This comment has been minimized.

Copy link

rikaardhosein commented Feb 11, 2019

Idea 7: How to execute external binaries/scripts with user-controlled arguments safely.

eg. execFile vs exec

@rikaardhosein

This comment has been minimized.

Copy link

rikaardhosein commented Feb 11, 2019

Idea 8: How to safely craft user-influenced HTTP requests. (Prevent SSRF vulns, etc)

@shivasurya

This comment has been minimized.

Copy link

shivasurya commented Feb 11, 2019

@MarcinHoppe I'll stick to the core lib and runtime and share possible ideas

@shivasurya

This comment has been minimized.

Copy link

shivasurya commented Feb 12, 2019

@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?

@bnb

This comment has been minimized.

Copy link
Member

bnb commented Feb 12, 2019

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.

@bnb

This comment has been minimized.

Copy link
Member

bnb commented Feb 12, 2019

Suggestions:

  • Automatically updating your dependencies
  • Monitoring for known vulnerabilities in CI/CD
  • Updating your runtimes to the minimum secure versions
@devansvd

This comment has been minimized.

Copy link

devansvd commented Feb 12, 2019

  • Fine tune validation for user inputs.
@MarcinHoppe

This comment has been minimized.

Copy link
Contributor Author

MarcinHoppe commented Feb 12, 2019

@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.

@radekk

This comment has been minimized.

Copy link

radekk commented Feb 13, 2019

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.

@bnb

This comment has been minimized.

Copy link
Member

bnb commented Feb 15, 2019

@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.

@oke-py

This comment has been minimized.

Copy link

oke-py commented Feb 16, 2019

idea: managing dependencies guideline:
run npm audit, npm audit fix locally and/or CI to find and address vulnerabilities.

@mhdawson

This comment has been minimized.

Copy link
Member

mhdawson commented Feb 17, 2019

In terms of scope I think there are a couple of considerations:

  1. 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

  2. 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.

@MarcinHoppe

This comment has been minimized.

Copy link
Contributor Author

MarcinHoppe commented Feb 18, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.