Alternativa Correta: D - utilizar parâmetros (prepared statements) para consultas SQL.

O tema central desta questão é a prevenção de injeções SQL em aplicações web. Injeções SQL são uma das principais vulnerabilidades de segurança em sistemas que interagem com bancos de dados. Essa técnica maliciosa ocorre quando um invasor consegue inserir ou "injetar" código SQL não autorizado nas consultas realizadas por uma aplicação, potencialmente comprometendo a segurança dos dados e integridade do sistema.

Para lidar com essa ameaça, a prática de utilizar prepared statements (ou consultas preparadas) é considerada uma das melhores abordagens. Prepared statements são consultas SQL onde os parâmetros são separados do código SQL. Isso significa que os dados inseridos pelo usuário são tratados como dados, e não como código, evitando assim que sejam interpretados como parte da consulta SQL. Esta técnica é amplamente recomendada por especialistas em segurança, conforme indicado por fontes como a OWASP, que lista as injeções como uma das principais ameaças à segurança de aplicações web.

Análise das Alternativas Incorretas:

A - Usar mecanismos de hashing para proteger os dados enviados às consultas SQL: Esta prática é útil para proteger senhas e dados sensíveis em repouso, mas não previne injeções SQL, pois o problema reside na forma como a consulta SQL é construída e executada.

B - Utilizar variáveis de ambiente para armazenar as credenciais de banco de dados e incluí-las diretamente nas consultas SQL: Embora o uso de variáveis de ambiente para armazenar credenciais seja uma boa prática de segurança, isso não aborda a questão da injeção SQL, que é sobre a construção das consultas.

C - Usar concatenação de strings para gerar as consultas SQL: Esta abordagem aumenta o risco de injeções SQL, pois permite que dados do usuário sejam diretamente incluídos e interpretados como parte do código SQL.

E - Implementar análise estática de código após o deployment: Análise estática é uma boa prática de qualidade de software, mas não previne injeções SQL. Além disso, para ser eficaz, deveria ocorrer antes do deployment.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

(D) utilizar parâmetros (prepared statements) para consultas SQL. 

Em sistema de gerenciamento de banco de dados (SGBD), uma instrução preparada , instrução parametrizada é um recurso em que o banco de dados pré-compila o código SQL e armazena os resultados, separando-os dos dados. Os benefícios das instruções preparadas são: 

• eficiência, porque podem ser usados ​​repetidamente sem recompilação
• segurança, reduzindo ou eliminando ataques de injeção de SQL.

Injeção de SQL (SQL Injection) é um tipo de ameaça de segurança que se aproveita de vulnerabilidades em sistemas que trabalham com bases de dados realizando ataques com comandos SQL; onde o atacante consegue inserir umainstrução SQL personalizada e indevida através da entrada de dados de uma aplicação, como formulários ou URL de uma aplicação online.

A questão aborda a prevenção de vulnerabilidades de injeção SQL, um problema crítico de segurança em aplicações web. Vamos analisar cada alternativa e identificar a mais adequada:

Utilizar parâmetros (prepared statements) para consultas SQL.

• Justificativa: Prepared statements separam claramente o código SQL dos dados fornecidos pelo usuário, impedindo que entradas maliciosas sejam interpretadas como parte da consulta. Isso elimina o risco de injeção SQL, pois os parâmetros são tratados como valores literais, não como código executável.

A) Usar mecanismos de hashing para proteger os dados enviados às consultas SQL.

• Erro: Hashing é usado para proteger senhas ou dados sensíveis, não para construir consultas SQL. Não previne injeção, pois o atacante pode injetar código diretamente sem hashing.

B) Utilizar variáveis de ambiente para armazenar credenciais e incluí-las diretamente nas consultas.

• Erro: Armazenar credenciais em variáveis de ambiente é uma boa prática, mas não evita injeção SQL. O problema está na construção dinâmica de consultas sem sanitização, não no vazamento de credenciais.

C) Usar concatenação de strings para gerar consultas SQL.

• Erro: Essa é exatamente a prática que causa injeção SQL. Concatenar entradas do usuário diretamente na query permite que comandos maliciosos sejam executados.

E) Implementar análise estática de código após o deployment.

• Erro: Análise estática ajuda a identificar vulnerabilidades, mas não as previne. Além disso, deve ser feita antes do deployment, não depois.

FONTE: DeepSeek

• A aplicação foi explorada por uma vulnerabilidade de injeção SQL.
• O time quer evitar esse tipo de falha no código-fonte, ou seja, na origem da vulnerabilidade.

• O uso incorreto de concatenação de strings com entradas do usuário para montar consultas SQL.
• Isso permite que comandos maliciosos sejam "injetados" no banco de dados.

❗ Prepared Statements (consultas parametrizadas)

Com essa abordagem, os parâmetros são passados separadamente do comando SQL, impedindo que o input do usuário seja interpretado como código SQL.

• Hashing é útil para proteger senhas ou dados sensíveis.
• Não protege contra injeção SQL, pois o problema está na forma como a consulta é construída, e não na segurança dos dados.
• ➡️ ERRADA

• Variáveis de ambiente são boas para proteger credenciais, mas não têm nada a ver com prevenção de injeção SQL.
• Incluir essas credenciais diretamente nas consultas seria um erro grave.
• ➡️ ERRADA

• Essa é justamente a causa da vulnerabilidade de injeção SQL.
• Nunca deve-se concatenar diretamente dados do usuário com a query.
• ➡️ ERRADA

• Essa é a técnica mais recomendada para prevenir injeção SQL.
• A consulta é preparada com placeholders, e os dados são passados separadamente.
• ➡️ CERTA

• Análise estática é útil, mas deve ser feita antes do deployment.
• Além disso, ela ajuda a identificar, mas não substitui práticas seguras como o uso de .
• ➡️ ERRADA

Chat

enfia esses comentario de IA naquele lugar, usem dessa forma.

SQL Injection acontece quando o usuário consegue inserir comandos SQL no campo de entrada e alterar a consulta ao banco.

A melhor prevenção é usar queries parametrizadas (Prepared Statements), separando dados do comando SQL.