Validacion de Certificado Deshabilitada
Deshabilitar la validacion de certificados TLS con NODE_TLS_REJECT_UNAUTHORIZED=0 o rejectUnauthorized: false permite ataques man-in-the-middle en todas las conexiones HTTPS.
Cómo Funciona
La validacion de certificados TLS asegura que cuando tu aplicacion se conecta a api.stripe.com, realmente esta hablando con Stripe y no con un atacante interceptando la conexion. Cuando los desarrolladores encuentran errores de certificado durante el desarrollo (certs autofirmados, certs expirados, hostname mismatches), frecuentemente deshabilitan la validacion completamente con NODE_TLS_REJECT_UNAUTHORIZED=0 o rejectUnauthorized: false. Si esto llega a produccion, cualquier atacante en la misma red puede realizar un ataque man-in-the-middle. Presentan su propio certificado, la aplicacion lo acepta sin cuestionarlo, y todo el trafico HTTPS — incluyendo API keys, credenciales de usuario y datos de pago — es legible por el atacante. Esto es especialmente peligroso en entornos cloud donde el trafico de red pasa por infraestructura compartida.
// Disabling TLS validation globally
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';
// Or per-request
const https = require('https');
const agent = new https.Agent({ rejectUnauthorized: false });
fetch('https://api.stripe.com/v1/charges', { agent });// For self-signed certs in dev, add the CA certificate
const https = require('https');
const fs = require('fs');
const agent = new https.Agent({
ca: fs.readFileSync('certs/dev-ca.pem'),
rejectUnauthorized: true
});
// In production, use default validation (rejectUnauthorized defaults to true)
fetch('https://api.stripe.com/v1/charges');Ejemplo Real
En 2014, investigadores encontraron que el 33% de las apps Android usando HTTPS habian deshabilitado la validacion de certificados, haciendolas vulnerables a ataques man-in-the-middle. Multiples apps bancarias fueron afectadas. El mismo patron se ha encontrado en aplicaciones Node.js donde NODE_TLS_REJECT_UNAUTHORIZED=0 fue establecido como un fix rapido durante desarrollo y nunca se removio.
Cómo Prevenirlo
- Nunca establezcas NODE_TLS_REJECT_UNAUTHORIZED=0 en ningun entorno
- Para desarrollo con certs autofirmados, agrega el certificado CA al agent en su lugar
- Usa reglas de ESLint para detectar y bloquear rejectUnauthorized: false en el codigo
- Audita variables de entorno y scripts de inicio buscando configuraciones de bypass de TLS antes del despliegue
Tecnologías Afectadas
Data Hogo detecta esta vulnerabilidad automáticamente.
Escanea Tu Repo GratisVulnerabilidades Relacionadas
Modo ECB
mediumUsar modo ECB (Electronic Codebook) para encriptacion produce bloques de texto cifrado identicos para bloques de texto plano identicos, revelando patrones en los datos encriptados.
IV/Nonce Estatico
highUsar un Vector de Inicializacion (IV) o nonce hardcodeado o constante para encriptacion anula el proposito del IV y permite a los atacantes detectar patrones y desencriptar datos.
Tamano de Llave Debil
mediumUsar llaves criptograficas mas cortas que los minimos recomendados (RSA menor a 2048 bits, AES menor a 128 bits) hace la encriptacion vulnerable a ataques de fuerza bruta con hardware moderno.
PRNG Debil para Seguridad
highUsar Math.random() o Date.now() para generar tokens, IDs de sesion o codigos de reset produce valores predecibles que los atacantes pueden adivinar o reproducir.