SQL Injection ou injeção de SQL é uma técnica de invasão de sistemas que se tornou famosa na Internet, mas pode ser utilizada em qualquer linguagem de programação. No entanto, na Internet temos uma combinação explosiva:
- A aplicação está acessível para toda internet que possui milhares de usuários dispostos a quebrar seu sistema;
- O uso de linguagens de script fracamente tipadas em conjunto com com tipos de dados fracamente tipados ajuda a abrir algumas brexas de segurança.
- O protocolo HTTP tem peculiaridades que quando mal utilizadas podem tornar uma aplicação web mais vulnerável como o uso de parâmetros GET.
O exemplo clássico é o login de um usuário da aplicação. Você pede o nome e senha do usuário numa tela e depois envia um SQL com esta característica:
SELECT TRUE WHERE nome = 'telles' AND senha = 'abizi'
Na tela de login o usuário pode digitar no lugar da senha algo mais ou menos assim:
USUÁRIO: admin
SENHA: ‘ OR 1=1 –
Ao substituir as variáveis o seu SQL ficaria assim:
SELECT TRUE WHERE nome = 'admin' AND senha = '' OR 1=1 --'
Segurança contra o SQL Injection
Regra no mínimo privilégio:
Veja que há uma série de problemas a serem analisados aqui. A primeira questão que qualquer sistema deve se preocupar em analisar é saber qual o potencial de destruição que o usuário vai ter se ele conseguir um ataque bem sucedido. Se o usuário que se conecta na aplicação é dono de objetos no banco de dados, como muitas aplicações gostam de fazer por uma questão de comodidade, você verá que o seu usuário terá permissões plenas sobre os seus objetos. Utilizando SQL Injection, ele poderá realizar operações como DROP, TRUNCATE, ALTER além do DELETE, INSERT, UPDATE e SELECT.
Então a primeira regra que deve SEMPRE ser seguida a risca é que:
“O USUÁRIO QUE A APLICAÇÃO UTILIZA PARA SE CONECTAR NO BANCO DE DADOS JAMAIS DEVE SER O DONO DOS OBJETOS CRIADOS NO BANCO DE DADOS”
Alguns artigos que tratam sobre SQL Injection ignoram solenemente esta recomendação. Alguns ficam desempregados inesperadamente. Então, precauções especiais devem ser tomadas em aplicações onde cada usuário da aplicação não tem seu próprio usuário criado no banco de dados - o que é comum em aplicações web com milhares de usuários que surgem sem controle do DBA. Você deve ter pelo menos 4 usuários para cada aplicação com este perfil:
- Um usuário que é dono dos objetos criados no banco de dados. Este usuário deve estar sob controle somente e tão somente do DBA, tanto no ambiente de testes como em produção. Lembre-se que este usuário tem poderes plenos sobre estes objetos do banco de dados.
- Um usuário ou grupo de usuários destinado aos desenvolvedores com poderes específicos para as suas tarefas. Pode-se determinar que no ambiente de produção ele tenha permissão de SELECT em todas tabelas e sequências e no ambiente de produção tenha poderes de SELECT, INSERT, UPDATE e DELETE.
- Um usuário ou grupo de usuários destinado aos administradores da aplicação, que terão poderes específicos na aplicação como deletar registros ou atualizar valores em tabelas. Este usuário deve se conectar a partir de outro executável que não o utilizado pelos usuários normais. A aplicação utilizada para fins administrativos deve ter acesso restrito ao acesso local por exemplo. Este usuário terá permissões de DELETE, UPDATE e INSERT em tabelas que um usuário normal não terá permissão. Portanto, este usuário jamais deve ser utilizado em operações de rotina.
- Um usuário para os usuários normais da aplicação. Este usuário deve seguir a risca a regra no menor privilégio. Ele deve apenas as permissões para acessar os objetos estritamente necessários. Privilégios de UPDATE e DELETE devem ser concedidos com muita cautela. Operações deste tipo quando executadas sem uma clausula WHERE adequada podem ser desatrosas. É este usuário que será alvo de ataques de SQL Injection. Se você for rigoroso com as permissões para este usuário, limitará muito a dimensão dos estragos que podem acontecer no caso de um ataque bem sucedido.
Cya~
