14/09/2020
Prof. Dr. Carlos André Batista de Carvalho
§ Aspectos legais e éticos
§ Segurança no Desenvolvimento de Aplicações
§ Ciclo de desenvolvimento seguro
§ Codificação segura e Boas práticas
§ Controles proativos
§ Riscos de Segurança em Aplicações Web
§ OWASP Top Ten
§ SQL Injection
§ Cross-Site Scripting (XSS)
§ Testes de Segurança em Aplicações Web
Desenvolvimento Seguro
1
14/09/2020
§ Conformidade de sistemas
§ Legislações
§ HIPAA, LGPD, etc
§ Padrões Internacionais
§ Profissionais também devem obedecer a legislação
§ Direito Digital
§ Tipificação de crimes em ambientes computacionais
§ Os testes de invasão devem ser previamente autorizados
§ Validade jurídica de transações virtuais
§ Referência
§ Capítulo 1 do livro do Bruno Fraga
Desenvolvimento Seguro
§ Acordo de confidencialidade (NDA)
§ Possui validade jurídica para penalizar as partes em caso de descumprimento
§ Não é evita o vazamento, mas é uma proteção para empresa
§ Contrato detalhado
§ Projeto a ser executado: responsabilidades, atividades e cronograma
§ Direitos de propriedade intelectual
§ Confidencialidade
§ Exceções
§ É utilizado para autorização e definição de escopo de testes de invasão
Desenvolvimento Seguro
2
14/09/2020
§ Código de conduta
§ Diversas áreas possuem seus códigos
§ Julgamento dos pares
§ Computação (ACM)
§ Morais
§ Evitar danos a terceiros, não discriminar, dá crédito a propriedade intelectual, entre outros
§ Responsabilidades
§ Respeitar as leis, adquirir e manter competência, honrar contratos, entre outros
§ Gerenciais (Liderança)
§ Gerir pessoas e recursos, especificar e autorizar o uso adequado dos recursos, entre outros
Desenvolvimento Seguro
§ Código de conduta
§ Segurança (ISC)
§ Proteger a sociedade, a comunidade e a infraestrutura
§ Agir com honra, honestidade, justiça, responsabilidade e legalidade
§ Prover um serviço diligente e competente
§ Avançar e proteger a profissão
§ Testes de invasão (EC-Council)
Desenvolvimento Seguro
3
14/09/2020
§ Código de conduta
§ Testes de invasão (EC-Council)
§ Privacidade
§ Divulgação autorizada
§ Propriedade intelectual
§ Não realizar atividades ilegais
§ Possuir autorizações
§ Qualidade do serviço
§ Gerenciamento e área de expertise
§ Compartilhamento de conhecimento
Desenvolvimento Seguro
§ Motivação
§ Softwares estão sujeitos a falhas
§ Acidentais: Erros de operação e programação
§ Intencionais: Ataques maliciosos que exploram eventuais vulnerabilidades
§ Fator humano
§ Codificação ingênua
§ Incidentes de segurança afetam as propriedades de segurança
§ Nível de impacto é variável
§ Riscos de segurança sempre existiram, mas aumentaram bastante com o desenvolvimento
Web
§ Envolvem aspectos relacionados com a rede de comunicação e/ou da própria aplicação
§ Plataformas móveis também possuem alta exposição
Desenvolvimento Seguro
4
14/09/2020
§ Software seguro é um software livre de vulnerabilidades e que funciona conforme
pretendido, sem comprometer as propriedades de segurança
§ Os softwares são desenvolvidos seguindo um processo que envolve algumas fases
§ O esforço para alterações em fases tardias são mais custosos
§ Envolvendo ou não requisitos de segurança
§ Existe ainda eventuais dados em casos de ataques, caso as falhas não sejam identificadas
previamente
§ Ciclo de desenvolvimento seguro
§ Identificação e tratamento adequado dos requisitos de segurança durante todo o processo
de desenvolvimento
Desenvolvimento Seguro
§ SDL (Security Development Lifecycle)
§ Adaptação do processo de desenvolvimento para incluir atividades inerentes a produção de
um software seguro em cada fase do processo de
§ https://www.microsoft.com/pt-br/download/details.aspx?id=12379
Desenvolvimento Seguro
10
5
14/09/2020
§ Treinamento
§ Nivelamento da equipe de desenvolvimento
§ Conceitos abordados
§ Princípios de projeto de segurança: privilégio mínimo, padrões abertos, defesa em profundidade,
etc.
§ Modelagem de ameaças
§ Como um atacante ver a aplicação?
§ Vetores de ataques e potenciais vulnerabilidades
§ Como se proteger e testar aplicações?
§ Boas práticas de codificação segura
§ Metodologias de testes
§ Privacidade de dados
Desenvolvimento Seguro
11
§ Requisitos
§ Além dos requisitos funcionais da aplicação, os requisitos de segurança devem ser
determinados
§ Análise de custos
§ Ex. gerenciamento de backup
§ Compatibilidade com as regras de negócio
§ Ex. gerenciamento de senhas
§ Gestão de segurança
§ Análise de riscos
§ Aceitação de riscos conhecidos (rastreamento de bugs)
§ Conscientizar o cliente que segurança não é custo
§ Danos de incidentes de segurança
Desenvolvimento Seguro
12
6
14/09/2020
§ Projeto
§ Redução da superfície de ataque
§ Ex. Isolar banco de dados
§ Modelagem de ameaças
§ Considera aspectos da arquitetura da aplicação
§ Identificação dos ativos e potenciais vulnerabilidades
§ Classificação de dados (informações sensíveis)
§ Padrões de ataques
§ Normalmente existe diversos ataques realizados em conjunto
§ Documentação e classificação das ameaças
§ Definição de controles de segurança
§ Observar príncipios de projeto
§ Ex. Algoritmos de criptografia
§ Uso de um checklist
Desenvolvimento Seguro
13
§ Classificação STRIDE (https://cutt.ly/dy3o0tO)
§ Spoofing
§ Falsificação de identidade
§ Tampering
§ Adulteração da informação ou sistema
§ Repudiation
§ Negação da execução de uma ação
§ Information disclosure
§ Divulgação indevida de informação
§ Denial of service
§ Interrupção de serviços
§ Elevation of privilegie
§ Obtenção de privilégios indevidos
Desenvolvimento Seguro
14
7
14/09/2020
§ Implementação
§ Boas práticas gerais de codificação
§ Revisão de código
§ Análise estática
§ Manual e automatizada
§ Codificação segura
§ Foi previsto na fase de projeto diversos controles. É a hora de implementá-los adequamente
§ Uso de ferramentas aprovadas e algoritmos seguros
§ Boas práticas para evitar ataques que explorem as falhas na codificação
Desenvolvimento Seguro
15
§ Verificação
§ Testes de software
§ Análise Dinâmica
§ Verificar comportamento do sistema quanto os aspectos de segurança
§ Ex. Problemas de privilégios
§ Ferramentas auxiliares
§ Testes de penetração
§ Teste de fuzzing
§ Gerar falhas por meio da inserção de dados aleatórios/defeituosos
§ Análise das exceções
§ Auditoria
§ Revisar modelo de ameaças e superfície de ataque
Desenvolvimento Seguro
16
8
14/09/2020
§ Liberação (Release)
§ Plano de gestão de incidentes
§ Equipe e serviços/procedimentos a serem realizados
§ Gestão de vulnerabilidades (cap. 7)
§ Ciclo das vulnerabilidades
§ Teste de patch de correção
§ Revisão de segurança
§ Checklist
§ Arquivamento de documentos e códigos
Desenvolvimento Seguro
17
§ Resposta
§ Execução do plano de gestão de incidentes
§ Aprender com os erros
§ Agile SDL (https://cutt.ly/fy8uNzA)
§ Adaptação do SDL para uso em metodologias ágeis
Desenvolvimento Seguro
18
9
14/09/2020
§ Outras metodologias S-SDLC
§ OWASP CLASP (Comprehensive, Lightweight Application Security Process)
§ Guia para equipe de desenvolvimento
§ Melhores práticas
§ Responsabilidades
§ Atividades
§ Vulnerabilidades e estratégias de mitigação
§ Estruturado em componentes a serem integrados aos processos de desenvolvimento
§ Visões
§ Recursos
§ Casos de uso
Desenvolvimento Seguro
19
§ Manter-se atualizado
§ Programação defensiva
§ Jamais assumir que o usuário irá utilizar o programa conforme esperado
§ Verificar consistência e completude de todos dos dados manipulados
§ Adotar práticas recomendadas
§ CERT, OWASP e Microsoft
§ As iniciativas envolve não apenas padrões de codificação
§ Modelagem de ameaças
§ Análise de código
§ Testes de segurança
Desenvolvimento Seguro
20
10
14/09/2020
§ Controles Proativos (OWASP)
§ Guia para orientar desenvolvedores
§ Treinamento
§ Considera aspectos relacionados com as principais vulnerabilidades (OWASP Top Ten)
§ Impacto positivo qualidade da aplicação
§ Redução nas vulnerabilidades
§ Elementos
§ Descrição do controle
§ Implementação
§ Vulnerabilidades
§ Referências
§ Ferramentas
Desenvolvimento Seguro
21
§ Definir requisitos de segurança
§ Observar as necessidades de segurança da aplicação
§ Legislação e órgãos de padronização
§ Existem catálogos que relacionam os requisitos com os respectivos controles
§ OWASP Application Security Verification Standard (ASVS)
§ Exposição de dados sensíveis
§ Comunicação segura (SSL/TLS)
§ Salvar senhas com hash e salt
§ Visão geral sobre padrões de segurança
§ Outros controles são mais específicos
§ Identificar e testar soluções
Desenvolvimento Seguro
22
11
14/09/2020
§ Fazer uso de frameworks de segurança e bibliotecas
§ Frameworks embutem controles de segurança
§ Necessário utilizar corretamente
§ Framework de persistência contem métodos/funções que protegem contra SQL Injection
§ Utilizar soluções padronizadas e atualizadas de segurança
§ Terceiros confiáveis
§ Previne diversas vulnerabilidades
§ Pode incluir uma nova: componentes com vulnerabilidades conhecidas
§ Ferramenta: OWASP Dependency Check
Desenvolvimento Seguro
23
§ Proteger o acesso aos bancos de dados
§ Consultas parametrizadas
§ Validação da entrada
§ Configuração adequada dos controles de segurança existentes nos SGBD
§ Acesso autenticado e autorizado
§ Comunicação protegida
§ Diretamente relacionado com SQL Injection
Desenvolvimento Seguro
24
12
14/09/2020
§ Codificação e escape de dados
§ Evitar que dados sejam interpretados de forma errada
§ Já usamos com os caracteres de controle (ex. aspas)
§ Validação na saída
§ Ataques de injeção e XSS
Desenvolvimento Seguro
25
§ Validação de dados
§ Verificar sintática e semanticamente as entradas
§ A entrada possui tipo e valor apropriado (ex. intervalo de datas)
§ Uso de expressões regulares
§ Uso de listas (branca ou preta) no processo de validação
§ Validação sempre no lado do servidor
§ Reduz a superfície de ataque
§ Nem sempre é possível distinguir entradas legítimas de maliciosas
§ Ex. SIGAA permite formatação dos textos
§ Deve ser utilizado em conjunto com outros controles
§ Diversos frameworks possuem métodos para validação de entradas
§ Relacionado com ataques de injeção, XSS e desserialização insegura
Desenvolvimento Seguro
26
13
14/09/2020
§ Implementar identidade digital
§ Relacionado com a autenticação de usuários e gerenciamento de sessão
§ Controle depende no nível de segurança exigido pela aplicação
§ Apenas login/senha pode ser suficiente
§ Como e quando aplicar múltiplos fatores?
§ Restrições quanto a elaboração de senhas
§ Proteção contra força bruta e das senhas armazenadas
§ Mecanismo de recuperação de senha (link em email, pergunta de segurança)
§ Geração e expiração de sessões
§ ID longo, único e aleatório
§ Proteções relacionadas aos cookies
Desenvolvimento Seguro
27
§ Aplicar controle de acesso
§ Verificação de permissões (autorização)
§ Toda requisição deve ter a permissão verificada
§ Ex. Comandos SQL para apagar dados/tabelas
§ Ex. Acesso a páginas de uma aplicação
§ Princípio do privilégio mínimo
§ Bloquear por padrão
§ Existem alguns mecanismos de controle de acesso
§ Lista de Controle de Acesso (ACL): quem pode acessar e quais as permissões (leitura/escrita)
§ Registrar eventos de controle de acesso
§ Tentativas erradas indicam a tentativa de ataques
Desenvolvimento Seguro
28
14
14/09/2020
§ Proteger os dados em todos os lugares
§ Relacionado com a proteção dos dados de acordo com sua sensibilidade
§ Cartões de crédito, senhas, registros de pacientes
§ Podem existir normas específicas para proteção dos dados
§ Proteção em repouso e em trânsito
§ Apenas TLS/SSL é insuficiente
§ Proteção da chave privada utilizada para estabelecimento das conexões
§ Gerenciamento de chaves é essencial para proteger dados em repouso
§ Desafio: processamento de dados em claro
§ O uso de técnicas para anonimização podem ser interessantes
§ Big Data
Desenvolvimento Seguro
29
§ Registro de logs e monitoramento
§ A análise de logs é essencial na investigação de um incidente e busca por soluções
§ Pode ser usado por sistemas de detecção de intrusão e para satisfazer requisitos
regulatórios
§ Não pode armazenar informação confidencial
§ O ideal é possuir proteção contra adulteração e ter localização distribuída
§ Algumas informações são padronizadas
Desenvolvimento Seguro
30
15
14/09/2020
§ Tratamento de erros e exceções
§ Mensagens de erro podem fornecer informações relevantes para um atacante
§ Nome de tabela, usuário, etc..
§ Tratar exceções de maneira centralizada e registrar em logs
§ Verificar cuidadosamente o tratamento de exceções
§ Além do vazamento de informações, o tratamento inadequado pode levar a negação do
serviço
Desenvolvimento Seguro
31
§ Tratamento de erros e exceções
§ Mensagens de erro podem fornecer informações relevantes para um atacante
§ Nome de tabela, usuário, etc..
§ Tratar exceções de maneira centralizada e registrar em logs
§ Verificar cuidadosamente o tratamento de exceções
§ Além do vazamento de informações, o tratamento inadequado pode levar a negação do
serviço
Desenvolvimento Seguro
32
16
14/09/2020
§ Principal referência: OWASP
§ Fundação sem fins lucrativos com diversos projetos inerentes a segurança Web (e também
Mobile)
§ Top Ten Vulnerabilities
§ Condificação segura
§ Controles proativos
§ Developers Guide (https://wiki.owasp.org/index.php/OWASP_Guide_Project)
§ Guia de referência rápida (https://owasp.org/www-pdf-archive/OWASP_SCP_v1.3_pt-BR.pdf)
§ Testing Guide
§ Testes relacionados a todo processo de desenvolvimento
§ Code Review Guide (https://wiki.owasp.org/index.php/Category:OWASP_Code_Review_Project)
§ Foco em testes de penetração
§ Ferramentas de apoio (WebScarab e WebGoat)
Desenvolvimento Seguro
33
§ É importante compreender os riscos associados ao desenvolvimento de softwares
§ As boas práticas estão relacionadas com controles para mitigar potenciais
vulnerabilidades
§ Esse guia apresenta uma visão geral das principais vulnerabilidades
§ Análise de risco
§ Facilidade de exploração (abuso)
§ Probabilidade de existência (prevalência)
§ Facilidade de encontrar e corrigir (deteção)
§ Impacto (apenas técnico)
§ Breve descrição com cenários de ataque e estratégias de mitigação
§ Referências
Desenvolvimento Seguro
34
17
14/09/2020
§ Injeção
§ “Falhas de injeção, tais como injeções de SQL, OS e LDAP ocorrem quando dados não-
confiáveis são enviados para um interpretador como parte de um comando ou consulta
legítima. Os dados hostis do atacante podem enganar o interpretador levando-o a executar
comandos não pretendidos ou a aceder a dados sem a devida autorização.”
§ Vulnerabilidade comum e bastante divulgada
§ Fácil de explorar e mitigar
§ Consultas e comandos são dinâmicos (usam dados fornecidos pelos usuários)
§ Validação e parametrização
§ Impacto elevado
§ Acesso não autorizado e ações resultantes desse acesso (controle total)
§ Inserção, alteração e remoção de dados (e até tabelas inteiras)
Desenvolvimento Seguro
35
§ Quebra de autenticação
§ “As funções da aplicação que estão relacionadas com a autenticação e gestão de sessões
são muitas vezes implementadas incorretamente, permitindo que um atacante possa
comprometer passwords, chaves, tokens de sessão, ou abusar doutras falhas da
implementação que lhe permitam assumir a identidade de outros utilizadores (temporária
ou permanentemente).”
§ Vulnerabilidade comum e bastante divulgada
§ Fácil de explorar, mas a mitigação também depende do fator humano
§ Força bruta, dicionário, senhas padrões, falhas no gerenciamento de sessões (ausência de timeout)
§ Sessões abertas em PCs públicos, senhas fracas, fornecimento de códigos de verificação
§ Autenticação multi-fator, senhas fortes, proteção contra força bruta, identificadores de sessão
aleatórios e não explícito em URLs
§ Impacto elevado
§ Acesso não autorizado (eventualmente com controle total) e revelação de informações sensíveis
Desenvolvimento Seguro
36
18
14/09/2020
§ Exposição de dados sensíveis
§ “Muitas aplicações web e APIs não protegem de forma adequada dados sensíveis, tais como
dados financeiros, de saúde ou dados de identificação pessoal. Os atacantes podem roubar
ou modificar estes dados mal protegidos para realizar fraudes com cartões de crédito, ou
outros crimes. Os dados sensíveis necessitam de proteções de segurança extra como
encriptação quando armazenados ou em transito.”
§ Vulnerabilidade comumente explorada
§ Requer ataques e controles mais complexos
§ Implementação adequada dos controles evitam que eles sejam burlados
§ Descarte de dados temporários, gerenciamento adequado de chaves, algoritmos fortes
§ Ataques de injeção podem retornar dados decifrados (ex. cartões de crédito)
§ Proteção de dados em trânsito é facilitada com o uso do SSL/TLS
§ O atacante tenta remover a proteção
§ O dano pela revelação de dados sensíveis é tradicionalmente elevado
§ Especialmente quando protegido por leis/regulamentações
Desenvolvimento Seguro
37
§ Entidades externas de XML (XXE)
§ “Muitos processadores de XML mais antigos ou mal configurados avaliam referências a
entidades externas dentro dos documentos XML. Estas entidades externas podem ser
usadas para revelar arquivos/pastas, execução de código remoto e ataques de negação de
serviço, tal como o ataque Billion Laughs.”
§ Vulnerabilidade adicionada na última versão
§ Identificada pela análise estática, mas requer implementação correta dos controles de
segurança
§ Validação de dados, bibliotecas atualizadas, utilizar o formato JSON
§ Uso de ferramentas auxiliares para execução dos ataques (ex. Burp Suite)
§ Interceptar e alterar o conteúdo das requisições para injeção do XML maliciosos
§ Impacto elevado
Desenvolvimento Seguro
38
19
14/09/2020
§ Quebra de controle de acesso
§ “As restrições sobre o que os usuários estão autorizados a fazer nem sempre são
corretamente verificadas. Os atacantes podem abusar destas falhas para aceder a
funcionalidades ou dados sem autorização, tais como dados de outras contas de usuário,
alterar as permissões de acesso, entre outros.”
§ Vulnerabilidade comum pela realização de testes inadequados
§ Nem sempre é fácil encontrar os pontos vulneráveis
§ Os ataques envolvem estratégias diferentes do SQL Injection
§ Alteração de URLs
§ Em aplicações complexas, a verificação pode ser inadequada em alguns pontos
§ Negar tudo por padrão
§ Obtenção de privilégios e dados sensíveis
Desenvolvimento Seguro
39
§ Configurações de segurança incorreta
§ “Uma boa segurança exige a definição de uma configuração segura e implementada na
aplicação, frameworks, servidor de aplicação, servidor web, banco de dados e plataforma.
Todas essas configurações devem ser definidas, implementadas e mantidas, já́ que
geralmente a configuração padrão é insegura. Adicionalmente, o software deve ser
mantido atualizado.”
§ A configuração incorreta resulta em falhas conhecidas pela comunidade, que pode ser
facilmente exploradas
§ As recomendações de proteção não são complexas, mas normalmente são negligenciadas
§ Testes podem detectar configurações incorretas
§ Funções desnecessárias, contas padrões
§ Tratamento de erros
§ Utilização de componentes vulneráveis
§ Impacto moderado
§ Eventualmente compromete um sistema por completo
Desenvolvimento Seguro
40
20
14/09/2020
§ Cross-Site Scripting (XSS)
§ “Falhas XSS ocorrem sempre que uma aplicação recebe dados não confiáveis e os envia ao
navegador sem validação ou filtro adequados. XSS permite aos atacantes executarem
scripts no navegador da vitima que podem “sequestrar” sessões do usuário, desfigurar
sites, ou redirecionar o usuário para sites maliciosos.”
§ Relatórios mostram que muitas aplicações estão vulneráveis
§ Fácil de explorar e mitigar
§ O atacante insere um script que podem ser executados no computador da vítima
§ Comentários em uma página Web
§ Dentro de uma URL
§ Uso de frameworks com proteção nativa
§ Validação e escaping
§ O impacto para a vítima depende do tipo de ataque XSS
§ Refletido, armazenado, DOM (Document Object Model)
Desenvolvimento Seguro
41
§ Desserialização insegura
§ “Desserialização insegura normalmente leva à execução remota de código. Mesmo que isto
não aconteça, pode ser usada para realizar ataques, incluindo ataques por repetição,
injeção e elevação de privilégios.”
§ Nova vulnerabilidade citada diante da tendência do aumento de incidentes enquanto
soluções adequadas não estiverem disponíveis
§ Recomendação é utilizar apenas tipos primitivos
§ Caso não seja possível: verificação de integridade, monitoramento, desserialização sem privilégios
§ Difícil de explorar
§ Auxlio de ferramentas (Burp Suite)
§ Ex.: Elevar privilégios, alterando o objeto (cookie) transmitido
§ Impacto elevado
Desenvolvimento Seguro
42
21
14/09/2020
§ Utilização de componentes vulneráveis
§ “Componentes, tais como bibliotecas, frameworks, e outros módulos de software quase
sempre são executados com privilégios elevados. Um ataque a um componente vulnerável
pode causar sérios dados. As aplicações que utilizam componentes com vulnerabilidades
conhecidas podem enfraquecer as suas defesas.”
§ É muito frequente o uso de componentes vulneráveis, mas eles nem sempre são explorados
facilmente
§ Vulnerabilidades encontradas recentemente e ainda sem correções
§ Ferramentas auxiliam a identificar a existência de vulnerabilidades
§ Inviabilidade de substituir o componente vulnerável e até mesmo de atualizá-lo
§ O atacante deve localizar o componente e alterar o exploit
§ Ex. Implementações antigas do OpenSSL são vulneráveis ao Heartbleed, que permite acesso a
memória do servidor
§ O impacto depende da vulnerabilidade
Desenvolvimento Seguro
43
§ Registro e monitoramento insuficientes
§ “O registo e monitoramento insuficientes permite que os atacantes possam continuar
realizando ataques sem serem detectados. Alguns dos estudos demonstram a demora em
identificar violações de dados.”
§ Os testes de penetração mostram se registro está sendo feito adequadamente
§ Essa vulnerabilidade mostra a importância da definição e aplicação de um plano para
tratamento de incidentes
§ O monitoramento é uma atividade essencial desse plano para permitir a detecção de ataques
Desenvolvimento Seguro
44
22
14/09/2020
§ Tipo clássico de ataque de injeção
§ Toda aplicação que usam um SGBD precisa incluir proteções contra esse tipo de
ataque
§ As aplicações utilizam comandos SQL para realizar transações no banco de dados
§ As aplicações são dinâmicas, de modo que os comandos utilizam informações
passadas pelos usuários por meio dos campos
§ Um ataque ocorre quando comandos SQL são informados nesses campos
§ É necessário validar a entrada antes de executar comandos SQL
§ Embora o ataque seja relativamente simples, o impacto é elevado
§ Deletar tabelas, acessar um sistema sem permissão
§ Nem sempre envolve ferramentas adicionais
Desenvolvimento Seguro
45
§ Exemplo de ataque
§ Digitar a seguinte informação em um campo da aplicação
§ Encerra o comando da aplicação e executa a remoção da tabela usuário
§ Nesse caso, o atacante precisa descobrir previamente o nome da tabela
§ As mensagens de erros podem ajudar nessa tarefa
§ A habilidade do atacante permite executar uma infinidade de ataques
§ É possível recuperar até dados de cartão de crédito
Desenvolvimento Seguro
46
23
14/09/2020
§ O foco é testar a segurança de aplicações
§ Verificar a existência ou não da vulnerabilidade
§ A verificação mais comum é a tentativa de acesso não autorizado
Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
Desenvolvimento Seguro
47
§ Entendendo o ataque
§ Esse comando retorna todos os usuários, mas como foi executado no login o acesso será
feito com o primeiro usuário da tabela (normalmente um administrador)
Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
Desenvolvimento Seguro
48
24
14/09/2020
§ Porque o ataque funciona?
§ Concatenação dos parâmetros diretamente na string que monta o comando SQL
§ Exemplo em Java
Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
Desenvolvimento Seguro
49
§ Como se proteger?
§ Não confie em seus usuário
§ Ambiente Web
§ Sempre valide/trate as entradas
§ Frameworks podem fazer essa validação se
usados corretamente
§ A biblioteca JDBC foi utilizada no código
anterior
§ Consultas parametrizadas
§ Java (PerparedStatement) Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
§ Função para validação dos parâmetros
Desenvolvimento Seguro
50
25
14/09/2020
§ Depois de obter acesso, o atacante pode realizar diversas ações do sistema
§ Os ataques podem variar conforme o SGBD alvo
§ Existem diferentes laboratórios abordando variações desse ataque, usando diversos
comandos diferentes, tendo impactos diferentes
§ https://portswigger.net/web-security/sql-injection
§ Modificar ou inserir dados
§ Requer outras atividades preliminares
§ Coleta de dados
Desenvolvimento Seguro
51
§ Inerente ao uso de trechos de HTML (e scripts) em campos de uma aplicação e em
URLs
§ Os campos podem, por exemplo, personalizar as páginas (ex. SIGAA) ou inserir
comentários
§ O ataque é “concretizado” sempre que a página for acessada pela vítima
§ Execução do script pelo navegador da vítima
§ Exemplos de ações
§ Adicionar como amigo, fazer postagens (Samy Worm)
§ Redirecionamentos ou envio de dados para páginas maliociosas
§ Mitigação: validação de dados
Desenvolvimento Seguro
52
26
14/09/2020
§ Exemplo de ataque
§ Enviar um script para coletar dados por um campo de uma página
§ XXS Armazenado
§ Ao acessar a página que mostra os campos digitados o script é executado
§ Envio de dados fornecidos pela vítima
Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
Desenvolvimento Seguro
53
§ Exemplo de ataque
§ Enviar um script pelo campo de busca
§ A execução do script seria na máquina do atacante
§ É possível copiar o link (URL) e enviar para as vítimas
§ XSS Refletido
§ https://www.casadocodigo.com.br/search?type=product&q=%3Cscript%3Ealert%281%29%3B%3C%
2Fscript%3E
Ataque sem sucesso
Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
Desenvolvimento Seguro
54
27
14/09/2020
§ Por que o ataque funciona?
§ O servidor processa a requisição do cliente e gera uma resposta com o script a ser
executado pelo cliente
§ O servidor não consegue diferenciar os scripts legítimos dos maliciosos
§ Mascarando o ataque
§ Scripts em tags HTML
§ Codificação Hexadecimal
Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
Desenvolvimento Seguro
55
§ Proteção
§ Validação e tratamento
§ Lista branca
§ Manter-se atualizado
§ XXS Filter Evasion Cheat Sheet
§ Bibliotecas AntiSamy
§ Configuração via XML
§ No exemplo, as tags são removidas
§ Mas é possível fazer o escape
§ O script aparece como texto simples
§ Exemplo de XSS Refletido
§ No exemplo, armazenamento ou processamento
da entrada limpa
Desenvolvimento Seguro
Rodrigo Ferreira. Segurança em aplicações Web. Casa do Código
56
28
14/09/2020
§ Os ataques focam em comprometer a vítima
§ Mas pode obter dados utilizados pela aplicação (login/senha)
§ Outra variação de XSS: DOM (Document Object Model)
§ Scripts que manipulam informações do cliente/vítima
§ É possível, por exemplo, sequestrar uma sessão (envio de cookies)
§ https://www.hacksplaining.com/lessons
§ https://hack.me/101525/u-hack-it-basic-exploits-tutorial.html
Desenvolvimento Seguro
57
§ Os testes de segurança fazem parte de todo processo de desenvolvimento
§ Análise de documentos
§ Observação aspectos de segurança (requisitos e controles)
§ Revisão de código
§ Testes de invasão/penetração
§ Uso de ferramentas automatizadas
Desenvolvimento Seguro
58
29
14/09/2020
§ OWASP Testing Guide (v4)
§ Checklist para realização de mais de 80 testes
§ Levantamento de informações
§ Gerenciamento de configuração e implantação
§ Autenticação, autorização e gerenciamento de sessões
§ Lógica de negócios
§ Preço e estoque negativo
§ Validação de dados
§ Negação de serviços
§ Tratamento de erros/exceções
§ Criptografia
§ Client Side
Desenvolvimento Seguro
59
§ Além de encontrar vulnerabilidades
§ Medir capacidade de detectar e se recuperar de ataques
§ Tipos de testes
§ Caixas preta, branca e cinza
§ Nível de conhecimento da equipe sobre os testes
§ Escopo, período
§ Regularidade dos testes
§ Normas regulatórias
§ Prevenção de danos
§ Plano de comunicação
Desenvolvimento Seguro
60
30
14/09/2020
§ Metodologia
§ Processo cíclico
§ Autores podem apresentar
metodologias diferentes
§ Bruno Fraga inclui uma atividade de pós-
exploração
§ Autorização prévia é indispensável
§ Documentação e apresentação
§ Viabiliza o aperfeiçoamento do
profissional e a reprodução de testes
§ Os relatórios devem incluir estratégias de
mitigação
§ Podem variar conforme o público alvo
Nelson Uto. Teste de Invasão em Aplicações Web. RPN/ESR
Desenvolvimento Seguro
61
§ Reconhecimento
§ Engenharia social, Google Hacking e NMAP
§ Coleta de informações para auxiliar os testes
§ Mapeamento
§ Relacionamento das informações coletadas
§ Arquitetura da aplicação
§ Ferramentas: Web Spiders
§ Modelagem de “possíveis” ameaças
§ Vetores de ataques
§ É possível que alguns dados sejam obtidos com a evolução dos testes
§ Ex.: Campos das tabelas
§ Exemplos de achados
§ Recuperação de senha (ex. perguntas secretas)
§ Regras para criação senhas (critérios para força bruta) e usuários
Desenvolvimento Seguro
62
31
14/09/2020
§ Identificação de vulnerabilidades
§ Planejamento dos testes a serem realizados
§ Localizar exploits inerentes às vulnerabilidades conhecidas
§ Ferramentas para varreduras de vulnerabilidades
§ Exploração de vulnerabilidades
§ Execução dos testes
§ Cuidado para não comprometer sistemas de produção
§ Não apenas detectar se uma aplicação está vulnerável
§ Identificação de potenciais danos
§ Identificação pontos para testes futuros
§ Ferramentas: Proxies de interceptação (Burp Suite, WebScarab) e Fuzzers
§ Podem ser realizadas em conjunto
Desenvolvimento Seguro
63
32
