Outro dia estive no I Encontro de Comitês de Ética da UTFPR, em Curitiba, para falar sobre segurança no uso de bancos de dados online. Esse texto é um pouco do que eu disse lá.

O uso de bancos de dados online é uma realidade. O ambiente virtual facilita o recrutamento de sujeitos para a pesquisa, permite a colaboração entre pesquisadores e inclusive reduz custos com maquinário in loco, uma vez que a capacidade de armazenamento e processamento é transferida para o servidor. Mas ao colocar dados na internet, a quais riscos estamos sujeitos?

CONTINUE LENDO

Meu objetivo aqui é falar sobre problemas de segurança na inserção, consulta, edição e tratamento das informações do banco. Há claro problemas de segurança, éticos e de metodologia que aparecem aqui, mas que não vou abordar no momento.

Segurança

Bom, podemos separar o processo de uso do banco de dados online numa pesquisa em cinco estágios: recrutamento dos sujeitos da pesquisa, coleta de dados, armazenamento, análise e backup. No uso do banco, nós temos as ações de recrutamento, coleta e análise concentrada no terminal do usuário e o armazenamento e backup no banco de dados em si.

Explico: dificilmente, quando se usa um banco de dados online, temos a manipulação direta do banco. Ou seja, é preciso usar um aplicativo online cuja função é permitir que o usuário realize suas tarefas numa interface gráfica navegável (muitas vezes acessível pelo navegador) e comunicar essas ações para a banco de dados.

Em português claro: se eu adiciono um questionário respondido pelo aplicativo, o software vai pegar os dados que digitei no navegador e salvar num novo registro dentro do banco de dados que está no servidor. Se eu quiser fazer uma busca por termos nos dados salvos, vou digitar isso num formulário e quanto apertar o botão Procurar o app vai até o banco e pesquisa os itens que contém esse termo.

É aí que o bicho pega. Porque o que esses aplicativos fazem é criar uma consulta dinâmica que se configura a partir das informações inseridas na página. É por aí que alguém pode tentar interferir nos dados.

Ameaça externa

Segundo a Verizon Bussiness Risk Team, 75% dos vazamentos de dados são causados por ameaças externas. Ou seja, terminais comprometidos por vírus, cavalos de tróia e mau uso. A Privacy Rights Clearinghouse (PRC)
já registrou 7670 vazamentos de dados desde 2008, quando começou a monitorar os comunicados sobre isso. Eles estimam que 1,07 bilhão de registros foram comprometidos.

Em um dos casos desse ano, dois computadores do Departamento de Saúde e Serviço Social do Alasca foram atacados por malware, o que pode ter comprometido fichas médicas, documentos de casos do Conselho Tutelar e do serviço de proteção à criança.

SQL Injection

Mas como alguém rouba, altera ou apaga dados de um banco de dados? Vou demonstrar dois métodos.

Um deles é o uso de formulários sem validação para obter acesso ao banco.

Formulário de autenticação

Quando o usuário digita o login e a senha o computador realiza a seguinte consulta no banco:
SELECT * FROM tabela_usuarios WHERE login = ‘valor_campo_login’ AND senha = ‘valor_campo_senha’

Isso significa que o banco irá procurar na tabela a linha cujo campo login é igual o que foi digitado e o campo senha é igual a que foi informada. Se isso for verdadeiro, o sistema aceita o login. Mas se o usuário incluir no campo senha o valor ‘ or ‘1’ = ‘1’ a consulta ficará assim:
SELECT * FROM tabela_usuarios WHERE login = ‘valor_campo_login’ AND senha = ” or ‘1’ = ‘1’
Ou seja, independente de encontrar ou não uma linha referente aos valores digitados a expressão será sempre verdadeira, porque 1 é sempre igual a 1.

Essa falha acontece quando um formulário não uso validação no processamento dos dados. Ou seja, ela não testa se o valor digitado no campo corresponde ao que se espera e veta a inserção de valores proibidos.

Consulta via URL

Outro exemplo é quando temos o seguinte formato de URL na consulta do aplicativo:

www.urldoapp.com.br/pagina.php?id=55

O item ?id= é uma consulta ao banco e pode ser manipulado. Ao ler isso você sabe que o aplicativo está consultando uma tabela que tem um campo id e há o item 55 no arquivo. Você pode alterar os valors após o ? de forma a tentar outras consultas.

Mesmo quando não há forma de acessar o banco, a forma como a consulta é feita pode já permitir que os dados sejam vistos. Um exemplo: Na prefeitura de Curitiba, os dados cadastrados nos pedidos da Lei de Acesso à Informação recebiam um id sequencial que era usado para consultar o pedido. Ou seja, a mera substituição do número na URL permitia o acesso aos dados de todos os requerentes.

Esses dois exemplos são o que se chama de SQL Injection: Uso de consultas dinâmicas para inserir, consultar, extrair e apagar dados do banco de dados.

De quem é a culpa

Você pode estar pensando: mas eu sou só usuário. Isso aí é problema do programador. É verdade. Mas ao se eximir de entender a mecânica do sistema você pode deixar passar problemas de segurança no seu banco, o que coloca em risco os teus dados. E isso é problema seu.

Ao entender como a coisa funciona é mais fácil observar onde podem estar as falhas e ser mais cuidadoso no tratamento dessas informações. Se você sabe que o risco existe e como ele se apresenta talvez pare de usar senhas tolas para projetos profissionais e achar que os técnicos vão garantir a segurança, porque eles podem até tentar, mas você é o elo fraco.

Ficou com vontade de aprender mais? Continue acompanhando nossas postagens. Confira minhas aulas sobre HTML, CSS e PHP.