Questão de Segurança da Informação — Práticas de Segurança e Ameaças em Programação — CESPE / CEBRASPE 2024

Programação defensiva e validação de entradas

✅ CERTO. A programação defensiva é uma abordagem de desenvolvimento de software que pressupõe que o sistema será alvo de entradas inesperadas ou maliciosas, e a validação e sanitização de entradas são práticas centrais dessa abordagem, pois impedem que dados maliciosos sejam processados e explorem vulnerabilidades como injeção de código. Essa é uma diretriz amplamente reconhecida em boas práticas de desenvolvimento seguro, incluindo as recomendações da norma ABNT NBR ISO/IEC 27002.

A programação defensiva parte de uma premissa simples: nunca confie em dados externos. Todo dado que entra no sistema — vindo de um formulário web, de uma API, de um arquivo, de um banco de dados ou de qualquer outra fonte — deve ser tratado como potencialmente hostil até que se prove o contrário. Essa desconfiança sistemática é o que diferencia a programação defensiva da programação tradicional, que muitas vezes assume que o usuário vai fornecer dados corretos e bem formatados.

A validação de entrada é o processo de verificar se os dados fornecidos atendem aos critérios esperados: tipo correto (número, texto, data), tamanho máximo, formato específico (e-mail, CPF, CEP) e faixa de valores aceitáveis. Já a sanitização (ou higienização) é o processo de limpar ou transformar os dados para remover ou neutralizar conteúdo potencialmente perigoso, como caracteres especiais que poderiam ser interpretados como código (por exemplo, <script> em uma página web ou ' OR '1'='1 em uma consulta SQL).

A importância dessas práticas fica evidente quando observamos os ataques mais comuns em aplicações web. O OWASP Top 10, uma das referências mais respeitadas em segurança de aplicações, lista a injeção (SQL Injection, XSS, etc.) como uma das categorias de risco mais críticas. A causa raiz desses ataques é justamente a falta de validação e sanitização adequada das entradas. Por exemplo, um ataque de SQL Injection ocorre quando um campo de entrada é concatenado diretamente em uma consulta SQL sem validação, permitindo que o atacante manipule a consulta para acessar ou modificar dados não autorizados.

A norma ABNT NBR ISO/IEC 27002, que é um código de prática para controles de segurança da informação, recomenda explicitamente a validação e sanitização de entradas como parte do desenvolvimento seguro de software. O contexto de apoio reforça essa diretriz ao afirmar que a norma recomenda "validar e sanitizar todas as entradas de dados, tanto no lado do cliente quanto no lado do servidor, para evitar injeções e outras vulnerabilidades".

ABNT NBR ISO/IEC 27002:

Recomenda-se validar e sanitizar todas as entradas de dados, tanto no lado do cliente quanto no lado do servidor, para evitar injeções e outras vulnerabilidades.

É importante destacar que a validação deve ser feita no servidor, e não apenas no cliente. A validação no lado do cliente (JavaScript) é apenas para melhorar a experiência do usuário, pois o atacante pode facilmente desativar o JavaScript ou usar ferramentas como Postman ou Burp Suite para enviar requisições diretamente ao servidor, ignorando a validação client-side. Portanto, a validação no servidor é a única que realmente protege o sistema.

A pegadinha que a banca poderia explorar aqui é a confusão entre validação de entrada e outras práticas de segurança, como criptografia ou controle de acesso. Mas a afirmação do enunciado é precisa: a programação defensiva inclui a validação e sanitização de entradas para prevenir que dados maliciosos sejam processados. Isso está perfeitamente alinhado com as boas práticas de desenvolvimento seguro.

✅ CERTO.