Prototype Pollution in Cassandra

Prototype Pollution is a JavaScript vulnerability where an attacker injects properties into existing Object prototypes, such as Object.prototype. While often discussed in frontend contexts, it becomes critical for backend Node.js applications that interact with databases like Apache Cassandra. The danger arises when an application merges untrusted user input (e.g., from HTTP requests) into objects that later influence database operations, security controls, or application logic.

In a Cassandra-backed Node.js service, this typically occurs when building CQL queries or configuration objects using unsafe merge patterns. Consider a common pattern where query parameters from a REST API are merged into a base query object before execution:

const baseQuery = { keyspace: 'app', table: 'users' };
// Attacker-controlled 'req.query'
const userParams = req.query; // e.g., { '__proto__': { 'admin': true } }

// VULNERABLE: merges user input directly
const finalQuery = Object.assign({}, baseQuery, userParams);

// Later, code might check for an 'admin' flag
if (finalQuery.admin) {
  // Grant admin privileges - now true due to prototype pollution
  cql.execute('SELECT * FROM app.users WHERE role = ?', ['admin']);
}

Here, the __proto__ key in userParams pollutes Object.prototype. The finalQuery object inherits admin: true, bypassing authorization checks. This is CWE-1321 (Improperly Controlled Modification of Object Prototype Attributes).

Another Cassandra-specific attack vector involves dynamic query construction where property names from input determine CQL clauses. An attacker could inject __proto__ or constructor.prototype to alter behavior:

function buildFilter(filterObj) {
  let cql = 'SELECT * FROM events';
  const params = [];
  for (const key in filterObj) {
    // If key is '__proto__', this adds a WHERE clause on a polluted property
    cql += ` WHERE ${key} = ?`;
    params.push(filterObj[key]);
  }
  return { cql, params };
}

// Malicious request: ?__proto__.isAdmin=true
const { cql } = buildFilter(req.query);
// Becomes: SELECT * FROM events WHERE isAdmin = ?
// If code elsewhere checks 'result.isAdmin', it may be true globally.

Cassandra’s lack of a fixed schema can exacerbate this; polluted properties might silently propagate through application logic or be mistaken for legitimate columns in result set processing. Real-world impact includes privilege escalation (BOLA/IDOR), data exfiltration via modified queries, or even remote code execution if the polluted object reaches a dangerous sink like eval() or a template engine (CVE-2022-33980 demonstrates similar chains in other Node.js ecosystems).

Detecting prototype pollution in Cassandra applications requires examining the code paths where untrusted input merges with objects used for query building, authorization, or configuration. Manual code review should focus on:

• Merge Operations: Look for Object.assign(), spread syntax ({...obj}), _.merge() (lodash), or custom recursive merge functions that incorporate request parameters (e.g., req.query, req.body, JWT payloads).
• Dynamic CQL Construction: Identify any string concatenation or template literals building CQL queries where property names originate from external input.
• Authorization Gates: Check if access control decisions (e.g., if (user.role === 'admin')) rely on object properties that could be polluted.

Automated scanning can assist but has limitations. Static analysis tools (ESLint rules like no-prototype-builtins or security linters) may flag risky merges but lack context about Cassandra integration. Dynamic scanning (like middleBrick) tests the runtime behavior by sending payloads containing prototype pollution vectors and observing effects in API responses or error messages. For example, middleBrick’s Input Validation and BOLA/IDOR checks include probes for prototype pollution by sending requests with __proto__ or constructor.prototype in JSON/query parameters and analyzing whether the application’s security posture changes (e.g., a user gains access to admin-only CQL queries).

When scanning a Cassandra API, middleBrick correlates findings with the OpenAPI spec (if provided) to identify parameters that flow into query construction. Its report highlights specific endpoints and parameters vulnerable to prototype pollution, mapping findings to OWASP API Top 10:API4:2023 – Unrestricted Resource Consumption (if pollution causes DoS) or API5:2023 – Broken Function Level Authorization.

However, detection is not foolproof; some pollution might only manifest in internal logic without external side effects. Therefore, combining tool scanning with targeted manual review of high-risk merge patterns in Cassandra query builders is essential.

Remediation centers on eliminating prototype pollution vectors and ensuring Cassandra query construction is immune to injected properties. The primary strategy is to never merge untrusted input directly into objects that influence security or database operations.

1. Use Whitelisting for Query Parameters: Instead of merging entire request objects, explicitly extract and validate allowed parameters. For Cassandra queries, map input to a predefined set of columns and operators.

// SAFE: Explicit whitelist
const allowedFilters = ['userId', 'timestamp', 'eventType'];
function buildSafeFilter(reqQuery) {
  const cqlParts = [];
  const params = [];
  for (const key of allowedFilters) {
    if (reqQuery[key] !== undefined) {
      cqlParts.push(`${key} = ?`);
      params.push(reqQuery[key]);
    }
  }
  const cql = cqlParts.length ? `SELECT * FROM events WHERE ${cqlParts.join(' AND ')}` : 'SELECT * FROM events';
  return { cql, params };
}

2. Use Parameterized Queries with Prepared Statements: The DataStax Node.js driver for Cassandra supports prepared statements, which separate CQL structure from data. This prevents property names from being interpreted as CQL syntax.

// SAFE: Prepared statement with bound parameters
const query = 'SELECT * FROM users WHERE email = ? AND status = ?';
const prepared = await session.prepare(query);
// Bind user-provided values safely (values array, not object merge)
const bound = prepared.bind([req.body.email, 'ACTIVE']);
const result = await session.execute(bound);

3. Object.create(null) for Prototype-Free Objects: If you must create an object from input (e.g., for mapping to a Cassandra row), use Object.create(null) to create an object with no prototype, eliminating inherited properties like __proto__.

// Create a prototype-less object for user input
const userInput = Object.create(null);
Object.assign(userInput, req.body); // Safe: no prototype chain

// Now userInput has no 'toString' or '__proto__' properties
const row = { id: uuid(), ...userInput }; // Spread is safe here
await session.execute('INSERT INTO users JSON ?', [JSON.stringify(row)]);

4. Library-Specific Safeguards: If using an ORM/query builder for Cassandra (e.g., cassandra-driver’s mapper or typeorm with Cassandra), consult its documentation for prototype pollution protections. Avoid any ORM methods that perform deep merging of user input into entity objects.

5. Runtime Prototype Pollution Detection: For defense-in-depth, add a startup check that tests if Object.prototype has been polluted (e.g., check for unexpected properties). This won’t prevent exploitation but can trigger alerts for investigation.

// Startup check
const unexpectedProto = Object.keys({}.__proto__).find(k => !['constructor', '__defineGetter__', ...].includes(k));
if (unexpectedProto) {
  console.error('Potential prototype pollution detected:', unexpectedProto);
  // Alert or fail startup
}

Finally, integrate security scanning early. Use middleBrick’s CLI in CI/CD to scan Cassandra APIs before deployment:

middlebrick scan https://api.example.com/v1/users --output json

This helps catch prototype pollution and other API risks (like BOLA or input validation issues) before code reaches production. Remediation guidance from middleBrick will point to the specific vulnerable parameter and suggest parameterized query patterns for Cassandra.