Meteor Security, and Security in General, at 2024-03

Security
1

Hi !

At Slack was this question:

From klaucode:

Hi, I would like to ask question related to the Meteor security, because Meteor is using lot of external packages, therefore I have a question, how you are checking (or if is it somehow possible to check), if author of some npm package will add to the package some bad code, which can be added to the Meteor wih npm update. How to protect this bad thing (and which processes are you using to protect it)? Is it good idea to use Meteor to the project, where security is important? And also what about insecure old nodejs, when will be available Meteor3 for production? (this is probably not question directly to the meteor, but it’s related to the all apps using external dependencies). …because by me, less external dependencies are in this case better. Thanks a lot for an each answer.

TL;DR

To be really sure, you have to read all source code you use, like all web framework code, all dependencies, etc. And not trust blindly at checks done by others.

Alternative is, that you write all your minimal code yourself, without any dependencies, and check is your code affected by any of the common vulnerabilities.

Npm packages security

Snyk

For example, Snyk is finding and publishing info about vulnerable NPM packages they find:

Here is how to add GitHub integration of Snyk for checking:

Dependabot

It automatically add fix pull requests to update vulnerable dependencies

Socket Security

GitGuardian

Suggested by @storyteller at Slack

npm audit command

Meteor Security

Meteor security video

Examples of Meteor security fixes

Examples of Hall of Fame of Meteor security fixes

https://wekan.github.io/hall-of-fame/

Upcoming Meteor 3 progress

Meteor Forums Security category

Security in general

OWASP

OpenSSF and it’s Slack for discussions

Secure by Design

PDF:

News:

https://www.cisa.gov/news-events/news/effort-bolster-government-cybersecurity-biden-administration-takes-step-ensure-secure-development

NSA’s Top Ten Cloud Security Mitigation Strategies

PDF:

News:

7 Likes
2

In my experiences, most of serious security issues come from programmer’s mistakes. The biggest mistake is believing in everything client gives. You must be suspicious.
meteor-suspicious

2 Likes
3

Hi @xet7, I’m very appreciate your interest about my question.

My question is mostly focused to the following points:

  • If Meteor can be consideres as safe (especially without any ‘bad code’ comming from used NPM extensions)?
  • If it isn’t confidential, which mechanisms/processes Meteor development team is using to be sure, that not ‘bad code’ is comming from external dependencies? Because I think, If I want to stay on same security level as Meteor, than I must use minimum same or higher level of security processes during development as a Meteor team.
  • What I can do to prevent integration ‘bad code’ from external dependencies and what another activities to do to stay safe. To this point was already answered by @xet7 and @storyteller .
4

@minhna I agree, it’s truth. But my question is focused mostly for code comming from external dependencies.

For sure, all of us remember, when we developing code in PHP, all forms, html code, almost everything was rendered by the server and there was minimum external dependencies. Now we are in time, when our app has few megabytes of own source code and hundreds megabytes of code comming from external dependencies and dependencies of dependencies. Therefore I think, that risk and vector of potential disruption is biggest from this side.

1 Like
5

Trust me I work on a project with laravel and you need a huge ton of extensions to get a website that is somewhat safe so it’s not really different from JS Frameworks.

2 Likes
6

@klaucode

There is not yet any web framework that has all the new additional requirements specified in above documents “Secure by Design” and “NSA’s Top Then Cloud Security Mitigation Strategies”.

While I have received and fixed those vulnerabilities I did get from responsible security disclosure reports from security researchers and added them to Hall of Fame, because they did audit Meteor based WeKan, you can not use that as any guarantee for your Meteor based code, because you could maybe use some different dependencies.

Some companies like NPM and Snyk have automatic and manual audit tests for packages that are at NPM registry, but you need to find information from their websites, how they verify packages.

When there will be audit of your code, they will ask for examples, how to you prevent various kinds of security vulnerabiltiies, like XSS, and others. For that, you need to know how those work, and test your own code. Because code you have written could have those security issues, there could be some typo, etc. You can not be sure is something secure, before you have checked is it secure.

For webbrowsers, you should have Firejail sandboxed Firefox, configured so that it can only read and write .mozilla and Downloads directory. And not be able to read your ssh private keys at ~/.ssh/ . Or alternatively, run browser in some VM, where are not your private keys. Because there has been browser vulnerabilities, where with Javascript it’s possible to upload any file from harddisk to Internet, like ssh private keys, and other private files.

For desktop operating systems, you should be using Linux Mint with automatic updates with mintupdate: deb and flatpak automatic update, and snap has automatic updates. Because any other operating system does not have automatic updates at all.

For some hardware, Qubes OS is also possible to use.

For servers, you should use containers, like Docker/Snap/SandstormGrain, because they limit write access to only some specific directory.

For servers, you should also use full disk encrypted VMs, like this Many Snaps on LXC · wekan/wekan-snap Wiki · GitHub

1 Like
7

Zero Trust

1 Like
8

At Slack, from sussition:

You can also enforce a strict content-security policy and use script nonce to ensure that you only load external dependency versions that you have vetted

9

Before npm, opensource was something like:

Go to something like sourceforge, search for library/framework/utility, download, and use in your code. If there were security issues, it could be fixed in the opensource project, but it would be a miracle for anyone to update all the utilities/libraries they have used from different places for every “security fix.”

Also, if you were using PHP, you were mostly running your code on opensource stuff like web servers, proxies, mysql db, and their plugins/extensions which were all 3rd party code that you didn’t vet yourself.

Compared now, as mentioned, npm has automated tools for security. There are tools to automatically keep your packages updated. Social media helped in disseminating news about security issues on packages/libraries. We are running stuff on services managed by companies with their own teams dealing with security.

2 Likes
10

I lead security for my team and given we have built and maintain a number of healthcare apps, we always operate with the Zero Trust model.

Examples above are good, and automated tools like static code analysis are good as well, but our absolute go-to is always a pen-test. I’m never comfortable deploying a Production app unless it’s had real-world penetration tests done by a professional. I’ve seen static analysis produce hundreds and hundreds of false positives. But pen-tests show you what’s actually vulnerable.

6 Likes