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

Criptografia em banco de dados e injeção de SQL

❌ ERRADO. A criptografia automática de dados em repouso no banco de dados não garante, por si só, que os dados recuperados estejam imunes à captura indevida em caso de falha de injeção de SQL. Isso ocorre porque, ao serem recuperados para uso pela aplicação, os dados são descriptografados, tornando-se legíveis e, portanto, vulneráveis a uma consulta maliciosa que explore a falha de injeção. A criptografia protege os dados em repouso, mas não é uma defesa contra a exploração de vulnerabilidades na camada de aplicação, como a injeção de SQL.

A criptografia é uma técnica fundamental para proteger a confidencialidade dos dados, mas sua eficácia depende de como e onde é aplicada. Quando um aplicativo armazena dados criptografados em um banco de dados, a proteção se concentra em impedir que alguém que acesse diretamente os arquivos do banco ou faça uma cópia não autorizada consiga ler as informações. No entanto, para que o aplicativo possa processar e exibir esses dados ao usuário, eles precisam ser descriptografados em algum momento. Esse processo de descriptografia ocorre, geralmente, na camada de aplicação ou no próprio banco de dados, e é nesse ponto que a vulnerabilidade de injeção de SQL pode ser explorada.

A injeção de SQL é uma técnica de ataque que explora falhas na validação de entradas do usuário para executar comandos SQL maliciosos no banco de dados. Se um atacante conseguir explorar essa falha, ele pode, por exemplo, executar uma consulta que retorne os dados descriptografados, contornando a proteção oferecida pela criptografia. A criptografia não impede que uma consulta SQL maliciosa seja executada; ela apenas protege os dados quando estão armazenados de forma cifrada. Uma vez que a consulta é executada e os dados são descriptografados para serem retornados, eles ficam expostos.

Para ilustrar, imagine um sistema que armazena números de cartão de crédito criptografados. Se o sistema tiver uma falha de injeção de SQL, um atacante pode enviar uma entrada maliciosa que faça o banco de dados retornar os números de cartão de crédito já descriptografados, pois a aplicação precisa deles em texto claro para funcionar. A criptografia, nesse caso, não oferece proteção contra a exploração da falha de injeção, pois o atacante está explorando a lógica da aplicação, não o armazenamento físico dos dados.

A distinção crucial é entre proteger os dados em repouso (armazenados) e proteger os dados em uso (processados pela aplicação). A criptografia protege os dados em repouso, mas não os dados em uso. Para proteger contra injeção de SQL, é necessário implementar outras medidas, como o uso de consultas parametrizadas (prepared statements), validação e sanitização de entradas, e o princípio do menor privilégio no acesso ao banco de dados. A criptografia é uma camada de defesa importante, mas não é uma solução completa para todas as ameaças.

A banca explora aqui a confusão entre proteger dados em repouso e proteger dados em uso. O candidato pode ser levado a acreditar que a criptografia é uma proteção abrangente, mas ela não impede a exploração de vulnerabilidades na aplicação. A resposta correta é ERRADO, pois a criptografia automática não garante a imunidade dos dados recuperados contra captura indevida em caso de falha de injeção de SQL.

Gabarito: letra E (Errado).