NoSQL security: All content tagged as NoSQL security in NoSQL databases and polyglot persistence
The security alert:
- Your password wasn’t leaked, but the hash was. Still not great.
- It’s fixed now.
The root problem?
To do login, npm uses the /_users database in couchdb. By default, CouchDB prior to version 1.2.0 makes this database world-readable.
Yet another problem
Latest stable CouchDB release is 1.1.1. And you’ll probably find some more nasty comments in the Hacker News thread.
Captured by Klint Finley from Jan Lehnardt:
For those not ready to upgrade to 1.2.0 CouchDB developer Jan Lehnardt suggests restricting access to /_users with a proxy.
The good news of course is that the CouchDB is changing this default behavior. The bad news is that it took this long for the problem with NPM to be noticed and fixed.
Me: the very bad news is that security is still an after-thought for many NoSQL databases.
Original title and link: CouchDB in Node Package Manager Exposed Password Hashes ( ©myNoSQL)
If you take a look at the topic of security in the NoSQL context, you’ll notice that things are far from being perfect. So, any contributions in this area are welcome. Patrik Karlsoon added a couple of network exploration Nmap scripts for Riak, Redis, and Memcached. And while these will not help much with security they might proove useful for managing your NoSQL deployments:
Added the script riak-http-info that lists version and statistics information from the Basho Riak distributed database.
Added the script memcached-info that lists version and statistics information from the distributed memory object caching service memcached
Added the script redis-info that lists version and statistic information gathered from the Redis network key-value store.
Added the redis library and the script redis-brute that performs brute force password guessing against the Redis network key-value store.
Original title and link: Nmap Scripts for Riak, Redis, Memcached ( ©myNoSQL)
Jeff Darcy has written a while back about the (lack of) security in NoSQL database. Unfortunately things haven’t changed much and if you check the NoSQL + Node.js applications I’ve posted lately you’ll notice that some of them are completely ignoring security.
And there are some people realizing the risks and starting to express their concerns:
Playing with MongoDB lately, I’m getting scared. Because I’m seeing some really bad practices out there. Seeing it in live code. In tutorials.
Because of this, defenses against SSJS injection are also similar to SQL injection defenses:
- Validate user input used in SSJS commands with regular expressions.
Remember there’s no such thing as security through obscurity.
So, MongoDB presented us with two problems:
- When sharding it, we can’t even use the basic security that it supports.
- The basic security that it offers is not reasonable for allowing external servers to connect to MongoDB.
Let’s just review:
you have this sharding setup:
on top of that add some Nginx
- switch from using a binary protocol to HTTP
Doesn’t sound easy or out of the box anymore.