Open Web Application Security Project (OWA SP) tem como um dos seus trabalhos mais conhecidos uma lista que reúne os riscos de ataques mais obrigatórios exploráveis a partir de vulnerabilidades nas aplicações web. Estes trabalhos são conhecidos como os dez riscos de segurança de aplicativos web mais críticos. “Ocorrem quando dados não confiáveis são enviados a um intérprete como parte de um comando ou consulta.” Tal afirmação se refere ao seguinte risco:
- A)Falhas de injeção.
Correta, porque descreve exatamente a situação em que dados não confiáveis são usados em comandos ou consultas, caracterizando falhas de injeção.
- B)Cross Site Scripting (XSS).
Errada, porque XSS envolve a execução de scripts no navegador da vítima, e não a inserção de dados em um intérprete de comandos ou consultas.
- C)Cross Site Request Forgery (CSRF).
Errada, porque CSRF explora a confiança do servidor em uma requisição legítima do usuário, sem depender da injeção de dados em comandos.
- D)Referências inseguras de objetos diretos.
Errada, porque referências inseguras de objetos diretos dizem respeito ao acesso a recursos por identificadores expostos ou previsíveis, não a comandos ou consultas.
Gabarito: A
Essa questão cobra um dos ataques mais clássicos do OWASP Top 10: a injeção. A ideia central é simples e perigosa ao mesmo tempo: quando a aplicação recebe dados não confiáveis e os encaixa em um comando, consulta ou interpretação sem tratar direito, o atacante pode “mandar” no que o sistema vai executar. É o tipo de falha que aparece em SQL Injection, LDAP Injection, Command Injection e outras variações que exploram justamente essa confiança excessiva na entrada do usuário. O enunciado foi praticamente a definição de falha de injeção: dados não confiáveis enviados a um intérprete como parte de um comando ou consulta. Isso é exatamente o que ocorre quando uma aplicação monta instruções dinâmicas com entrada externa sem validação, parametrização ou escape adequados. Em linguagem de prova: o sistema deixa o usuário “conversar” com o banco, com o interpretador ou com o shell. As outras opções são ataques bem conhecidos, mas com outra lógica. XSS explora a execução de scripts no navegador da vítima, CSRF força uma requisição em nome do usuário autenticado, e referências inseguras de objetos diretos tratam do acesso indevido a recursos por IDs previsíveis. Aqui, porém, o foco não é navegador, nem sessão, nem ID exposto: é a injeção de dados em um interpretador. Na prática, a defesa passa por consultas parametrizadas, validação de entrada, princípio do menor privilégio e tratamento seguro de comandos e consultas. No OWASP, esse tipo de falha sempre aparece entre os riscos mais críticos, justamente porque pode levar de vazamento de dados até execução de comandos no servidor. Então, se a questão falar em dados não confiáveis entrando como parte de comando ou consulta, pense sem medo em injeção.