When I left there in 2011 they still had unhashed passwords all over the place. I kept stumbling into them when I wasn't even supposed to have DB access, it was like a bad comedy.
Those two unhandled errors in the Rainbow bcrypt hashes are a big security bug: a constant (unnoticed) error would allow ANY password to be accepted! This is similar to an old Linux bug where there was an equal instead of a comparison sign, allowing for any password. Use either a well tested library if you want a Promise-based bcrypt function or make sure you test yours.
However it still seems like a good starting point and if you follow those steps it's better than nothing.
This article made me confirm my suspicion about Node.js (and by the way I do program in Node.js as well): It is becoming the new PHP.
When you lower down the entry barriers to web development, more kids proclaim themselves as experts, or pretend to really know how to create a deployable-in-real life web application, with disastrous results.
This article would be a great article if it was written in 1995, just after cookies were introduced.
Since this is 2017, the shallowness of the advice given makes me think that out there, there are thousands of javascripters* who are implementing web apps without knowing even the essentials of http/cookie/passwd security. Many of them, also, rely on MongoDB, the Snapchat of Databases, even though the information to be stored for their purposes is often clearly relational and the app require transactions.But no, let's use Mongo because we're with the MEAN stack and because it is so easy to setup.
*not to mention that still in 2017 many of them still don't adopt the Ecmascript2017 advantages, and are still doing boilerplate nightmare like:
if (err) {...}
else { dostuff (x, function (err,res) {
if (err) {...}
else { dostuff2 (x, function (err,res) {
if (err) {...}
else { dostuff3 (x, function (err,res) {
if (err) {...}
else { dostuff4 (x, function (err,res) {
if (err)
... instead of using async and await for bringing the code down to acceptable elegance levels!!
I'm speaking about a real problem with the node.js community, and I say this as a user of the platform. The entry barrier is small and this creates some problems, not only the lack of security considerations on lots of web apps out there, but also on the quality of some NPM packages out there. Don't get me wrong, node.js is a good idea, but as ponted out by mikacsika's comment below:
"Also, a lot of Node.js teams popping up from development shops et al consist of front-end engineers that have never needed to understand the systems-level impact of their code"
One of my responsibilities is assisting a small start-up implemented in node.js. Guess what? A site developed exclusively by frontend developers. I pointed out many problems with the code, including security concerns. They were reluctant to implement the many changes i recommended, acting as if the targeted-to-frontend-turned-fullstack tutorials were always right... until their server and db got hacked 15 days ago. True story.
And I believe you. I still don't think that's a problem exclusive to Node. I've seen godawful, naive, insecure codebases written in C, C++ and PHP. I've talked to co-workers about similar experiences in Python, ColdFusion ...
This 'Node people are the worst because they came from the front-end' attitude is poison.
Article only scratch surface. XSS/CSRF, SQL injections, JavaScript injection, JSON hijacking, cookie poisoning and privileged escalation just to name few.
Each input from external source is potentially malicious. Passwords security is now well understood, there so many places where security can go wrong.
This title has been changed from its original. Mods?
Node.js applications are one thing, Express.js applications are another. This seems to talk about the Express.js framework, and Express has its own set of guidelines that should be followed as the bare minimum, sadly in the "advanced" section:
In reality I see two things that bite most outfits getting their feet wet with Node for the first time, and it's not how well the passwords are hashed.
First is the age-old problem of input validation. Express.js devs read the tutorials that show bringing in data directly from req:
... and just accept it. Unvalidated input / unfiltered output seems par for the course in a lot of smaller Express.js APIs, especially when they are using Angular, Knockout or another client-side framework that offers some filtering of data being returned from the API.
A close second is third-party dependencies. While the Node Security Project does what it can to help out, and nsp/snyk are good best practices, the Node.js culture of importing modules for everything often leads to really large attack surfaces with rarely-audited modules of unknown provenance added for development speed. Third-party modules -- especially less popular ones -- are a goldmine of critical vulnerabilities just as WordPress plugins used to be (and still are).
Also, a lot of Node.js teams popping up from development shops et al consist of front-end engineers that have never needed to understand the systems-level impact of their code. Many are used to JS for talking to API black-boxes and making cool effects or reactive user interfaces, and they're not often thinking about directory traversal, SQL injection or cookie poisoning because those have traditionally not been in the domain of the JavaScript-oriented developer.
With NPM i have seen something i've never ever seen in my life with package ecosystems (i.e. Maven, Pip): On NPM, there are packages out there that can have as much as 32 dependences, and, more ridiculously, some of these 'libraries' are small snippets of code (just a few lines). It is really a cause of concern, for me...
12 comments
[ 1.3 ms ] story [ 33.6 ms ] threadHere is something more specific related to the qs module in express and mongodb: http://blog.websecurify.com/2014/08/hacking-nodejs-and-mongo...
However it still seems like a good starting point and if you follow those steps it's better than nothing.
When you lower down the entry barriers to web development, more kids proclaim themselves as experts, or pretend to really know how to create a deployable-in-real life web application, with disastrous results.
This article would be a great article if it was written in 1995, just after cookies were introduced.
Since this is 2017, the shallowness of the advice given makes me think that out there, there are thousands of javascripters* who are implementing web apps without knowing even the essentials of http/cookie/passwd security. Many of them, also, rely on MongoDB, the Snapchat of Databases, even though the information to be stored for their purposes is often clearly relational and the app require transactions.But no, let's use Mongo because we're with the MEAN stack and because it is so easy to setup.
*not to mention that still in 2017 many of them still don't adopt the Ecmascript2017 advantages, and are still doing boilerplate nightmare like:
if (err) {...} else { dostuff (x, function (err,res) { if (err) {...} else { dostuff2 (x, function (err,res) { if (err) {...} else { dostuff3 (x, function (err,res) { if (err) {...} else { dostuff4 (x, function (err,res) { if (err)
... instead of using async and await for bringing the code down to acceptable elegance levels!!
> Becoming the new PHP
> Kids ...
> Many of them, also, rely on MongoDB, the Snapchat of Databases
These generalizations aren't helpful. Please don't pretend this wasn't an opinion you'd already formed.
"Also, a lot of Node.js teams popping up from development shops et al consist of front-end engineers that have never needed to understand the systems-level impact of their code"
One of my responsibilities is assisting a small start-up implemented in node.js. Guess what? A site developed exclusively by frontend developers. I pointed out many problems with the code, including security concerns. They were reluctant to implement the many changes i recommended, acting as if the targeted-to-frontend-turned-fullstack tutorials were always right... until their server and db got hacked 15 days ago. True story.
This 'Node people are the worst because they came from the front-end' attitude is poison.
Each input from external source is potentially malicious. Passwords security is now well understood, there so many places where security can go wrong.
Node.js applications are one thing, Express.js applications are another. This seems to talk about the Express.js framework, and Express has its own set of guidelines that should be followed as the bare minimum, sadly in the "advanced" section:
https://expressjs.com/en/advanced/best-practice-security.htm...
https://blog.risingstack.com/node-js-security-checklist/
In reality I see two things that bite most outfits getting their feet wet with Node for the first time, and it's not how well the passwords are hashed.
First is the age-old problem of input validation. Express.js devs read the tutorials that show bringing in data directly from req:
https://expressjs.com/en/api.html#req
... and just accept it. Unvalidated input / unfiltered output seems par for the course in a lot of smaller Express.js APIs, especially when they are using Angular, Knockout or another client-side framework that offers some filtering of data being returned from the API.
A close second is third-party dependencies. While the Node Security Project does what it can to help out, and nsp/snyk are good best practices, the Node.js culture of importing modules for everything often leads to really large attack surfaces with rarely-audited modules of unknown provenance added for development speed. Third-party modules -- especially less popular ones -- are a goldmine of critical vulnerabilities just as WordPress plugins used to be (and still are).
Also, a lot of Node.js teams popping up from development shops et al consist of front-end engineers that have never needed to understand the systems-level impact of their code. Many are used to JS for talking to API black-boxes and making cool effects or reactive user interfaces, and they're not often thinking about directory traversal, SQL injection or cookie poisoning because those have traditionally not been in the domain of the JavaScript-oriented developer.
With NPM i have seen something i've never ever seen in my life with package ecosystems (i.e. Maven, Pip): On NPM, there are packages out there that can have as much as 32 dependences, and, more ridiculously, some of these 'libraries' are small snippets of code (just a few lines). It is really a cause of concern, for me...