1. False Activity Messages: Sites falsely claim high user activity or interest in a product to create urgency.

2. Deceptive Consumer Testimonials: Using fake endorsements or presenting testimonials without disclosing material information.

3. Deceptive Celebrity Endorsements: Falsely attributing testimonials to celebrities.

4. Parasocial Relationship Pressure: Leveraging trusted characters, especially those familiar to children, to influence choices.

Scarcity

1. False Low Stock Message: Misleading users by indicating low stock to prompt immediate purchases.

2. False High Demand Message: Creating a false sense of urgency by claiming high demand.

Urgency

1. Baseless Countdown Timer: Displaying a fake countdown clock to pressure immediate purchases.

2. False Limited Time Message: Suggesting offers are time-limited when they are not.

3. False Discount Claims: Advertising fake discounts or sales to lure consumers.

Obstruction

1. Price Comparison Prevention: Making it difficult for shoppers to compare prices by bundling items or using inconsistent measures.

2. Roadblocks to Cancellation: Designing processes that make it easy to sign up but challenging to cancel.

3. Immortal Accounts: Making it hard or impossible to delete an account.

Sneaking or Information Hiding

1. Sneak-into-Basket: Automatically adding items to the shopping cart without the user’s consent.

2. Hidden Information: Withholding essential information or significant product limitations.

3. Hidden Costs: Adding fees or charges that are not initially disclosed.

4. Drip Pricing: Advertising a partial price and adding mandatory charges later in the buying process.

5. Hidden Subscription or Forced Continuity: Offering a free trial that transitions into a paid subscription without clear consent.

Interface Interference

1. Misdirection: Designing elements to focus user attention away from critical information.

2. False Hierarchy or Pressured Upselling: Using visual prominence to nudge users toward specific choices.

3. Disguised Ads: Making advertisements look like unbiased product reviews or independent articles.

4. Bait and Switch: Leading users to expect one outcome but delivering another.

Coerced Action

1. Unauthorized Transactions: Tricking users into paying for goods or services they didn’t intend to buy.

2. Auto-Play: Automatically playing additional videos in a disruptive or harmful manner.

3. Nagging: Repeatedly and disruptively asking users to take an action.

4. Forced Registration or Enrollment: Requiring account creation or information sharing to complete a task.

5. Pay-to-Play or Grinding: Advertising free access but then charging for full functionality.

6. Friend Spam, Social Pyramid Schemes, and Address Book Leeching: Misusing email addresses or social media permissions for unintended purposes.

Asymmetric Choice

1. Trick Questions: Using confusing language to steer users towards unwanted actions.

2. Confirm Shaming: Shaming users into making certain choices by framing alternatives negatively.

3. Preselection: Preselecting options that benefit the company but not the user.

4. Subverting Privacy Preferences: Tricking users into sharing more information than intended.

Source: https://www.ftc.gov/reports/bringing-dark-patterns-light

Several months ago I was working on a side project for automating the election results display. I had a quick development process and published the website with Ampt and the database server. My Security Researcher friend Sven immediately sent the URL he exploited the application and I was kind of surprised as I was using default queries nothing very specific but the result was there, he was blocking my application to proceed with data with fun! Thanks, Sven :)

I understood that there are many vulnerabilities out there but even the most common code examples we read, copy and even run out there were not safe enough.

Kein system ist sicher!

Before starting I would like to suggest taking a look at CWE-943: Improper Neutralization of Special Elements in Data Query Logic to understand what is NoSQL injection and how it related to MongoDB.

You may have read my level-up advice for development environment setup post, here is another database with docker-compose:

version: '3'

services:
  database:
    image: mongo
    ports:
      - "27017:27017"

Run MongoDB without authentication, only for experimental purposes, please activate authentication for production!

I will use MongoDB Compass GUI to show a little bit about MongoDB queries.

I have a document - not a table in NoSQL we call it a document not the same but closest naming - called users.

This is how it looks like as I am not filtering any data:

I would like to filter Jane Smith with email and the query will be:
{ $where: "this.email == 'janesmith@example.com'" }.

So far:

• We know how to write a MongoDB Query.

• We know how to filter documents.

As you can see from the query there is a comparison and when the expression for the MongoDB operator $where evaluates to true the data will be accessed.

We will be replacing the email address of Jane Smith with: '||'true to escape from the original query and force every $where the operator is to be calculated as true.
The first single quote will create an empty string, which forces the email address to be compared to an empty string and will be evaluated as false. We also concatenated Logical OR and 'true' where the final expression will fallback to false || true.

{ $where: "this.email == 'janesmith@example.com'" }
{ $where: "this.email == ''||'true'" }

When you run the injected email value, you will obtain all data from the sample.users document as shown below:

So far I showed how to exploit a basic MongoDB query, you should know that this is not the only way to exploit it. For this post, I will be focusing on this boolean-based injection payload.

Let's create a MongoDB-Express application to have a real-life example:

const express = require('express');
const mongoose = require('mongoose');

const app = express();

const mongoURL = 'mongodb://localhost:27017/sample'; 

const userSchema = new mongoose.Schema({
    name: String,
    email: String,
    admin: Boolean
});

const User = mongoose.model('User', userSchema);

async function connectToDatabase() {
    try {
        await mongoose.connect(mongoURL, {
            useNewUrlParser: true,
            useUnifiedTopology: true
        });
        console.log('Connected to MongoDB');
    } catch (err) {
        console.error('Failed to connect to MongoDB:', err);
        process.exit(1);
    }
}

app.get('/', (req, res) => {
    res.send('Running MongoDB with Node.js');
});

app.get('/users', async (req, res) => {
    await connectToDatabase();

    const email = req.query.email;

    try {
        const query = { $where: `this.email == '${email}'` };
        const users = await User.find(query);
        if ( users.length === 0 ) {
            res.status(404).json({ error: 'User not found' });
            return;
        }
        res.status(200).json(users);
    } catch (err) {
        console.error('Failed to retrieve users:', err.message);
        console.group('Stack trace');
        console.error(err);
        console.groupEnd();
        res.status(500).json({ error: 'Internal server error' });
    }
});

app.listen(3000, () => {
    console.log('Server is running on port 3000');
});

For this application we will have an endpoint:

• http://localhost:3000/users?email=janesmith@example.com will return "User not found" error.

• http://localhost:3000/users?email=%27%7C%7C%27true will return all of the data from users document

The decoded query value %27%7C%7C%27true is equal to '||'true. Browsers will decode automatically.

Let's focus on the code:
We are assigning email variable with this line:
const email = req.query.email; Here is the first mistake most developers do. We are getting data from outside of the application, users, customers, frontend whatever you call it. We should sanitize the data to be sure it is ready to be used.
There are some libraries to sanitize the data, for Express we can use mongo-sanitize. Basically, we need to escape from the special characters before executing database queries. If we sanitize the boolean injection payload the query and the result will be like:

Here is another suggestion for this case lets take a look at query construction:

const query = { $where: `this.email == '${email}'` };

We are using single quotes for email value and it results in queries below:

{ $where: "this.email == 'janesmith@example.com'" }
{ $where: "this.email == ''||'true'" }

However, we could escape by using backticks to avoid injection payloads:

{ $where: "this.email == `janesmith@example.com`" }
{ $where: "this.email == `'||'true`" }

To conclude we are sanitizing inputs and using default query methods advised to avoid injections.

const email = sanitize(req.query.email); // Sanitize input to avoid NoSQL injection
try {
    const users = await User.find({ email }); // use default query options to avoid NoSQL injection
    if ( users.length === 0 ) {
        res.status(404).json({ error: 'User not found' });
        return;
    }
    res.status(200).json(users);
} catch (err) {

I wanted to draw attention to the importance of writing secure code, as it is susceptible to vulnerabilities. Vulnerabilities arise from the improper neutralization of special elements in data query logic. Attackers can exploit this weakness to manipulate queries, modify selection criteria, append unauthorized commands, or obtain unintended results. To mitigate the risk, developers must focus on implementing rigorous input validation and sanitization techniques for No/SQL Injections. By adopting secure coding practices, such as parameterized queries and proper input handling, developers can fortify MongoDB applications and protect against NoSQL injection attacks.

Thanks for reading so far! Thanks, Sven for exploiting!

Docker has revolutionized the way developers build, ship, and run applications. It provides a lightweight and portable environment for isolating applications and their dependencies. One of the powerful tools in the Docker ecosystem is Docker Compose, which allows you to define and manage multi-container applications. In this blog post, we will explore how to use Docker Compose for development, focusing on a simple example with a PostgreSQL database and a Redis cache.

I have been working with these tricks to avoid problems like slow connection to remote databases, clean install, forgetting the passwords etc. Let's start!

Make sure you have Docker and Docker Compose installed on your machine.

$ docker -v
> Docker version 24.0.2, build cb74dfcd85 
$ docker-compose -v
> Docker Compose version v2.12.1

Docker Compose comes bundled with Docker Desktop for Windows and macOS, while Linux users can install it separately. Once you have everything set up, create a new directory for your project and navigate into it.

Defining the Docker Compose File: In your project directory, create a file called docker-compose.yml and open it in a text editor. This file will contain the configuration for your Docker Compose environment. Start by specifying the version at the top of the file:

Let's define the services we want to run using Docker Compose. In our example, we'll have two services: a PostgreSQL database and a Redis cache. Add the following code to your docker-compose.yml file:

version: '3'

services:
  db:
    image: postgres:latest
    restart: always
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    environment:
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: postgres
        POSTGRES_DB: postgres

  redis:
    image: redis:latest
    restart: always
    ports:
      - "6379:6379"

Explanation:

• The db service is based on the latest PostgreSQL image. We specify that it should always restart and mount a local directory (./postgres-data) as the data volume for persistent storage.

• Port 5432 on the host machine is mapped to port 5432 on the db service container, allowing us to access the PostgreSQL database externally.

• Environment variables are set to configure the PostgreSQL instance.

• The redis service is based on the latest Redis image. It also restarts automatically, and port 6379 on the host machine is mapped to port 6379 on the redis service container.

Save the docker-compose.yml file and return to your terminal. To start the defined services, use the following command in your project directory:

$ docker-compose up
$ # docker-compose up --build -d

Docker Compose will download the necessary images (if not already present) and start the containers. You'll see the output from each service, and you can monitor their logs in real-time.

Accessing the Services: With the services up and running, you can access them from your development environment. For example, you can connect to the PostgreSQL database using your preferred database client and the following connection details:

• Host: localhost

• Port: 5432

• Username: postgres

• Password: postgres

Similarly, you can connect to the Redis cache using localhost and port 6379.

To verify connectivity, you can use the following URLs:

• Redis: redis://localhost:6379

• PostgreSQL: postgresql://postgres:postgres@localhost:5432/postgres

These URLs can be directly used in your application code or database clients to establish connections with the Redis and PostgreSQL databases. Make sure that the Docker Compose services are running, and then test the connections. If you encounter any connection errors, double-check the URLs and ensure that the services are running correctly. Verifying connectivity at this stage will help ensure smooth development without any connectivity issues.

Docker Compose is a powerful tool for managing multi-container applications in a development environment. It simplifies the setup and configuration of complex application stacks, allowing developers to focus on building their applications rather than managing dependencies. In this blog post, we explored a simple example with a PostgreSQL database and a Redis cache, but Docker Compose can be used for a wide range of application architectures.

Take care of your health!