Security & Mobility Now
Security is top-of-mind everywhere, especially right here where Juniper experts share their thoughts on the latest security breakthroughs and product advancements
JUNOSRob

NoSQL Injection

by Juniper Employee ‎06-19-2012 09:00 AM - edited ‎06-15-2012 03:34 PM

As times change so do the problems that we face. In today’s world we face the problems of ever changing datasets. When creating an application the schema that is used to contain our data is no longer fixed. Due to the rapidity of development, companies can’t wait weeks to complete the definition of how they want to store their data. Waiting a week or a month on your application or enhancement may spell disaster for your product. In some cases you want the flexibility to change how your data is stored and queried to get the most out of your data. Because of these challenges the NoSQL movement was born.

 

NoSQL is a technology that allows you to have non-fixed datasets when storing data into a database. The minimal need you want to solve by using NoSQL is the need for two or more items stored in a dataset to have different properties. An example would be if you wanted to store contact information such as name, address, and telephone number. What if you had users that had twitter, foursquare, or Facebook data that you wanted to store with your traditional contact data? In a traditional relational database you would need to preallocate all the fields that you need upfront. You can change your fields within a relational database but it may take an extreme amount of time to apply those changes to your database. This may cause downtime or loss of productivity. Because of this NoSQL was created. Because we have moved forward with NoSQL doesn’t mean that we leave traditional databases behind. If you’re using a fixed field dataset then odds are traditional databases still work for that application.

 

NoSQL databases are popular in the field of web applications and analytics. There are even a few different types of NoSQL systems as they accomplish different things. One example is an in memory database. This would include Redis or Memcache. These systems are used for high volume queries that need extremely low latency responses. Great uses for these systems are for things like trending lists on social networks or online games. They both need low latency access to a set of data. In the case of social networks  such as Twitter tens of millions of people look at the top trends per day. A backend system performs analysis on the feed on incoming tweets and then posts the result of the analysis to the memory database. When users are looking to see what the hottest trends are they will access the memory store and then get a very fast response. This is much better than the usual query against a database. A database would need to spin up its disks, perform a calculation, and then return the data.

 

Because of the popularity of these databases and the fact that they are being used in a wide variety of applications, we naturally intersect with security risks. By default these databases do not use authentication. This would be the state if you downloaded the software and installed it yourself. Why not use authentication? Well the idea is accessibility toward developers. Ideally these databases are deployed in firewall secured locations or listening so only on server processes can talk to them. With the drive of cloud based services its possible to assemble an application of any scale very quickly. Sometimes in doing so developers may forget about the need for authentication.

 

Besides user data it’s common to store things such as session cookies or other application state data inside of these databases.  In extreme examples an attacker could dump all of your session cookies and then use this to access a site with another users credentials. Other cases attackers used the NoSQL systems to store and serve malware.

 

The biggest issue here isn’t with the databases themselves but as with most security issues it has to deal with the humans configuring them. Below is a series of links on how to enable authentication on the various databases that I mentioned. Ideally you would want to limit access to the systems with a network firewall or perhaps server side firewalling. If the database’s port is open to the Internet odds are someone will attempt a brute force attack on the system to break in. This is common with any authenticated service (SSH, FTP, HTTP, etc.) let alone a service that provides the potential for very valuable data. There is even a module for Metasploit to brute force against a MongoDB host. There are other similar modules for scanning for Redis and other NoSQL systems.

 

When choosing to use any service you need to be aware of the implications of it. If your going to use a service to host data, the protocol or application is irrelevant, be aware of the risk if that data is made accessible. Because NoSQL systems are somewhat new to network security administrators its important to be aware of the potential risks of these services running in your network.

 

Securing Databases:

MongoDB: MongoDB Security

Redis: Redis Security

CouchDB: CouchDB Security

Memcache: Memcached Security

Comments
by Bbaer(anon) on ‎06-20-2012 02:13 PM

No SQL options don't leverage the significant embedded knowledge among customers of SQL.  Often requires a completely new query language which can be seen as an investment in something unproven.  In other words investments in infrastructure that may have no legs or is not future proofed.  It would seem to me the better option would be to explore the NewSQL solutions that provide new, scalable infrastructure for big data but support existing query tools leveraging SQL knowledge and investments?

 

What is your opinion or perspective on this?

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About Security & Mobility Now

Discussing a wide range of topics impacting enterprises and
data center security.

Subscribe RSS Icon

Our Bloggers

Kyle Adams
Senior Software Engineer

Profile | Subscribe

Ritesh Agrawal
Director
Software Engineering

Profile | Subscribe

Erin K. Banks
Senior Technical Marketing Manager

Profile | Subscribe

Ajay Bharadwaj
Product Manager

Profile | Subscribe

Michael Callahan
Vice President
Product Marketing

Profile | Subscribe

Scott Emo
Director
Product Marketing

Profile | Subscribe

Mora Gozani
Senior Manager
Product Marketing

Profile | Subscribe

Ashur Kanoon
Sr. Manager
Technical Marketing

Profile | Subscribe

Seema Kathuria
Manager
Product Marketing

Profile | Subscribe

Kevin Kennedy
Senior Director
Product Management

Profile | Subscribe

Dave Killion
Software Engineer

Profile | Subscribe

Rebecca Lawson
Senior Director
Product Marketing

Profile | Subscribe

Rajoo Nagar
Senior Manager
Product Marketing

Profile | Subscribe

Erin O'Malley
Manager
Product Marketing

Profile | Subscribe

Galina Pildush
Strategy & Planning
Architect

Profile | Subscribe

Edward Roberts
Director
Product Marketing

Profile | Subscribe

Bill Shelton
Director Field Sales

Profile | Subscribe

Ashutosh Thakur
Product Line Manager

Profile | Subscribe

Troy Vennon
Software Engineer

Profile | Subscribe

Brad Woodberg
Product Manager

Profile | Subscribe

Labels
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.