PAULO RICARDO LISBOA DE ALMEIDA

LIDANDO COM
ENTRADAS DE
USUÁRIO
PAULO RICARDO LISBOA DE ALMEIDA
ENTRADAS DE USUÁRIO
• Entradas de usuário são uma das grandes causadoras de falhas de
segurança
• O usuário está fora do escopo da aplicação
• A aplicação deve partir do princípio que qualquer entrada pode conter
conteúdo malicioso
ENTÃO COMO SE DEFENDER?
BLACKLIST
• Lista de padrões que podem ser utilizados em ataques
• Qualquer entrada que possua um desses padrões é bloqueada
• Ex:. Select, Drop, Alter, ...
• Qualquer entrada que não consta na lista é aceita
• Essa técnica funciona? Por quê?
BLACKLIST
• Técnica simples, porém pouco efetiva
BLACKLIST
• Exercício
• Tentar quebrar o algoritmo de validação de padrões baseado em blacklist
criado pelo professor
BLACKLIST - PROBLEMAS
• A lista dificilmente vai conter todos os padrões maliciosos possíveis
• Técnicas de invasão estão sempre evoluindo
• A lista pode se tornar obsoleta em pouco tempo
• Formas de se burlar blacklists:
• Se a palavra select está na blacklist, tentar SeLeCt
• 1=1 por 2=2
• Inserir caracteres não padrão para quebrar o algoritmo de detecção para
que ele pare de funcionar
• Exemplo: inserir um caractere NULL ou de fim de string para confundir o algoritmo
que transforma a string em tokens
WHITELIST
• Lista contendo somente as palavras aceitas
• Técnica efetiva para conter ataques
• Problemas?
WHITELIST
• Lista contendo somente as palavras aceitas
• Técnica efetiva para conter ataques
• Problemas?
• Muitas vezes é impossível criar um lista somente com as entradas
aceitáveis
• Ex.: Caixa de entrada para o nome do usuário. Não é possível saber todos os
nomes possíveis ou todas as formas de se escrever um nome.
• Preconceito com Joana D’Arc
SANITIZAÇÃO
• Aceita qualquer entrada e então faz a “sanitização”
• Remove padrões potencialmente maliciosos ou os escapa
• Depois da sanitização a entrada é passada para o sistema realizar o
processamento
• A sanitização pode ser considerada como uma solução geral e eficaz
se implementada da maneira correta
• Ex.:
• O usuário entra com a seguinte string no campo senha:
• ' or 1 = 1;
• Após a sanitização
• \' or 1=1;
MANIPULAÇÃO SEGURA DE DADOS
• Safe Data Handling
• Ao invés de validar a entrada, garantir que ela é processada de forma
inerentemente segura
• Nem sempre é possível
• Porém nos casos em que é aplicável essa técnica é muito efetiva
MANIPULAÇÃO SEGURA DE DADOS –
EXEMPLO COM API
• API JDBC sem Manipulação Segura de Dados
int cpf = 123456;
String nome = "Paulo";
String nascimento = new Date();
String sql = "insert into pessoa" +
" (cpf,nome,nascimento)" +
" values (";
sql += cpf + "," + nome + "," + nascimento.toString()+ ");"
PreparedStatement statement =
connection.prepareStatement(sql);
...
MANIPULAÇÃO SEGURA DE DADOS–
EXEMPLO COM API
• Utilizando a API JDBC com Safe Data Handling
String sql = "insert into pessoa" +
" (cpf,nome,nascimento)" +
" values (?,?,?)";
PreparedStatement statement =
connection.prepareStatement(sql);
statement.setInt(1, cpf);
statement.setString(2, nome);
VALIDAÇÃO SEMÂNTICA
• Muitas vezes uma mesma entrada de dados pode ser maliciosa ou
não, dependendo das circunstâncias
• Ex.: um usuário pode tentar entrar na conta de outro enviado os dados
da conta em um campo hidden de um form
• Os dados enviados são válidos e não existe um filtro capaz de detectar que
as strings são maliciosas
• É necessário uma validação semântica
• Verificar se os dados enviados no form pertencem ao usuário que submeteu o form
VALIDAÇÃO POR FRONTEIRAS
• Boundary Validation
• Considerar que depois que os dados foram validados na “fronteira da
aplicação” não há mais perigo é um erro
• Ex.: Considerar que após uma sanitização as informações podem ser
confiáveis e, por exemplo, passadas para o banco de dados
VALIDAÇÃO POR FRONTEIRAS
• Problemas:
• A fronteira dificilmente conseguirá filtrar todo tipo de dados maliciosos
• Os componentes são encadeados
• Um atacante eficaz pode gerar uma entrada aparentemente inofensiva, que será
processada e modificada componente a componente, até chegar no componente
alvo
• As modificações sofridas podem tornar a entrada inicial como um foco de ataque
• Ex.: Como utilizar um sanitizador que sempre escapa caracteres maliciosos com uma barra
invertida \ para evitar SQL Injections ao seu favor?
VALIDAÇÃO POR FRONTEIRAS
• Problemas:
• A fronteira dificilmente conseguirá filtrar todo tipo de dados maliciosos
• Os componentes são encadeados
• Um atacante eficaz pode gerar uma entrada aparentemente inofensiva, que será
processada e modificada componente a componente, até chegar no componente
alvo
• As modificações sofridas podem tornar a entrada inicial como um foco de ataque
• Ex.: Como utilizar um sanitizador que sempre escapa caracteres maliciosos com uma barra
invertida \ para evitar SQL Injections ao seu favor?
• Entrar com a string \' or 1=1
• A fronteira pode escapar o '
• Porém esse caractere já foi escapado, o que irá gerar um \\' or 1=1
• O caractere de escape agora está escapando o \, e então o ' or 1=1 pode ser passado para
a camada do banco de dados
VALIDAÇÃO POR FRONTEIRAS
• Na validação por fronteiras, cada componente trata a entrada como
sendo de um potencial atacante
• Por exemplo:
• A camada que recebe os dados do usuário faz uma sanitização
• A camada da aplicação que se comunica com o banco de dados recebe
esses dados, porém os trata através da técnica da manipulação segura de
dados (parameters)
VALIDAÇÃO POR FRONTEIRAS
CRIANDO TESTES PARA CADA UMA DAS
TÉCNICAS DE PROTEÇÃO
• Blacklist
• Tentar inserir de alguma forma uma informação que está na blacklist
• Ex.: Se a blacklist não aceita select, digitar sElEcT
• Procurar por padrões possivelmente maliciosos que não estão na blacklist
• Whitelist
• Verificar se a aplicação não bloqueia alguma entrada válida (não maliciosa)
• Sanitizador
• Criar entradas que confundam o sanitizador, fazendo com que uma entrada que não
geraria erros se torne perigosa depois de sanitizada
• Tentar quebrar o algoritmo
• Modificar a codificação da entrada, enviar caracteres especiais (\0), estourar o tamanho da
string, etc..
CRIANDO TESTES PARA CADA UMA DAS
TÉCNICAS DE PROTEÇÃO
• Safe data handling
• Verificar os possíveis drivers utilizados pelos desenvolvedores e testar
falhas comuns desses drivers
• Se o desenvolvedor estiver utilizando um driver antigo, com certeza ele conterá
brechas de segurança conhecidas.
• Ler a documentação do fabricante
• Validação semântica
• Elaborar testes que verifiquem se o software valida não só a entrada, mas
se as informações enviadas fazem “sentido” em determinada situação
• Ex.: O usuário logado A está tentando modificar as informações de login do usuário
B
CRIANDO TESTES PARA CADA UMA DAS
TÉCNICAS DE PROTEÇÃO
• Validação por fronteiras
• Criar cenários onde são passadas informações que podem não ser filtradas
na fronteira, e que podem ser potencialmente prejudiciais a um modulo
específico do software
• Criar entradas que podem ser modificadas a cada fronteira do software, até
chegar no módulo alvo
• A entrada inicial não é prejudicial, mas as modificações feitas pelo próprio software
a tornam prejudicial ao módulo
EXERCÍCIO
• Verifique as possíveis falhas em campos de entrada de usuário de uma
aplicação de sua preferência.
–
Sugestão: Google-Gruyere