Insecure Deserialization in Restify with Mutual Tls

Insecure deserialization occurs when an application processes untrusted serialized objects without sufficient validation. In a Restify service that uses Mutual TLS (mTLS), the presence of mTLS is often assumed to provide sufficient transport-layer security, which can lead to insecure deserialization being overlooked. mTLS ensures that both client and server authenticate each other with certificates, but it does not prevent a malicious authenticated client from sending crafted serialized payloads that exploit deserialization logic.

In Restify, common practices include accepting JSON, MessagePack, or other serialized formats via POST or PUT endpoints. If the server uses functions like JSON.parse on user-controlled input or, more dangerously, native deserialization modules (e.g., node-serialize, v8.deserialize, or custom class revivers), an attacker may achieve Remote Code Execution (RCE) or object injection. Real-world examples include gadget chains involving Buffer, setTimeout, or process in Node.js, which have been observed in the wild (e.g., CVE patterns involving prototype pollution leading to deserialization-style impacts). Even with mTLS, if the endpoint trusts the authenticated client’s payload structure and does not validate or sanitize the deserialized data, the server can be compromised.

An mTLS-enabled Restify endpoint might look like this in a vulnerable configuration:

const restify = require('restify');
const fs = require('fs');
const tls = require('tls');

const server = restify.createServer({
  tls: {
    cert: fs.readFileSync('server-cert.pem'),
    key: fs.readFileSync('server-key.pem'),
    ca: [fs.readFileSync('ca-cert.pem')],
    requestCert: true,
    rejectUnauthorized: true
  }
});

server.post('/import', (req, res, next) => {
  // Vulnerable: direct deserialization of user input
  const data = JSON.parse(req.post()); // or similar custom reviver
  // Process data without schema validation
  res.send({ received: data });
  return next();
});

server.listen(8080, () => console.log('Listening'));

In this setup, mTLS ensures only clients with a trusted certificate can connect, but the endpoint still parses the request body unsafely. An authenticated client can send a malicious serialized object that, when deserialized, triggers unintended behavior. This highlights that transport security (mTLS) and application-level deserialization safety are separate concerns; one does not substitute the other.

To align with checks like those in middleBrick’s 12 security checks — which include Input Validation and Unsafe Consumption — you must validate and sanitize all incoming serialized data, enforce strict schemas, and avoid native deserialization of untrusted sources. middleBrick’s scans can surface such insecure deserialization findings within the Input Validation and Unsafe Consumption categories, providing severity and remediation guidance to help you reduce risk.

Remediation focuses on ensuring that mTLS is correctly configured for client authentication and that the application does not trust deserialized data simply because the transport is secured. Follow these concrete steps for a Restify service:

• Enforce mTLS with explicit certificate validation: require client certificates and verify them against a trusted CA.
• Never deserialize user-controlled input using native or dynamic revivers; prefer schema-based parsing (e.g., JSON Schema) and strict type checks.
• Apply the principle of least privilege to authenticated clients and monitor for anomalous payloads, which middleBrick’s Continuous Monitoring can help detect via Pro plan scanning.

Secure Restify example with proper mTLS and safe parsing:

const restify = require('restify');
const fs = require('fs');

const server = restify.createServer({
  tls: {
    cert: fs.readFileSync('server-cert.pem'),
    key: fs.readFileSync('server-key.pem'),
    ca: [fs.readFileSync('ca-cert.pem')],
    requestCert: true,
    rejectUnauthorized: true
  }
});

// Use a strict schema-based parser instead of raw JSON.parse
const Ajv = require('ajv');
const ajv = new Ajv();
const importSchema = {
  type: 'object',
  required: ['id', 'name'],
  properties: {
    id: { type: 'string', format: 'uuid' },
    name: { type: 'string', minLength: 1, maxLength: 100 }
  },
  additionalProperties: false
};
const validateImport = ajv.compile(importSchema);

server.post('/import', (req, res, next) => {
  let body;
  try {
    body = JSON.parse(req.payload); // req.payload is already a string
  } catch (e) {
    return res.send(400, { error: 'Invalid JSON' });
  }

  if (!validateImport(body)) {
    return res.send(400, { errors: validateImport.errors });
  }

  // Safe processing: use validated data
  res.send({ id: body.id, name: body.name });
  return next();
});

server.listen(8080, () => console.log('Listening'));

In this secure example:

• mTLS is enforced with requestCert: true and rejectUnauthorized: true, ensuring only clients with valid certificates can connect.
• The endpoint uses JSON.parse on req.payload (a string) and then validates the resulting object against a strict JSON Schema using Ajv. This prevents unexpected properties and ensures type safety.
• No native or dynamic revivers are used, mitigating gadget-chain risks. For production, rotate certificates and integrate certificate revocation checks, which aligns with middleBrick’s findings for Encryption and Data Exposure checks.

Using the middleBrick CLI (middlebrick scan <url>) or GitHub Action can help you detect insecure deserialization and TLS misconfigurations during development. The Pro plan enables continuous monitoring so that future changes to deserialization logic are caught early, and findings map to frameworks like OWASP API Top 10 and PCI-DSS.