Por que JSON.stringify não é tão inofensivo quanto parece
Desenvolvedores usam JSON. stringify todos os dias para serializar dados, enviar objetos pela rede, armazenar estados em arquivos ou persistir configurações. Mas essa chamada aparentemente inofensiva para JSON. stringify pode introduzir uma desserialização insegura se os dados forem posteriormente reidratados sem validação.
O problema não é o JSON. stringify em si, mas sim como o utilizamos incorretamente. Quando você serializa objetos complexos (especialmente com protótipos ou instâncias de classe) e os desserializa cegamente mais tarde usando JSON. analisar, você corre o risco de dar vida a cargas maliciosas dentro do seu aplicativo.
Em JavaScript, é fácil presumir que o que é serializado é seguro porque é “apenas JSON.” Mas JSON são dados, não lógica. Se invasores controlarem esses dados, eles poderão explorar os limites de confiança do seu código. É aqui que começa a desserialização insegura.
Erros comuns de desenvolvedores que permitem desserialização insegura
A desserialização insegura geralmente decorre de hábitos que parecem inofensivos em revisões de código. Mas quando JSON.stringify é usado de forma descuidada, a superfície de ataque se expande.
Prática insegura: serializar entradas de usuários não validadas
⚠️Atenção: Esse padrão serializa a entrada controlada pelo invasor sem qualquer validação. Pode levar a uma desserialização insegura se os dados forem posteriormente considerados confiáveis.
// Node.js example
const userData = req.body; // attacker-controlled
fs.writeFileSync('userdata.json', JSON.stringify(userData));
⚠️Atenção: Desserializar os mesmos dados sem validação pode reintroduzir a carga útil no seu aplicativo.
const input = JSON.parse(fs.readFileSync('userdata.json'));
doSomething(input); // Trusting it blindly
Padrão perigoso: Reutilização de JSON além dos limites de confiança
JSON serializado criado em um serviço (ambiente de desenvolvimento) é reutilizado em outro (produção), sem validação. Isso geralmente acontece em ferramentas internas ou microsserviços.
Exemplo em Python de risco silencioso:
⚠️Atenção: As etapas de serialização e desserialização abaixo manipulam dados potencialmente não confiáveis sem validação.
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 os exemplos serializam e desserializam dados controlados pelo usuário sem a imposição de esquema. Isso cria um ambiente propício para exploits de desserialização inseguros, desencadeados pelo uso descuidado de JSON. stringify.
Riscos reais em Pipelines: Do Código para CI/CD Fluxos de desserialização
Agora leve esse comportamento para um pipeline. Quando JSON. stringify é mal utilizado dentro CI/CD fluxos de trabalho, você expõe seu processo de construção a riscos de desserialização inseguros. Isso geralmente acontece com metadados de artefatos, acessórios de teste e instantâneos de configuração.
comum CI/CD armadilhas:
- Geração de artefatos insegura: artefatos de construção incluem objetos serializados que são reutilizados em trabalhos sem validação.
- Variáveis de ambiente serializadas: as equipes armazenam variáveis de ambiente como JSON serializado e as reutilizam em etapas ou até mesmo em projetos.
- Dados de teste injetados: Dados de teste desserializados de não confiáveis commits ou ramificações executadas sem verificação de tipo.
Esses padrões facilitam a injeção de cargas úteis por invasores em redes confiáveis pipelines usando lógica de string JSON manipulada.
⚠️Atenção:Este fluxo de trabalho transmite dados serializados sem validação. Se o test-runner.js não validar a entrada, corre o risco de desserialização insegura.
# YAML example in GitHub Actions
steps:
- name: Load test data
run: |
echo '${{ secrets.TEST_JSON }}' > test.json
node test-runner.js test.json
If test-runner.js carrega e analisa JSON sem validação, pode disparar uma desserialização insegura.
Protegendo JSON. stringify com validação e análise segura
A solução não é evitar o JSON. stringify, mas usá-lo com cuidado e aplicar verificações de segurança consistentemente. Se manuseado corretamente, é seguro, mas em ambientes modernos pipelines, as suposições quebram rapidamente.
Práticas DevSecOps para proteger JSON.stringify:
- Use esquemas JSON para validar dados serializados e desserializados.
- Aplique uma digitação rigorosa, evite digitações aleatórias ou suposições sobre formas de objetos.
- Use bibliotecas de análise segura que suportem imposição de esquema ou proteções de tipo.
- Trate dados serializados como não confiáveis, mesmo que tenham vindo de um repositório confiável.
- Instrumento pipelines para detectar padrões JSON.stringify arriscados precocemente.
Prática recomendada: Este exemplo usa validação de esquema JSON para evitar desserialização insegura. Exemplo usando ajv em 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");
A desserialização segura significa validar antes Confiável. Não confie em JSON. Use strings como padrão para manter sua segurança; defina o que é segurança.
Detectando riscos de serialização com Xygeni
A auditoria manual só detecta até certo ponto. Xygeni traz visibilidade sobre como JSON.stringify é usado em sua base de código e pipelines.
O que a Xygeni faz:
- Traços JSON.stringify uso do código-fonte até a implantação.
- Detecta fluxos de desserialização inseguros, especialmente em microsserviços e pipeline estágios.
- Sinaliza a serialização de dados não seguros, como variáveis de ambiente, entrada do usuário ou artefatos.
- Alertas sobre desvios de padrão, mostrando quando dados serializados mudam de forma ou cruzam limites de confiança.
Este tipo de visibilidade é crítico ao lidar com riscos de desserialização inseguros introduzidos por JSON.stringify, especialmente em CI/CD sistemas onde dados serializados se movem de forma rápida e silenciosa.
Protegendo JSON. stringify: Seu Shield Contra a desserialização insegura
JSON.stringify não é inseguro por si só. Mas, quando usado sem cautela, torna-se a porta de entrada para a desserialização insegura.
Se você é um desenvolvedor trabalhando com JSON:
- Audite seu uso em todos os serviços, pipelinee ferramentas.
- Trate dados desserializados como não confiáveis.
- Aplique validação de esquema, imponha tipos e integre segurança em seu CI/CD.
E não pare nas melhores práticas, use o Xygeni para rastrear, detectar e interromper riscos de desserialização inseguros antes que eles cheguem à produção. A serialização não é neutra. Faça uso dela JSON. stringificar seguro.
