Fonte: http://www.online-security-solution.com/ - Illustration by Gaich Muramatsu Prof. Hederson Velasco Ramos Uma boa maneira de analisar ameaças no nível dos aplicativo é organiza las por categoria de vulnerabilidade do aplicativo. Ameaças por categoria de vulnerabilidade do aplicativo: Categoria de dados Autenticação Autorização Gerenciamento de Configuração Ameaça Estouro de buffer; XSS (Cross Site Scripting); injeção de código SQL; canonização Espionagem de rede; ataques de força bruta; ataques de dicionário; repetição de cookie; roubo de credencial Elevação de privilégio; divulgação de dados confidenciais; violação de dados; ataques "luring". Acesso não autorizado a interfaces de administração; acesso não autorizado a armazenamentos de configuração; recuperação de dados de configuração em texto não criptografado; falta de responsabilidade individual; contas de processo e serviço muito privilegiadas. 2 1
Ameaças por categoria de vulnerabilidade do aplicativo: Categoria Dados Confidenciais Gerenciamento de Sessão Criptografia Manipulação de Parâmetros Ameaça Acessar dados confidenciais em armazenamento; espionagem na rede, violação de dados Seqüestro de sessão; repetição de sessão, interceptação Geração de chave ou gerenciamento de chave de baixa segurança; criptografia de baixa segurança ou personalizada Manipulação de seqüência de caracteres para consulta; manipulação de campo de formulário; manipulação de cookie, manipulação do cabeçalho HTTP. 3 Ameaças por categoria de vulnerabilidade do aplicativo: Categoria Gerenciamento de Exceção Auditoria e Log Ameaça Divulgação de informações; negação de serviço O usuário nega a realização de uma operação, o invasor explora um aplicativo sem rastreamento; o invasor encobre seus rastros 4 2
A é uma questão de segurança na qual um invasor descobre que seu aplicativo faz suposições infundadas sobre o tipo, o tamanho, o formato ou o intervalo de dados de entrada. O invasor pode fornecer cuidadosamente uma entrada adulterada afim de comprometer seu aplicativo. As principais vulnerabilidades da categoria são: - Estouros de Buffer - XSS (Cross-Site Scripting) -Injeção de Código SQL - Canonização 5 - Estouros de Buffer (Buffer Overflow) As vulnerabilidades de estouro de buffer podem levar a ataques de negação de serviço ou injeção de código. -Um ataque de negação de serviço causa uma falha no processo; -A injeção de código altera o endereço de execução do programa para executar o código injetado por um invasor. As contramedidas para ajudar a evitar estouros de buffer incluem: Realizar validação completa da entrada. Essa é a primeira linha de defesa contra estouros de buffer. - Restrinja a entrada, validando seu tipo, tamanho, formato e intervalo. - Quando possível impeça que o usuário escreva na entrada. Use ComboBox. 6 3
- XSS (Cross Site Scripting) Um ataque XSS pode fazer com que o código arbitrário seja executado no navegador de um usuário enquanto o navegador está conectado a um site da Web confiável, mas vulnerável. O ataque atinge os usuários de seu aplicativo, e não o aplicativo em si. Seu aplicativo é usado como o veículo para o ataque. Ou seja, permite que um script em zona sem privilégio seja executado em área privilegiada. É possível executar códigos em HTML, JavaScript, PHP, etc. 7 - XSS (Cross Site Scripting) Exemplo: Para iniciar um ataque, o invasor deve convencer o usuário a clicar em um hiperlink cuidadosamente adulterado, por exemplo, incorporando um link em um emailenviado ao usuário ou adicionando um link mal intencionado à postagem de um grupo de notícias. Os pontos de link com uma página vulnerável em seu aplicativo que ecoa a entrada invalidada de volta para o navegador no fluxo de saída HTML. Ex. de forma como o link pode ser mal intencionado Link legítimo: www.seusitelegitimo.com/logon.aspx?username=bob Veja um link mal intencionado: www. seusitelegitimo.com/logon.aspx?username=<script>alert('codigo malicioso')</script> 8 4
Canonização Formas diferentes de entrada que resolvem para o mesmo nome padrão (o nome canônico) são conhecidas como canonização. O código é particularmente suscetível a questões de canonização se tomar decisões de segurança com base no nome de um recurso que é passado para o programa como entrada. Arquivos, caminhos e URLs são tipos de recurso que são vulneráveis à canonização porque em cada caso pode haver muitas maneiras diferentes de representar o mesmo nome. Os nomes de arquivo também são problemáticos. Por exemplo, um único arquivo poderia ser representado como: c:\temp\algum-arquivo.exe algum-arquivo.exe c:\temp\subdir\..\algum-arquivo.exe c:\ temp\algum-arquivo.exe..\algum-arquivo.exe 9 -Canonização As contramedidas para tratar questões de canonização incluem: - Evitar nomes de arquivo de entrada onde for possível e utilizar, em vez disso, caminhos de arquivo absolutos que não podem ser alterados pelo usuário final. - Certifique se de que os nomes de arquivo estejam bem formados (se você necessita aceitar nomes de arquivo como entrada) e valide os dentro do contexto de seu aplicativo. Por exemplo, verifique se eles estão dentro da hierarquia de diretórios de seu aplicativo. 10 5
-Injeção de código SQL (SQL Injection) Um ataque de injeção de código SQL explora vulnerabilidades na validação da entrada para executar comandos arbitrários no banco de dados. Isso pode ocorrer quando seu aplicativo usa entrada para construir instruções SQL dinâmicas para acessar o banco de dados. Também pode ocorrer se seu código utilizar procedimentos armazenados que são seqüênciaspassadas que contêm entrada do usuário não filtrada. Ao utilizar o ataque de injeção de código SQL, o invasor pode executar comandos arbitrários no banco de dados. Exemplos: 1) no campo User escrever: ; drop table user-- (ação que apaga tabela user) 2) ; having1=1-- (Ação que retorna: errorcolumn usuarios.codigoisinvalid. Esta mensagem informa que a BD possui uma coluna com nome usuários 11 -Injeção de código SQL As contramedidas para evitar a injeção de código SQL incluem: -Realizar validação da entrada completa. Seu aplicativo deve validar sua entrada antes de enviar uma solicitação ao banco de dados. -Utilizar procedimentos de armazenamento parametrizados para acesso ao banco de dados para garantir que as seqüências de entrada não são tratadas como instruções executáveis. Se você não puder utilizar procedimentos armazenados, use parâmetros SQL ao construir comandos SQL. - Utilizar contas menos privilegiadas para se conectar ao banco de dados. 12 6
1 Considerando a categoria Validação de entrada, quais são as categorias de ameaças existentes? 2 Explique o funcionamento da ameaça XSS. 3 Em qual aplicação o ataque de canonização é mais comum, escreva um exemplo de ataque. 4 Como podemos evitar o estouro de buffer em um aplicativo? 5 Quais são as contramedidas utilizadas para evitar o ataque de SQL Injection? 13 7