Injection ainda é um dos maiores riscos segundo o OWASP. Se você deixar essa falha passar, um invasor pode causar muitos danos, custando milhões. Quer saber sobre as tendências dos ataques cibernéticos? A galera da CISCO já disse, entre 2016 e 2017 os ataques triplicaram, e o custo pode ultrapassar os US $150 milhões antes de você notar.
Quando falamos de invasões na Web, o velho SQL Injection ainda está em segundo lugar, atrás apenas do famoso DDOS.
OWASP
Nunca ouviu falar do OWASP? O Open Web Application Security Project é uma organização que tenta ajudar os desenvolvedores a se preocuparem mais com segurança. Eles promovem práticas seguras na Web através de workshops e eventos. Já ouviu falar do "OWASP Top Ten"?
De tempos em tempos, eles atualizam a lista das 10 principais falhas. Resolver essas falhas não torna o site 100% seguro, mas dificulta bastante a vida de quem tenta invadir.
Segurança
Segurança e desenvolvedores, sempre um desafio. Tem LGPD, segurança de infraestrutura, mas quem está cuidando dos aplicativos? Documentos importantes são enviados por e-mail como se fossem piadas. Google e Microsoft tentam ajudar, mas...
Firewall ativo, antivírus atualizado, USB bloqueado, e a aplicação daquele sistema de cadastro de plantas? Já pensou nisso?
Pedir ajuda para Daniel Donda, porque causar danos dá trabalho, e 53% dos ataques são de pessoas com tempo de sobra, gerando mais de meio milhão em custos.
Injection
Falhas de Injection são erros onde um script malicioso toma conta da aplicação. O SQL Injection é o mais famoso, mas não é só ele.
Segundo a galera da Akamai, 51% dos ataques em 2017 usavam o SQL Injection. Cadê os devs para proteger esses aplicativos?
SQL Injection
No caso do SQL Injection, o invasor altera os parâmetros de consulta do site. Insere uma consulta e mexe nos parâmetros, pura diversão! Ainda tem quem ache que o Bob Drop Table é só piada!
O Ataque
Imagine uma aplicação que lista estudantes:
Aqui está a consulta que faz isso funcionar:
Teste a vulnerabilidade inserindo consultas SQL como abc' OR 1=1 --.
O servidor mostra todos os registros.
Passo 2 - Mapeando o banco
Usando sys.Tables, se o usuário tiver acesso suficiente, o invasor pode consultar: abc' UNION SELECT [name], cast(max_column_id_used as varchar(5)) FROM sys.Tables --.
Passo 3 - Dados confidenciais
Com as tabelas à mostra, busca por dados confidenciais:
abc' UNION SELECT Username, Password FROM AspnetUsers --
E nunca podemos esquecer do clássico abc'; DROP TABLE AspnetUsers --
Como se proteger
Hora de aprender a se defender dessas ameaças do SQL:
Consultas Parametrizadas
SEMPRE use consultas parametrizadas.
Veja a parametrização nas linhas 5 e 11!
Usuário do Banco
O usuário não deve ter permissões demais. Não ajuda só o invasor, mas também atrapalha seus planos.
ORMs
Use ORM, como EntityFramework ou Hibernate, para ajudar a evitar SQL Injection.
Stored Procedures
Stored procedures protegem contra consultas concatenadas que te deixam vulnerável.
Considerações
Injection é um problema sério. Precisamos corrigir esses códigos mal escritos!
Conclusão
Se a demonstração não te deixou preocupado, pelo menos serve para mostrar na prática como os ataques de SQL Injection funcionam.
Download
Pratique suas habilidades de segurança revisando meu trabalho no GitHub
Fale conosco