Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Um serviço .NET usa Dapper para consultar e gravar dados em um banco relacional. A aplicação recebe parâmetros vindos de formulários públicos (por exemplo, CPF, período de datas e número do protocolo). Qual prática deve ser adotada para mitigar SQL Injection ao montar comandos SQL com Dapper?
AUtilizar parâmetros nomeados e passar os valores separadamente, permitindo que o provedor de dados gere comandos preparados de forma segura.
BConcatenar as entradas do usuário após "sanitização" (substituir aspas, remover palavras-chave), pois isso evita ataques na maioria dos casos.
CDepender de migrações automáticas para validar o esquema, reduzindo o risco de injeção na camada SQL.
DUsar change tracking do Dapper para que os valores sejam tratados como dados, não como código.
EEliminar N+1 automaticamente, pois menos rodadas no banco reduzem a superfície de ataque.
Revelar gabarito e comentário▾
GabaritoA — Utilizar parâmetros nomeados e passar os valores separadamente, permitindo que o provedor de dados gere comandos preparados de forma segura.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
SQL Injection e Dapper: a prática correta de mitigação
Gabarito: letra A. A mitigação mais eficaz contra SQL Injection é o uso de comandos parametrizados com parâmetros nomeados, prática nativa do Dapper e de qualquer provedor ADO.NET. Isso garante que os valores fornecidos pelo usuário sejam tratados como dados, nunca como parte executável do comando SQL. A letra A descreve exatamente esse mecanismo.
A banca testa o conhecimento de que a "sanitização" de entradas (letra B) é frágil e não confiável, e que outras opções (migrações, change tracking, N+1) são irrelevantes ou não existem no Dapper para esse fim.
O texto de apoio reforça que "variáveis de ligação (usando comandos parametrizados)" protegem contra injeção e melhoram o desempenho, exemplificando com PreparedStatement do JDBC — princípio idêntico ao Dapper.
Prática
Descrição
Eficácia contra SQL Injection
Relação com Dapper
Parâmetros nomeados (A)
Passar valores separadamente como parâmetros nomeados, gerando comandos preparados
✅ Alta – valores tratados como dados, nunca como código
Nativo do Dapper e ADO.NET
Sanitização de entradas (B)
Substituir aspas e remover palavras-chave após concatenação
❌ Baixa – frágil e contornável por atacantes
Não recomendada; Dapper não depende disso
Migrações automáticas (C)
Validar esquema do banco via migrações
❌ Nula – não afeta consultas em tempo de execução
Irrelevante para o contexto
Change tracking do Dapper (D)
Recurso inexistente no Dapper para tratar valores como dados
❌ Nula – conceito fictício
Não existe no Dapper
Eliminar N+1 (E)
Reduzir rodadas no banco para diminuir superfície de ataque
❌ Nula – não mitiga injeção SQL
Não é prática de segurança contra injeção
Alternativa A — ✅ Correta ⟵ GABARITO
Utilizar parâmetros nomeados (ex.: new { cpf, periodo, protocolo }) e passá-los separadamente faz com que o Dapper crie internamente um SqlCommand com Parameters, gerando uma consulta preparada (prepared statement). Os valores são vinculados de forma segura, eliminando qualquer possibilidade de interpretação de fragmentos maliciosos como código SQL. Essa é a prática recomendada por toda a literatura de segurança e pela documentação oficial do Dapper.
Alternativa B — ❌ Incorreta
A "sanitização" (escapar aspas, remover palavras-chave) é uma técnica falha e não deve ser a principal linha de defesa. Como o próprio contexto aponta: "como pode haver um grande número de caracteres de escape, esta técnica não é confiável". Atacantes sofisticados podem contornar filtros, e a abordagem correta é sempre usar parâmetros, nunca confiar em limpeza manual.
Alternativa C — ❌ Incorreta
Migrações automáticas (como as do Entity Framework ou Flyway) tratam da evolução do esquema do banco (criação/alteração de tabelas). Elas não têm qualquer relação com a proteção contra SQL Injection em consultas dinâmicas em tempo de execução. A validação de esquema não impede que uma string maliciosa seja concatenada a um comando SQL.
Alternativa D — ❌ Incorreta
Dapper não possui um recurso chamado "change tracking" para esse fim. O Dapper é um micro-ORM que já utiliza comandos parametrizados por padrão quando se passa um objeto anônimo ou DynamicParameters. Mas a alternativa sugere algo inexistente. A frase "para que os valores sejam tratados como dados, não como código" descreve o efeito dos parâmetros, mas o nome "change tracking" é enganoso — esse termo é usado por Entity Framework para rastrear alterações em entidades, não para segurança contra injeção.
Alternativa E — ❌ Incorreta
O problema N+1 (múltiplas consultas em loop) é uma questão de desempenho, não de segurança. Eliminá-lo pode reduzir a carga no banco, mas não mitiga SQL Injection. A superfície de ataque permanece a mesma se as consultas individuais ainda forem construídas com concatenação de strings.
PEGA ESSA DICA!
Na prova, sempre desconfie de alternativas que sugerem "sanitização" como defesa suficiente. A banca quer que você lembre: comandos parametrizados são a única barreira confiável. No Dapper, basta escrever connection.Query("SELECT * FROM Tabela WHERE Id = @Id", new { Id = usuarioId }) — nunca concatene variáveis dentro da string SQL.