Como resolvi a vulnerabilidade de SQL Injection hoje...

E aí, devs! Hoje precisava solucionar alguns pontos de vulnerabilidade de SQL injection de um resultado de pentest. O teste fazia uma simulação de alterar o payload da request e colocava um HTML e um script no meio desses dados e alterar todo o e-mail que ia ser disparado.

• Mudava toda a conversa original do e-mail.
• Escondia as partes que realmente importavam.
• colocava uns links fakes para phishing, fazendo parecer que são os links de verdade.

Para solucionar isso fiz um middleware em Node.js no nosso projeto para validar e sanitizar todos os dados no backend antes de serem usados:

1. Pega os Dados da Requisição: Primeiro, ele pega os dados que vieram na bagagem da requisição web, especificamente do corpo body dela. É dali que ele espera tirar informações como um pacote de dados do usuário userInputPayload, uma dica para o assunto do e-mail emailSubjectHint, o link principal mainLink e o link da imagem da marca brandImageUrl.
2. Verificação Essencial: Ele confere se o userInputPayload (que é onde devem estar os detalhes do cliente como nome, e-mail, empresa, telefone, categoria de perfil e a origem do dado) realmente veio e se é um objeto válido. Se não, já corta o mal pela raiz e avisa que tá faltando coisa.
3. Prepara as Ferramentas de Checagem (Regex): O "segurança" usa algumas expressões regulares para poder inspecionar os dados:

• Uma regex é especialista em farejar caracteres perigosos (tipo <, >, /, ', ", ;, =), aqueles que são a porta de entrada pra HTML injection.
• Outra regex é focada em garantir que o formato do e-mail (clientEmail) esteja correto.
• E uma terceira cuida de verificar se as URLs fornecidas para o mainLink e brandImageUrl seguem o padrão esperado (com protocolo, domínio, etc.).
• Inspeção Campo a Campo: Com as ferramentas em mãos, ele passa um pente fino em cada informação:
• Dados como nome do cliente (clientName), organização (clientOrg), categoria de perfil (profileCategory), tag de origem do dado (dataSourceTag) e telefone (clientPhone) são checados contra a regex de caracteres perigosos.
• O e-mail do cliente (clientEmail) tem seu formato validado pela regex específica para e-mails.
• Os campos emailSubjectHint, mainLink e brandImageUrl são opcionais. Se eles não vierem, tudo bem. Mas se vierem, também passam pela checagem: emailSubjectHint contra caracteres perigosos, e mainLink e brandImageUrl contra a regex de URLs.

4. Decisão Final:

• Algo errado? Bloqueia! Se qualquer um desses campos não passar na inspeção, o "segurança" impede a continuação do processo. Ele manda uma resposta de erro (um 400 Bad Request), avisando que os dados estão inválidos ou contêm caracteres não permitidos. Isso evita que dados "contaminados" sigam adiante.
• Tudo certinho? Pode passar! Se todos os dados estiverem limpinhos e válidos, o "segurança" dá sinal verde, e a requisição continua seu fluxo normal para o próximo passo, que seria, por exemplo, a lógica de montar e enviar o e-mail.
• Essa abordagem ajuda a garantir que apenas dados seguros e bem formatados sejam usados, diminuindo drasticamente o risco de injeções de HTML.