O mínimo que você deveria aprender para se defender de ataques de injeção de SQL no PostgreSQL

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:

1. 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.
2. 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.
3. 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.
4. 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 desastrosas. É 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.

Use criptografia, visões e funções

Feito isso, você já terá um ambiente muito mais seguro, com certeza. A próxima parte do nosso trabalho será realizar um tratamento dedicado às informações mais sensíveis do seu sistema. Identifique estes objetos com cuidado. Existem dados sigilosos que podem ser alvo de criptografia. Senhas jamais devem ser armazenados sem criptografia. Use uma função como MD5 para isso. Lembre-se que você não poderá saber qual é a senha armazenada no campo, apenas poderá verificar se uma senha é igual a que está armazenada. No entanto, se apenas um grupo específico precisa ter acesso a estas informações você deve restringir o acesso a elas. Quando você quer restringir o acesso a apenas uma coluna ou grupo de colunas de uma tabela a melhor alternativa é criar uma visão com apenas as colunas que o usuário vai precisar. De permissão ao usuário acessar esta visão não permita que ele leia a tabela diretamente.

Há casos em que a pessoa precisa alterar ou ler registros, mas você não quer que limitar a possibilidade de que o usuário altere todos os registros da tabela. Para isso, você pode criar funções que encapsulem toda a operação. Você passa para a função os parâmetros a serem alterados, a função checa a validade destes dados, faz todas as alterações em todas tabelas necessárias e retorna se realizou a operação com sucesso ou não, ou ainda retorna um valor desejado como se fosse um SELECT. O resultado disso é que você só precisa dar permissão ao usuário para executar a função e não precisa dar nenhum acesso a qualquer um dos objetos envolvidos na transação. Isto significa que o usuário só poderá realizar aquela transação especificada pela função, que se for bem codificada, evitará definitivamente qualquer chance de acesso indevido.

Procedimentos preparados

A terceira etapa é utilizar os procedimentos preparados ou “prepared statements’. Este procedimentos fazem com que você passe como parâmetros os valores a serem substituídos num comando SQL qualquer. As pessoas evitam utilizar este procedimento pois ele requer que você o execute em duas etapas: preparar o procedimento e executar o procedimento. Quando executado com freqüência, os procedimentos preparados não só são mais seguros, como também apresentam um ganho de performance.

Dollar Quoting

A quarta etapa que você pode utilizar é peculiar ao PostgreSQL, e chama-se “dollar quoting“. Ao invés colocar strings de caractere entre aspas simples em expressões SQL, você pode usar o $$ como em:

SELECT TRUE FROM users WHERE name = $$$$ AND senha = $$abizi$$;

Você ainda pode fazer coisas como:

SELECT TRUE FROM users WHERE name = $name$telles$name$ AND senha = $senha$abizi$senha$;

Note que você pode colocar suas strings entre $$, $nome$, $senha$ ou qualquer outra coisa, tendo somente que começar e terminar com a mesma marca. Usar este tipo de notação no código SQL pode parecer um tanto grotesco inicialmente, mas quando você for escrever funções, ela pode tornar a sua vida muito mais simples, pois você não terá situações bizarras como um grupo de várias aspas simples ou contra barras. Com o dollar quoting, você não precisa se preocupar com as aspas simples.

Checar o tipo de dados

A próxima barreira de defesa na luta contra a injeção de SQL é checar o tipo de dados utilizado. Um tipo comum de ataque é por exemplo injetar código em parâmetros GET do protocolo http. Se você espera um número, tenha certeza de que ele é um número antes de substituir a sua variável no seu código SQL. Uma forma eficiente de fazer isso é utilizar a função ‘printf’. Quase toda linguagem de programação possui um comando semelhante ao printf da linguagem C. A nossa string SQL utilizando printf ficaria alguma coisa assim:

SQL = printf('SELECT TRUE FROM users WHERE nome = %s AND senha = %s', nome, senha)

A questão aqui é que a função printf vai forçar o uso do tipo de dados correto na função SQL. Não é uma solução perfeita, mas pode evitar alguns problemas além de evitar a conversão implícita de tipos de dados, fonte de muitas dores de cabeça no banco de dados.

Escapar as strings

A barreira mais conhecida na proteção contra a injeção de SQL é o uso de funções que escapem as strings. Hoje a maioria das linguagens de programação possuem funções para escapar caracteres como aspas simples em strings. Veja que uma aspa simples pode fazer parte de uma string como em “database’s security”. Para que uma string deste tipo seja aceita, é preciso escrevê-la desta forma numa expressão SQL:

INSERT INTO titulo VALUES ('database''s security');

Note que existem duas aspas simples e não uma aspas dupla. Esta é a única forma de se adicionar aspas simples numa string em banco de dados. Você deve esperar que o seu usuário por qualquer motivo digite uma aspa simples em qualquer string. A não ser que você remova explicitamente as aspas simples da sua string antes de construir o seu comando SQL, você deverá sempre escapa-las. Se a sua linguagem de programação possuir uma função de escape de strings específica para o seu banco de dados, utilize-a no lugar de uma função genérica.

Conclusão

Os problemas de segurança em geral são criados por profissionais mal informados ou por desenvolvedores que acreditam que segurança é um fator supérfluo e que implementar todas as barreiras necessárias é muito trabalhoso. O descuido com a segurança chega num ponto onde muitos servidores web exibem suas mensagens de erro diretamente na tela do usuário, no ambiente de produção. O uso de técnicas de SQL Injection em ambiente que não implantaram todas as barreiras citadas e ainda oferecem de bandeja os erros da aplicação na tela é absolutamente devastador. O usuário consegue descobrir o nome de todas as tabelas e colunas da sua aplicação, alterar qualquer registro ou mesmo apagar todas as informações de todas tabelas. Não é incomum encontrarmos aplicações de grande porte com furos homéricos de segurança. Não é incomum sites famosos e grandes corporações sofrerem com o vazamento de informações, fraudes e perda de dados. O prejuízo é sempre maior do que o custo de implementar a segurança de forma correta na aplicação.

Quando pensar novamente em segurança, lembre-se que a tarefa é de todos. Os ataques de SQL injections são muito simples de executar, a pondo de criarem a expressão “Script kiddie” para designar pessoas com pouco conhecimento técnico que utilizam receitas simples e eficientes para invadir sistemas. Não adiante a rede, o servidor e o banco de dados adotarem condutas rigorosas de segurança se você lança mão de aplicações (desenvolvidas por você ou por terceiros) que não tomam este tipo de precaução.