NoSQL, But Even Less Security

Hi all, Bryan here. If you’re in the Los Angeles area, I’d like to invite you to the presentation I’ll be giving at the OWASP LA chapter meeting on Wednesday, April 27th, titled “NoSQL, But Even Less Security.” We’ll be taking an in-depth look at some programming “worst practices” that can lead to vulnerabilities in applications using NoSQL databases such as MongoDB, Riak, CouchDB, Neo4j, or Cassandra. Here’s a sneak peek at some of the problems I’ll be talking about:

Eventual consistency. According to Eric Brewer’s CAP theorem, at any given time a system has to give up either consistency, availability, or partition tolerance: It’s impossible to always have all three. For many organizations, the whole reason they’re moving away from traditional relational SQL databases is that they want to improve scalability (i.e. partition tolerance). Since the CAP “P” is a hard requirement, you have to choose between consistency and availability, and some NoSQL databases choose availability. These are called “eventually consistent” databases, because at any given time you can’t be sure you’re seeing up-to-date data. Of course, to a security person, “eventual consistency” is just a fancy way of saying “race condition,” so we’ll be demonstrating some of those.

CSRF and REST APIs. Authentication and authorization are very weakly implemented in most NoSQL databases, if they’re implemented at all. Usually, if you can get to the port where the database is running, you have complete administrative access to it. Even assuming that you’ve closed off outside access to those ports with your firewall (I hope this is a good assumption!), you may still be vulnerable to cross-site request forgery attacks against the database REST APIs.

NoSQL injection. NoSQL databases may not have fixed schemas like SQL databases, but that doesn’t mean they’re any more resilient against injection attacks. In some cases, it makes exploitation even easier. We’ll show how ‘ OR ‘1’ = ‘1 still works wonders in the NoSQL space unless you’ve taken proper defensive measures.

Server-side JavaScript injection. The competition between Microsoft, Mozilla, Google and Apple to produce the fastest Web browser has given us incredibly fast JavaScript engines. (While I’m personally more than a little skeptical, some people are claiming that JavaScript outperforms C in certain benchmarks. But regardless of whether you believe this or not, you have to admit that JavaScript engines have come a long way in recent years.) Developers are taking advantage of the speed of these engines to create server-tier applications with them, notably Node.js Web servers and NoSQL databases. Now, when an attacker can inject his own script into a Web browser, we call that cross-site scripting, and we consider it one of the most serious Web application vulnerabilities there is (it’s currently #2 on the OWASP Top Ten list). But when an attacker can inject his own script into a server-side application, it’s even worse. Orders of magnitude worse. In some cases, these vulnerabilities can allow the attacker to upload and execute arbitrary binaries on the server – basically completely owning the machine.

Again, if any of this catches your interest, please stop by the OWASP LA meeting on Wednesday, April 27th. Hope to see you there! (If you’re interested but can’t make it, send me an email – brsulliv at adobe – and I’ll send you back the slides. If there’s enough interest, I’ll just post them here.)

Comments are closed.