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
§ 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
§ 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
§ 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
§ 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 danos 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 desenvolvimento

§ https://www.microsoft.com/pt-br/download/details.aspx?id=12379

Desenvolvimento Seguro
§ 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

§ 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
§ Conscientizar o cliente que segurança não é custo
§ Danos de incidentes de segurança

Desenvolvimento Seguro
§ 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 princípios de projeto
§ Ex. Algoritmos de criptografia
§ Uso de um checklist

Desenvolvimento Seguro

§ 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
§ 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 adequadamente
§ Uso de ferramentas aprovadas e algoritmos seguros
§ Boas práticas para evitar ataques que explorem as falhas na codificação

Desenvolvimento Seguro

§ 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
§ 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

§ 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
§ 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

§ Boas práticas
§ Relacionadas com diversas fases do SDL
§ Especialmente com a fase de implementação
§ Mitigação dos riscos existentes
§ Programação defensiva
§ Manter-se atualizado
§ Recomendações OWASP (Proactive Controls)
§ http://cutt.ly/lyIuUSN
§ https://owasp.org/www-project-proactive-controls/

Desenvolvimento Seguro
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
§ 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

§ 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
 § 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

§ 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
§ 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

§ 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

Desenvolvimento Seguro
§ É importante compreender os riscos associados ao desenvolvimento de softwares
§ As boas práticas estão relacionadas com controles para mitigar potenciais
vulnerabilidades
§ Metodologia para seleção do Top 10
§ Coleta de Dados: CWEs / CVEs / Análise de Apps (> 500 mil)
§ Contribuições científicas
§ Categorização e Classificação
§ Fatores
§ Passado e Futuro
§ Facilidade de exploração e mitigação
§ Impacto

§ Breve descrição com cenários de ataque e estratégias de mitigação

§ Referências

Desenvolvimento Seguro
§ 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.”
§ Violação de princípios: privilégio mínimo e seguro por padrão
§ Tipo de permissão
§ Os ataques envolvem diferentes estratégias (não confundir com quebra de autenticação)
§ Elevação de privilégios
§ Alteração de URLs
§ Tokens JWT e configuração incorreta do CORS
§ Em aplicações complexas, a verificação pode ser inadequada em alguns pontos
§ Nem sempre é fácil encontrar os pontos vulneráveis

Desenvolvimento Seguro

§ Falhas Criptográficas (Anteriormente: Exposição de dados sensíveis)

§ “Muitas aplicações web e APIs não protegem de forma adequada dados sensíveis e/ou
privados, 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.”
§ 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
§ Proteção de dados em trânsito é facilitada com o uso do SSL/TLS
§ O atacante tenta remover a proteção (MITM)
§ O dano pela revelação de dados sensíveis é tradicionalmente elevado
§ Especialmente quando protegido por leis/regulamentações

Desenvolvimento Seguro
§ 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”
§ Inclui: Cross-Site Scripting (XSS)
§ O atacante insere um script que podem ser executados no computador da vítima
§ Os scripts podem “sequestrar” sessões do usuário, desfigurar sites, ou redirecionar
§ Vulnerabilidade comum e bastante divulgada
§ Fácil de explorar e mitigar
§ Consultas e comandos são dinâmicos (usam dados fornecidos pelos usuários)
§ Uso de Frameworks para validação de dados (parametrização e escaping)
§ 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

§ Design Inseguro
§ É diferente de implementação insegura
§ Problemas de design não são corrigidos por uma implementação perfeita
§ Falhas relacionadas ao projeto dos controles de segurança (ausentes ou ineficientes)
§ Modelagem de ameaças, nível de segurança desejado
§ Proteção
§ Uso de um SDL
§ Bibliotecas de padrões de design
§ Gerenciamento de riscos e análise adequada dos controles de segurança
§ Atenção aos recursos computacionais e as camadas de proteção

Desenvolvimento Seguro
§ 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.”
§ Inclui: Entidades externas de XML (XXE)
§ Referências a entidades externas dentro dos documentos XML
§ Proteção: Validação de dados, bibliotecas atualizadas, utilizar o formato JSON
§ As recomendações de proteção não podem ser negligenciadas
§ Testes podem detectar configurações incorretas
§ Tratamento de erros
§ Utilização de componentes vulneráveis
§ Eventualmente compromete um sistema por completo

Desenvolvimento Seguro

§ Componentes vulneráveis e desatualizados

§ “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, que não são analisados adequadamente
§ 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
§ Monitoramento é fundamental
§ 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
§ Falhas de identificação e 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).”
§ 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

§ Falhas de Software e Integridade de dados

§ Inclui: Desserialização insegura
§ Proteção insuficiente no tratamento de objetos serializados
§ Mitigação: tipos primitivos, validação (integridade), desserialização sem privilégios
§ Ampliação:
§ Ex.: Injeção de código malicioso em softwares/atualizações
§ Verificação de integridade durante atualizações

Desenvolvimento Seguro
§ Falhas de registro e monitoramento de segurança
§ “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
§ Como e o que registrar?
§ 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

§ Server-Side Request Forgery (SSRF)

§ Falsificação de solicitação do lado do servidor
§ Permite ao atacante realizar requisições através de um servidor vulnerável
§ Acesso não autorizado a redes de comunicação e outros serviços
§ Ex.: Execução de comandos remotos (shell) explorando vulnerabilidades (CVEs) do Microsoft
Exchange Server
§ Mitigação
§ Camada de rede: Firewall (bloqueio a acessos remotos)
§ Camada de aplicativo
§ Validação de dados
§ Desativar redirecionamentos

Desenvolvimento Seguro
§ 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

Desenvolvimento Seguro

§ 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
§ 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

§ Metodologia PTES
§ Processo cíclico
§ Existem variações entre metodologias
§ Autorização prévia é indispensável
§ Não apenas voltado para segurança de aplicações
§ https://www.take.net/blog/tag/teste-de-invasao/
§ Fase 1: Preparação / Pré-engajamento
§ Autorização prévia é indispensável
§ Definição de escopo
§ Fase 2: Coleta de Informações
§ Engenharia social, Google Hacking e NMAP
§ Coleta de informações para auxiliar os testes

Desenvolvimento Seguro
§ Metodologia PTES
§ Fase 3: Modelagem de ameaças
§ Relacionamento das informações coletadas
§ Arquitetura da aplicação
§ Identificação de vetores de ataques
§ Mapeamento / Como Atacar?
§ Ferramentas: Web Spiders
§ É 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

§ Metodologia PTES
§ Fase 4: Análise de vulnerabilidades
§ Descoberta de falhas
§ Ferramentas para varreduras de vulnerabilidades
§ Planejamento
§ Localizar exploits inerentes às vulnerabilidades conhecidas
§ Fase 5: 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

Desenvolvimento Seguro
§ Metodologia PTES
§ Fase 6: Pós-exploração
§ Como manter o controle do sistema?
§ Ex.: Backdoor, Criar uma nova conta
§ Apagar rastros
§ Os ataques nem sempre são identificados imediatamente
§ https://anchisesbr.blogspot.com/2020/09/seguranca-quanto-tempo-leva-para.html
§ Fase 7: Relatórios
§ Documentar o processo conforme público alvo
§ Relatórios técnicos e executivos
§ Incluir recomendações de mitigação, limitações (o que não foi testado) e como reproduzir ataques

https://sectigostore.com/blog/13-vulnerable-websites-
Desenvolvimento Seguro web-apps-for-pen-testing-and-research/