Por qué JSON.stringify no es tan inofensivo como parece
Los desarrolladores usan JSON.stringify a diario para serializar datos, enviar objetos por cable, almacenar el estado en archivos o persistir configuraciones. Sin embargo, esta llamada aparentemente inofensiva a JSON.stringify puede provocar una deserialización insegura si los datos se rehidratan posteriormente sin validación.
El problema no es JSON. stringify en sí, sino cómo lo usamos mal. Al serializar objetos complejos (especialmente con prototipos o instancias de clase) y deserializarlos ciegamente después usando JSON. analizar, corre el riesgo de introducir cargas maliciosas en su aplicación.
En JavaScript, es fácil asumir que lo que se serializa es seguro porque es "simplemente JSONPero JSON son datos, no lógica. Si los atacantes controlan esos datos, pueden explotar los límites de confianza en tu código. Aquí es donde comienza la deserialización insegura.
Errores comunes de los desarrolladores que permiten una deserialización insegura
La deserialización insegura suele deberse a hábitos que parecen inofensivos en las revisiones de código. Pero cuando JSON.stringify se usa de forma descuidada, La superficie de ataque se expande.
Práctica insegura: serializar entradas de usuario no validadas
⚠️Advertencia: Este patrón serializa la entrada controlada por el atacante sin validación. Puede provocar una deserialización insegura si posteriormente se confía en los datos.
// Node.js example
const userData = req.body; // attacker-controlled
fs.writeFileSync('userdata.json', JSON.stringify(userData));
⚠️Advertencia: Deserializar los mismos datos sin validación puede reintroducir la carga útil en su aplicación.
const input = JSON.parse(fs.readFileSync('userdata.json'));
doSomething(input); // Trusting it blindly
Patrón peligroso: reutilización de JSON a través de límites de confianza
El JSON serializado creado en un servicio (entorno de desarrollo) se reutiliza en otro (entorno de producción) sin validación. Esto suele ocurrir en herramientas internas o microservicios.
Ejemplo de Python de riesgo silencioso:
⚠️Advertencia: Los pasos de serialización y deserialización a continuación manejan datos potencialmente no confiables sin validación.
import json
def save_user_input(data):
with open('input.json', 'w') as f:
f.write(json.dumps(data))
def process_input():
with open('input.json') as f:
data = json.loads(f.read())
execute_logic(data) # Dangerous if data structure is assumed
Ambos ejemplos serializan y deserializan datos controlados por el usuario sin la aplicación del esquema. Esto crea un caldo de cultivo para exploits de deserialización inseguros, provocados por el uso descuidado de JSON. stringify.
Riesgos reales en Pipelines: Del código a CI/CD Flujos de deserialización
Ahora tomemos ese comportamiento en serio. pipeline. Cuando se hace un mal uso de JSON.stringify en CI/CD En los flujos de trabajo, expones tu proceso de compilación a riesgos de deserialización inseguros. Esto suele ocurrir con metadatos de artefactos, accesorios de prueba e instantáneas de configuración.
Sus preguntas CI/CD trampas:
- Generación de artefactos insegura: los artefactos de compilación incluyen objetos serializados que se reutilizan en diferentes trabajos sin validación.
- Variables de entorno serializadas: los equipos almacenan variables de entorno como JSON serializado y las reutilizan en pasos o incluso proyectos.
- Datos de prueba inyectados: datos de prueba deserializados de fuentes no confiables commits o ramas ejecutadas sin verificación de tipo.
Estos patrones facilitan que los atacantes inyecten cargas útiles en sitios confiables. pipelines usando lógica de cadena JSON manipulada.
⚠️Advertencia:Este flujo de trabajo pasa datos serializados sin validación. Si test-runner.js no valida la entrada, se corre el riesgo de una deserialización insegura.
# YAML example in GitHub Actions
steps:
- name: Load test data
run: |
echo '${{ Secretos.TEST_JSON }}' > test.json
node test-runner.js test.jsonIf test-runner.js carga y analiza JSON sin validación, puede desencadenar una deserialización insegura.
Protección de JSON. stringify con validación y análisis seguro
La solución no es evitar JSON.stringify, sino usarlo con cuidado y aplicar comprobaciones de seguridad consistentemente. Si se maneja correctamente, es seguro, pero en la era moderna... pipelines, las suposiciones se rompen rápidamente.
Prácticas de DevSecOps para proteger JSON.stringify:
- Utilice esquemas JSON para validar datos serializados y deserializados.
- Aplicar una tipificación estricta, evitar la tipificación de pato o suposiciones sobre las formas de los objetos.
- Utilice bibliotecas de análisis seguro que admitan la aplicación de esquemas o protecciones de tipos.
- Trate los datos serializados como no confiables, incluso si provienen de un repositorio confiable.
- Ciclo de pipelines para detectar patrones JSON.stringify riesgosos de forma temprana.
Práctica recomendada: Este ejemplo utiliza la validación del esquema JSON para evitar la deserialización insegura. Ejemplo que utiliza ajv en Node.js:
const Ajv = require("ajv");
const ajv = new Ajv();
const schema = { type: "object", properties: { id: { type: "number" } }, required: ["id"] };
const validate = ajv.compile(schema);
const input = JSON.parse(fs.readFileSync('input.json'));
if (!validate(input)) throw new Error("Invalid input");
La deserialización segura significa validar antes Confianza. No dependas de JSON. Define valores predeterminados para mantenerte seguro; define cómo se ve la seguridad.
Detección de riesgos de serialización con Xygeni
La auditoría manual sólo detecta una parte de la información. xygeni brinda visibilidad sobre cómo se utiliza JSON.stringify en su base de código y pipelines.
Qué hace Xygeni:
- Traces JSON.stringify Uso desde el código fuente hasta la implementación.
- Detecta flujos de deserialización inseguros, especialmente en microservicios y pipeline etapas
- Marca la serialización de datos no seguros, como variables de entorno, entradas de usuario o artefactos.
- Alertas sobre desviaciones de patrones, que muestran cuando los datos serializados cambian de forma o cruzan los límites de confianza.
Este tipo de visibilidad es fundamental cuando se trata de riesgos de deserialización insegura introducidos por JSON.stringify, especialmente en CI/CD sistemas donde los datos serializados se mueven rápida y silenciosamente.
Asegurando JSON. stringify: Su escudo contra la deserialización insegura
JSON.stringify no es inseguro por sí mismo. Pero si se usa sin precaución, se convierte en la puerta de entrada a una deserialización insegura.
Si eres un desarrollador que trabaja con JSON:
- Audite su uso en todos los servicios. pipeliney herramientas.
- Tratar los datos deserializados como no confiables.
- Aplique la validación de esquemas, aplique tipos e integre la seguridad en sus CI/CD.
Y no se detenga en las mejores prácticas, use Xygeni para rastrear, detectar y detener los riesgos de deserialización insegura antes de que lleguen a producción. La serialización no es neutral. Haz uso de JSON. convertir en cadena asegurar.
