Primer: Introduction to No-SQL Databases and MongoDB

Firesand: End-to-End Security for your Business

Introduction

This article is one of a collection of primer articles, providing a basic introduction to various topics, for reference in other – more in-depth – articles. These primer articles are written as people come to security pages from various backgrounds, be it a software engineer who wants to understand an issue they need to fix (or prevent one from occurring in the first place) or a penetration tester with no background in software engineering, who wants to understand and know how to exploit a particular issue.

This primer is on No-SQL databases and specifically regarding MongoDB.

No-SQL Databases and MongoDB

MongoDB is one of several 'No-SQL' databases, other examples include: Couchbase, DynamoDB, Memcached, Redis, and a plethora of others!

MongoDB can be deployed and managed by IT teams locally within an organisation’s own infrastructure (Cloud or otherwise), or it is available as a cloud service, as MongoDB Atlas.

What is the distinction between a SQL Database and a No-SQL Database?

There are a variety of differences between these two broad categories of database technology, not least because there is huge variability in the No-SQL space. For example, some of these store Key-Value pairs (e.g., Couchbase), whilst databases such as MongoDB store their data as JSON (JavaScript Object Notation) Documents.

At broad level, some important common differences are as follows:

No-SQL database advantages, when compared with SQL databases, they:

• May be faster and more efficient for certain operations.
• May scale more easily.
• Tend to have more flexible data structures, making development and subsequent modification easier.

No-SQL database disadvantages, when compared with SQL databases, they:

• Tend to not support ACID properties, and thus risk data consistency.
• May struggle with joins between different datasets.
• Typically use 'lower-level' (arguably more technical) query languages.

Note: neither list above is complete, nor do the advantages or disadvantages universally apply!

MongoDB: Documents and Collections

A MongoDB does not store ‘Records’, or ‘Rows’, nor does it have a concept of 'Tables' as per traditional SQL databases. Instead, MongoDB uses 'Documents' and 'Collections'.

The Document being the closest equivalent to a row/record and the Collection being the closest equivalent to a table.

An interesting feature of this is that the data is - potentially - denormalised, and the structure of Documents in the same Collection can vary wildly.

What does this look like with MongoDB?

MongoDB stores its data as JSON documents (or more specifically BSON (Binary JavaScript Object Notation) which is a binary encoded JSON document).

However, for the purposes of simplicity, in this article we will show BSON represented as JSON!

If we consider a simple example of a database system that held three attributes in a user table: UserId, UserName, and Password.

In a traditional SQL database, this would be represented in a table format:

Whereas with JSON, this could look like:

{
    id: 1,
    username: 'Yossarian',
    password: 'Catch22'
}

Note: yes, there is absolutely a glaring security flaw here, but that is not the focus of this article!

In terms of interacting with the databases, the following presents how to select data in both scenarios:

Traditional SQL Query:

SELECT UserId FROM TUser WHERE UserName = 'Yossarian' AND Password = 'Catch22'

No-SQL Query:

{ UserName: 'Yossarian', Password: 'Catch22' }

The following image shows what this might look like in the MongoDB Compass application:

As can be seen, submitting such a query, will return the associated JSON document.

Of course, there are a wide range of queries that can be executed, and very importantly - especially from the perspective of an attacker - there are various MongoDB commands that can be submitted, parsed, and executed by MongoDB itself.

Final Thoughts

This has been a very basic introduction to No-SQL databases, and very specifically MongoDB! As can be seen, these behave in a different manner than traditional SQL databases, and present some advantages and some disadvantages.

However, fundamentally, they are still data stores that can be queried by constructing queries using external input, which is very important from a security perspective.

About the author

https://www.linkedin.com/in/chrisblake/

Chris Blake has over 20 years of experience in the information and cyber security field, and is a passionate and qualified Enterprise Security Architect and Privacy Professional who leads and delivers innovative solutions at Firesand Limited, a company he co-founded in 2016. His specialities include application security, enterprise security architecture, and privacy, with a strong track record of building and implementing ISO 27001 compliant and certified information security practices, application security programmes, and enterprise security architectures. He has a thirst for continual learning and a commitment to excellence, as demonstrated by his academic and professional credentials from prestigious institutions such as the University of Oxford, (ISC)², IAPP, SABSA, The Open Group, and ISACA.

Chris holds an MSc in Software and Systems Security at the University of Oxford, and an array of professional certifications: CISSP, ISSAP, CSSLP, CCSP, SSP.NET, SSP.JAVA, CISA, CISM, CIPP/E, CIPM, CIPT, FIP, SCF, TOGAF, CPSA, and CEH.

Chris' experience spans multiple sectors: Retail & eCommerce; Financial Services, Banking, & Payments; i-Gaming; Energy (Oil & Gas); Property Management & PropTech; and Data Science; as well as Defence. 

His areas of interests include: penetration testing; regulation & privacy, including the impact on society; access control in software; security automation in development; application of cryptography; security architecture; risk modelling & analysis; HTTP architecture & web security; IoT Security.