Nosql Injection with Mutual Tls

Nosql injection attacks exploit insufficient input validation to manipulate database queries in NoSQL databases like MongoDB, Cassandra, or CouchDB. In Mutual TLS (mTLS) environments, these attacks can be particularly insidious because the encrypted channel creates a false sense of security while the application logic remains vulnerable.

The attack typically begins when an application accepts user input through mTLS-secured endpoints without proper sanitization. Consider a Node.js Express API using MongoDB that authenticates clients via mTLS:

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

const app = express();
app.use(express.json());

// mTLS configuration
const httpsOptions = {
  cert: fs.readFileSync('/path/to/server-cert.pem'),
  key: fs.readFileSync('/path/to/server-key.pem'),
  ca: fs.readFileSync('/path/to/ca-cert.pem'),
  requestCert: true,
  rejectUnauthorized: true
};

const server = https.createServer(httpsOptions, app);

// Vulnerable route
app.post('/api/users', (req, res) => {
  const { username, password } = req.body;
  
  // No input validation
  const query = { username: username, password: password };
  
  User.find(query, (err, results) => {
    if (err) return res.status(500).send(err);
    res.json(results);
  });
});

server.listen(3000, () => console.log('Server running on port 3000'));

The vulnerability emerges when attackers craft payloads that exploit MongoDB's query syntax. An attacker with valid mTLS certificates can send:

{
  "username": {"$ne": null},
  "password": {"$ne": null}
}

This payload uses MongoDB's $ne (not equals) operator to bypass authentication entirely, returning all users since all usernames and passwords are not equal to null. The mTLS encryption prevents network-level eavesdropping but does nothing to stop this logical manipulation.

More sophisticated attacks leverage mTLS's client certificate validation to target specific application logic. For example, an API might use certificate subject information to determine database collections:

app.get('/api/data', (req, res) => {
  const cert = req.connection.getPeerCertificate();
  const orgName = cert.subject.CN.split('.')[0]; // Extract org from CN
  
  const query = { company: orgName };
  Data.find(query, (err, results) => {
    if (err) return res.status(500).send(err);
    res.json(results);
  });
});

An attacker could manipulate the certificate's Common Name or exploit insufficient validation to access other organizations' data by crafting queries that use operators like $where for JavaScript injection:

{
  "$where": "this.company == 'targetOrg' || this.company == 'otherOrg'"
}

This bypasses the intended access control while the mTLS channel remains secure.

Detecting NoSQL injection in mTLS environments requires examining both the encrypted communication channel and the application's query construction logic. Traditional network monitoring tools cannot inspect mTLS traffic without access to private keys, making runtime detection critical.

middleBrick's scanning approach tests the unauthenticated attack surface by sending crafted payloads through the mTLS channel to observe database query behavior. The scanner identifies NoSQL injection by:

1. Sending operator-based payloads through mTLS-secured endpoints
2. Analyzing response patterns for signs of query manipulation
3. Checking for timing discrepancies that indicate database-level operations
4. Verifying proper error handling without information disclosure

For MongoDB-specific detection, middleBrick tests common injection patterns:

// Test for authentication bypass
{
  "username": {"$ne": ""},
  "password": {"$ne": ""}
}

// Test for object injection
{
  "username": "validUser",
  "password": {"$gt": ""}
}

// Test for JavaScript injection
{
  "$where": "sleep(1000) && this.username == 'test'"
}

The scanner monitors response times and content to identify successful injections. A response returning all users when querying for a specific username indicates a $ne operator bypass.

middleBrick's OpenAPI analysis complements runtime scanning by examining API specifications for parameter types that might allow injection. The tool cross-references spec definitions with actual runtime behavior, identifying mismatches where specifications suggest strict typing but implementations accept arbitrary objects.

Developers can also implement detection through application-level monitoring. Logging and alerting on unusual query patterns helps identify attacks in progress:

const mongoose = require('mongoose');

// Monkey-patch Mongoose to detect suspicious queries
const originalFind = mongoose.Query.prototype.find;

mongoose.Query.prototype.find = function(query) {
  if (typeof query === 'object') {
    const suspiciousKeys = ['$where', '$ne', '$gt', '$lt', '$regex'];
    const found = suspiciousKeys.some(key => key in query);
    
    if (found) {
      console.warn('Suspicious NoSQL query detected:', query);
      // Additional logging or alerting here
    }
  }
  
  return originalFind.call(this, query);
};

This runtime detection catches attempts to use MongoDB operators in places where they shouldn't appear, such as authentication credentials or search parameters.

Remediating NoSQL injection in mTLS environments requires defense in depth: secure mTLS configuration, input validation, and safe query construction. The mTLS layer ensures only authenticated clients can attempt attacks, but application logic must prevent successful exploitation.

Start with strict mTLS certificate validation. Configure the server to verify client certificates against a trusted CA and enforce certificate revocation checking:

const httpsOptions = {
  cert: fs.readFileSync('/path/to/server-cert.pem'),
  key: fs.readFileSync('/path/to/server-key.pem'),
  ca: fs.readFileSync('/path/to/ca-cert.pem'),
  requestCert: true,
  rejectUnauthorized: true,
  checkServerIdentity: (hostname, cert) => {
    // Additional hostname verification
    if (cert.subject.CN !== hostname) {
      throw new Error('Certificate subject does not match hostname');
    }
  }
};

Next, implement strict input validation using schema validation libraries. For MongoDB, use the built-in schema validation or a library like Joi to enforce expected data types:

const Joi = require('joi');

const loginSchema = Joi.object({
  username: Joi.string().min(3).max(50).required(),
  password: Joi.string().min(8).max(100).required()
});

app.post('/api/login', (req, res) => {
  const { error, value } = loginSchema.validate(req.body);
  if (error) {
    return res.status(400).json({ error: 'Invalid input format' });
  }
  
  // Safe query construction
  const query = {
    username: value.username,
    password: value.password
  };
  
  User.findOne(query, (err, user) => {
    if (err || !user) {
      return res.status(401).json({ error: 'Invalid credentials' });
    }
    res.json({ success: true, user });
  });
});

The schema validation prevents object-based injection by ensuring username and password are always strings, not objects with operators.

For database queries, use parameterized queries or ORM methods that automatically escape inputs. With Mongoose, use the query builder API instead of raw objects:

// Safe query construction
const query = User.where('username').equals(username)
  .where('password').equals(password);

query.exec((err, results) => {
  if (err) return res.status(500).send(err);
  res.json(results);
});

This approach ensures values are treated as literals, not query operators.

Implement application-level access controls that complement mTLS authentication. Use the certificate information to enforce data isolation:

app.get('/api/company-data', (req, res) => {
  const cert = req.connection.getPeerCertificate();
  const orgName = cert.subject.CN;
  
  // Validate organization name format
  if (!/^[a-zA-Z0-9-]+$/.test(orgName)) {
    return res.status(400).json({ error: 'Invalid organization format' });
  }
  
  // Safe query using whitelist approach
  const allowedCompanies = ['companyA', 'companyB', 'companyC'];
  if (!allowedCompanies.includes(orgName)) {
    return res.status(403).json({ error: 'Access denied' });
  }
  
  Data.find({ company: orgName }, (err, results) => {
    if (err) return res.status(500).send(err);
    res.json(results);
  });
});

This ensures that even if an attacker obtains a valid certificate, they cannot access data outside their authorized scope.

Finally, implement comprehensive logging and monitoring to detect injection attempts:

const mongoSanitize = require('mongo-sanitize');

app.use((req, res, next) => {
  const sanitizedBody = mongoSanitize(req.body);
  if (JSON.stringify(sanitizedBody) !== JSON.stringify(req.body)) {
    console.warn('Potential NoSQL injection attempt detected:', req.body);
    return res.status(400).json({ error: 'Invalid input detected' });
  }
  next();
});

The mongo-sanitize library removes MongoDB operators from input, preventing injection attempts while allowing legitimate data to pass through.