Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
Webinar # 17 – Análise de Malware em Forense Computacional
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
1. Teste de Invasão em Aplicações
Web
Principais Técnicas de Exploração e Formas
de Prevenção
Rafael Soares Ferreira
Clavis Segurança da Informação
rafael@clavis.com.br
2. $ whoami
• Grupo Clavis
• Sócio Diretor Técnico
• Detecção e resposta a incidentes de segurança
• Testes de invasão em redes, sistemas e
aplicações.
6. Descrição
• Ocorre quando a aplicação envia dados não
tratados para algum serviço interno.
• Pode ser feita via SQL, LDAP, Xpath, comandos
de sistema operacional, argumentos de
programas, etc.
• Descoberta por varreduras e/ou fuzzers
• Mais facilmente por verificação de código.
9. Exemplo
• É possível editar a função de validação, ou
impedi-la de ser executada no navegador.
10. Exemplo
• Sem a função de validação é possível submeter a
string admin ‘ or ‘ -- que possibilita acesso ao
sistema.
11. Impactos
• Dependendo do tipo de injeção os danos
causados podem ser:
ü Perda ou corrupção de dados
ü Negação de Serviço
ü Falhas de autenticação
ü Execução arbitrária de código e até
comprometimento total do sistema.
12. Como se Prevenir
• Não utilizar dados não confiáveis em comandos
e/ou queries.
• Rotinas de validação ou “escape” de caracteres.
• É aconselhável o uso de validação positiva nas
entradas.
• Utilizar canonicalização de dados.
13. Referências
• Ferramenta para detecção e exploração de SQLi
http://sqlmap.sourceforge.net/
• Enterprise Security API – Input Validation
http://owasp-esapi-java.googlecode.com/svn/
trunk_doc/latest/overview-summary.html
• (OWASP) Reviewing Code for SQL Injection
https://www.owasp.org/index.php/
Reviewing_Code_for_SQL_Injection
15. Descrição
• Ocorre quando uma aplicação inclui dados não
tratados em um objeto enviado ao navegador.
• A detecção pode ser feita via teste de injeção ou
análise de código.
• Existem 3 principais tipos:
ü Stored
ü Reflected
ü DOM based XSS
16. Descrição
Stored:
• Código injetado é armazenado permanentemente
na aplicação vulnerável (comentários, posts, logs,
etc)
• A vítima recebe o código malicioso junto com
alguma requisição feita.
20. Exemplo
• O código então será submetido a todos que
visualizarem a descrição de tal arquivo.
21. Impactos
• Atacante pode executar scripts no navegador da
vítima para:
ü Roubo de informações de sessão
ü Pichação de Sites
ü Inserção de conteúdo malicioso
ü Redirecionamento de usuários e etc.
• Além da exposição de informações dos usuários,
tal falha pode denegrir a imagem da instituição
responsável pela aplicação.
22. Como se Prevenir
• “Escapar” caracteres vindo de fontes não
confiáveis e que serão utilizados no contexto do
navegador (body, atributos, JavaScript, CSS,
URL).
• A validação positiva é sempre interessante mas é
preciso atentar para peculiaridades da aplicação
em questão pois caracteres especiais e
codificações diversas podem fazer parte da rotina
da aplicação.
23. Referências
• Definição do CWE sobre Cross-Site Scripting
http://cwe.mitre.org/data/definitions/79.html
• RSnake's XSS Attack Cheat Sheet
http://ha.ckers.org/xss.html
• (OWASP) Reviewing Code for Cross-site scripting
https://www.owasp.org/index.php/
Reviewing_Code_for_Cross-site_scripting
24. Outras Ameaças
• Quebra de Autenticação / Sessão
• Referência direta à objetos
• Cross-Site Request Forgery (CSRF)
• Falhas de Configuração
• Armazenamento / Canal Inseguro