Ciclo de Desenvolvimento

Seguro e Segurança em
Aplicações Web
Riscos de Segurança em
Aplicações Web
Introdução

Módulo 6
Agenda

• Open Web Application Security Project (OWASP)

• Os dez riscos de segurança mais críticos em aplicações web
(OWASP Top 10 – 2017)
Riscos de Segurança em
Aplicações Web

Módulo 6 OWASP
• Comunidade aberta dedicada a capacitar organizações a desenvolver,
adquirir e manter aplicações confiáveis

• É uma fundação sem fins lucrativos, livre de pressões comerciais

Principais projetos:

– Top 10
– Testing Guide
– ZAP
– Dependency Check

www.owasp.org
Riscos de Segurança em
Aplicações Web

Módulo 6 OWASP Top 10 - 2017

 OWASP Top 10

O que é?
• Documento com 10 riscos de segurança mais críticos em aplicações Web

• Vulnerabilidade x Ameaça x Risco

• Ordenados de acordo com a exploração, prevalência, detecção e impacto

Principais Objetivos

• Sensibilização sobre segurança em aplicações

• Mostrar as consequência desses riscos

OWASP Top 10
Avaliação de Riscos

Metodologia de Classificação de Risco da OWASP

Risco = Probabilidade x Impacto

Riscos de Segurança em
Aplicações Web

Módulo 6 Injeção
2017 A1: Injeção
Modelo de interação: Usuário – Servidor – Banco de dados

Consultas ao BD realizadas via servidor Web/Aplicação

Aplicação Web tenta proteger BD de acesso ilícito

Acesso direto ao BD não é permitido
Falha na aplicação permite atacante romper proteção e acessar diretamente BD
 2017 A1: Injeção

Definição
Falhas de injeção 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

execução comandos indesejados ou acessos a dados não autorizados.

O que vai ser injetado depende do backend: SQL, OS, LDAP,...

Exploração Fácil Impacto Severo

2017 A1: Injeção

Cenário de Ataque

Query = “select * from Users where(name=‘$user’ and password=‘$pass’);”

Verdade Absoluta
Comentário

Query = “select * from Users where(name=‘joao’ OR 1=1); -- and password=‘whocares’);”

Isso retornará todos os registros da tabela!!

2017 A1: Injeção

Cenário de Ataque

String sql = "select * from tabela_usuarios where login='" + campo_login +"' and senha='" + campo_senha + "'";
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(sql);
if (rs.next())
System.out.println("Usuário Autenticado.");
else
System.out.println("Usuário ou Senha incorretos.");

– Aqui temos consultas onde a string SQL é concatenada com os parâmetros

(controlados pelo usuário) e assim executada
2017 A1: Injeção

Impacto
Muitas aplicações ainda são suscetíveis, mesmo sendo muito simples evitar

Fonte: Veracode State of Software Security 2017

Bases inteiras podem ser modificadas, lidas ou removidas

Pode levar ao controle total do sistema
2017 A1: Injeção

Impacto
2017 A1: Injeção

Impacto

Fonte: CTIR Gov

2017 A1: Injeção

Como Evitar?
1. Usar Prepared Statement nas consultas

String sql = "SELECT * FROM tabela_usuarios WHERE login = ? AND senha = ?";
PreparedStatement prepStmt = con.prepareStatement(sql);
prepStmt.setString(1,login);
prepStmt.setString(2,senha);
ResultSet rs = prepStmt.executeQuery();

2. Lista Branca:
– Validar dados de entrada aceitos no servidor
– Verificar por valores esperados e rejeitar os demais

3. Escapar caracteres especiais

2017 A1: Injeção
Riscos de Segurança em
Aplicações Web

Módulo 6 Quebra de Autenticação

2017 A2: Quebra de Autenticação

Definição
Fragilidades na autenticação e gerenciamento de sessão permitem que um
atacante assuma a identidade de um usuário, facilitando assim o vazamento de
informações.

Exploração Fácil Impacto Severo

2017 A2: Quebra de Autenticação

Cenários de Ataques
Cenário 1: Reserva de Passagem
Aplicação suporta reescrita de URL, colocando IDs de sessão na URL

Usuário autenticado envia link aos amigos

http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

Sem perceber, ele está enviando o sessionid

Seus amigos poderão acessar sua sessão, dados pessoais, cartão de crédito,...
 2017 A2: Quebra de Autenticação

Cenários de Ataques
Cenário 2: Timeout de Sessão
Tempo de expiração da aplicação não está definido corretamente.
Usuário utiliza computador público e em vez de selecionar “logout” ele
simplesmente fecha o navegador.
Atacante usa o computador mais tarde e o navegador ainda está autenticado.

Cenário 3: Força bruta

Sabendo nome do usuário válido, atacante pode utilizar listas de senhas
conhecidas para tentar, num ataque automatizado, autenticar na aplicação.
2017 A2: Quebra de Autenticação

Impactos
• Contas de usuários comprometidas ou sessões violadas (hijacked)

• Uma vez violada, o atacante poderá fazer tudo aquilo que a vítima tem
privilégio de fazer

• Contas de admin (root) são as mais procuradas

• Prejuízos financeiros e de imagem

 2017 A2: Quebra de Autenticação

Como Evitar?
1. Autenticação deve ser simples, centralizada e padronizada (CAS+Gerid)

2. TLS deve proteger o tempo todo, tanto as credenciais quanto o Session ID:
autenticação e navegação

3. Limitar o número máximo de tentativas de autenticação ou atrasar essa

operação (CAPTCHA)

4. Não utilizar credencias padrão

5. Quando possível, utilizar autenticação multifator

6. Cuidado na implantação de mecanismos que podem ser um possível atalho

para roubo de credenciais. Ex.: Primeiro Acesso e Esqueci Senha.
 2017 A2: Quebra de Autenticação

Como Evitar?
7. Gerar novos identificadores de sessão com elevado nível de entropia.

8. Esses identificadores não deve na URL (POST x GET)

9. Devem também ser invalidados após logout, inatividade ou ao final de um

determinado período de tempo

10. Ativar parâmetros de segurança em cookies de autenticação: HttpOnly e Secure

– HttpOnly: Evita que um script na máquina do cliente possa acessar e

manipular os cookies

– Secure: por valores: Quando ativado, os cookies só serão enviados via

conexão criptografada HTTPS
Riscos de Segurança em
Aplicações Web

Módulo 6 Exposição de Dados

Sensíveis
 2017 A3: Exposição de Dados Sensíveis

Definição
Dados sensíveis são expostos a pessoas não autorizadas: credenciais de acesso,
números de cartão de crédito, informações pessoais, etc.

A falha mais comum é simplesmente não criptografar os dados sensíveis

Quando a criptografia é usada, as falhas são relacionadas a algoritmos de

segurança fracos ou implementações inadequadas para armazenamento de senhas

Exploração Moderada Impacto Severo

2017 A3: Exposição de Dados Sensíveis

Cenários de Ataques
Cenário 1: Armazenamento incorreto de senha
• Senhas sendo armazenadas de modo incorreto: hashes vulneráveis ou sem sal.
Esses tipo de hash pode ser facilmente quebrado através de rainbow table

Cenário 2: Não utilizar HTTPS em todas páginas autenticadas

• O atacante monitora o tráfego de rede (como uma rede wireless aberta), e

rouba o cookie de sessão do usuário. O atacante então reproduz este cookie e
sequestra a sessão do usuário, acessando dados privados do mesmo.
2017 A3: Exposição de Dados Sensíveis

Impactos
• Comprometimento de dados que deveriam estar protegidos: Dados pessoais,
credenciais de acesso, dados médicos, cartões de crédito, ...

• Perda de confiança na organização, insatisfação de clientes

 2017 A3: Exposição de Dados Sensíveis

Como Evitar?
1. Identificar e criptografar todos os dados sensíveis em repouso e em trânsito

2. Não armazenar dados sensíveis desnecessariamente. Descarte-os o mais rápido

possível

3. Certifique-se de utilizar protocolos, algoritmos e chaves fortes. Force o uso de

criptografia como diretivas como o HTTP Strict Transport Security (HSTS)

4. Armazenar senhas com algoritmos projetados especialmente para a proteção

de senhas: argon2, scrypt, bcrypt
Riscos de Segurança em
Aplicações Web

Módulo 6 Entidades Externas

XML (XXE)
2017 A4: Entidades Externas XML (XXE)

Definição
Ocorre quando dados não confiáveis inseridos em XML contendo referência a
entidade externa são processados com um analisador de XML (XML parser)
configurado de forma insegura

Exploração Moderada Impacto Severo

 2017 A4: Entidades Externas XML (XXE)

Cenários de Ataques
Cenário 1: Atacante tenta extrair dados do servidor

Atacante intercepta requisição XML para reiniciar a senha e altera a mesma para
acessar arquivos no servidor
POST /forgot_pass HTTP/1.1
Host: shop.com
User-Agent: Mozilla/5.0
Accept-Language: en-US
Connection: keep-alive
<forgotpass>
<user> admin@shop.com </user>
</forgotpass>
POST /forgot_pass HTTP/1.1
Host: shop.com
User-Agent: Mozilla/5.0
Accept-Language: en-US
Connection: keep-alive
<?xml version="1.0"?>
<!DOCTYPE forgot_pass [
<!ELEMENT field ANY>
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<forgotpass>
<user>
<field name=“id”> &xxe; </field>
</user>
</forgotpass>
 2017 A4: Entidades Externas XML (XXE)

Cenários de Ataques

Caso o analisador de XML estiver configurado para processar entidades externas

(muitas estão por padrão), servidor web retornará conteúdo do arquivo solicitado.

HTTP/1.0 200 OK

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
(...)
 2017 A4: Entidades Externas XML (XXE)

Cenários de Ataques
Cenário 2: Atacante tenta um ataque de negação de serviço

POST http://example.com/xml HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM "file:///dev/random" >]>
<foo> &xxe; </foo>

Nesta requisição, o atacante tenta realizar um ataque DoS através de um arquivo

potencialmente recursivo
2017 A4: Entidades Externas XML (XXE)

Impactos
• Vazamento de dados, atacante pode recuperar arquivos do servidor

• Indisponibilidade: Entidade externa é um arquivo muito grande ou contém

uma referência recursiva

• Execução de comados externos no servidor

 2017 A4: Entidades Externas XML (XXE)

Como Evitar?
1. Maneira mais segura é desabilitando o processamento de entidade externa

2. Ferramentas de SAST são grande aliadas na busca por XXE

Riscos de Segurança em
Aplicações Web

Módulo 6 Controle de Acesso Ineficiente

 2017 A5: Controle de Acesso Ineficiente

Definição
Estão relacionada as restrições sobre aquilo que os usuários autenticados são
autorizados a fazer.

Usuário autenticado muda valor de um parâmetro que se refere diretamente a um

objeto do sistema por outro objeto que o usuário não está autorizado.

Exploração Moderada Impacto Severo

2017 A5: Controle de Acesso Ineficiente

Cenário de Ataque 1
 2017 A5: Controle de Acesso Ineficiente

Cenário de Ataque 2
Usuário autenticado força navegação em URLs que ele não deveria ter acessa

– http://example.com/app/getappInfo
– http://example.com/app/admin_getappInfo

Caso um usuário sem perfil de administrador consiga acessar a página

admin_getappinfo, teremos uma falha no controle de acesso.
2017 A5: Controle de Acesso Ineficiente

Impactos
• Impactos na confidencialidade, integridade e disponibilidade das informações
referenciadas pelo parâmetro vulnerável

– Confidencialidade: ler dados sensíveis

– Integridade: modificar dados sensíveis
– Disponibilidade: apagar dados sensíveis

• Contas de administrador são as mais visadas

 2017 A5: Controle de Acesso Ineficiente

Como Evitar?
1. Módulo de autorização consistente, que negue todo acesso por padrão,
exigindo papel específico no acesso a todas funções (ASDS).

2. Desativar a listagem de diretórios no servidor.

3. Utilizar identificadores que possam ser expostos com segurança. Por exemplo,
funções hash ao invés de números incrementais.
Riscos de Segurança em
Aplicações Web

Módulo 6 Configurações Incorretas de

Segurança
2017 A6: Configuração Incorreta de Segurança

Definição
O sistema onde a aplicação está inserida possui muitas camadas como rede, SO,
servidores web e de aplicação, frameworks, bibliotecas, banco de dados, etc.

Configurações incorretas são comumente resultado de:

– Uso de configurações padrão
– Configurações incompletas
– Cabeçalhos HTTP mal configurados
– Mensagens de erro contendo informações sensíveis.

Exploração Fácil Impacto Moderado

2017 A6: Configuração Incorreta de Segurança

Segurança de Aplicações é um trabalho compartilhado

2017 A6: Configuração Incorreta de Segurança

Cenários de Ataque
• A listagem de diretórios ativada no servidor

• Erros gerando mensagens detalhadas incluindo, por exemplo, o stack trace

• Classes, usuários, serviços de teste não retirados quando forem pra produção.

• Utilização de senhas padrão

2017 A6: Configuração Incorreta de Segurança

Impacto
• Frequentemente proporciona ao atacante acesso não autorizado a dados ou
funcionalidades do sistema

• Em casos mais extremos, todo o sistema pode ser comprometido

2017 A6: Configuração Incorreta de Segurança

Como Evitar?
1. Varreduras e auditorias periódicas para detectar vulnerabilidades nas
configurações ou correções ausentes

2. Ambientes de desenvolvimento, homologação e produção devem ser todos

configurados de forma idêntica (com senhas diferentes usadas em cada
ambiente)

3. Processo automatizado de criação de ambientes (nuvem)

4. Utilização de cabeçalhos de segurança: Secure, HttpOnly, X-Frame-Options,...

Riscos de Segurança em
Aplicações Web

Módulo 6 Cross-Site Scripting (XSS)

 2017 A7: Cross-Site Scripting (XSS)

Definição
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.

Permite que um atacante injete scripts maliciosos que serão executados pelo
navegador.

Os dois tipos mais comuns são persistente e refletido.

Exploração Fácil Impacto Moderado

2017 A7: Cross-Site Scripting (XSS)

Cenário de Ataque
XSS Persistente Código malicioso é
armazenado na aplicação.

Ex: Comentário em um
blog com JS malicioso.

Ataque afetará qualquer

um que visualizar o
comentário – Ao invés de
mostrar o suposto
comentário irá executar o
código malicioso.
2017 A7: Cross-Site Scripting (XSS)

Cenário de Ataque
XSS Refletido

Código malicioso é
enviado através de um
link.

Ex: E-mail contendo um

phishing.

Afetará apenas usuários

que acessarem aplicação
via link malicioso
2017 A7: Cross-Site Scripting (XSS)

Impactos
• Praticamente, metade das aplicações são vulneráveis a XSS

Veracode, 2019

• Permite execução de scripts no navegador da vítima, levando a:

– Roubo de cookies de sessão
– Desfigurar site (defacement)
– Redirecionamento de usuários, podendo forçar download de arquivos
maliciosos
– Acesso a informações no navegador, como o histórico de navegação
 2017 A7: Cross-Site Scripting (XSS)

Como Evitar?
Nunca confiar nos dados vindo do usuário:

1. Validação de dados:
– Filtrar adequadamente todos os dados de entrada
– Lista branca

2. Bibliotecas de escape de saída de caracteres como o OWASP Java Encoder

Project

3. Utilizar a flag HTTPOnly nos cookies: JS não poderá acessá-los

Riscos de Segurança em
Aplicações Web

Módulo 6 Desserialização Insegura*

*Item adicionado via pesquisa na indústria

 2017 A8: Desserialização Insegura

Definição
Serialização é o processo de converter um objeto numa representação/formato em
que possa ser armazenado ou transmitido com uma maior facilidade

Desserialização é o processo de recriar o objeto a partir dessa representação

 2017 A8: Desserialização Insegura

Definição
Desserializar significa recuperar dados (ou estado de um objeto) a partir de um
conjunto de bytes, garantindo que eles representem as mesmas informações.

Exploração dessa vulnerabilidade é bem difícil, visto que exploits prontos

raramente funcionam

Exploração Difícil Impacto Severo

 2017 A8: Desserialização Insegura

Cenário de Ataque 1
Um fórum utiliza serialização para salvar um ‘super cookie’. Este contém ID do
usuário, papel, hash de senha e outro estado:

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Uma atacante altera o objeto serializado para dar para um determinado usuário
privilégio de administrador

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
 2017 A8: Desserialização Insegura

Cenário de Ataque 2
O carrinho de compras de um usuário é salvo como um objeto serializado

{"productId“ : 6, "amount": "2", price:"42.00"}

Atacante altera preço na esperança que aplicação não cheque o objeto serializado

{"productId“ : 6, "amount": "2", price:"5.00"}

 2017 A8: Desserialização Insegura

Cenário de Ataque 2
No caso de desserialização insegura, a aplicação utilizará os dados sem validação

Usuário malicioso pagará apenas o preço do objeto desserializado

2017 A8: Desserialização Insegura

Impactos
• Essas falhas podem levar a:
– Execução remota de códigos
– Ataques de negação de serviço
– Ataques ao controle de acesso
– Abusos na lógica da aplicação
 2017 A8: Desserialização Insegura

Como Evitar?
• Solução mais segura é não aceitar objetos serializados de fontes não confiáveis

• Caso não seja possível, considerar:

– Implementação teste de integridade nos objetos serializados
– Isolar ambiente de execução da desserialização de objetos
– Monitoramento para alertar no caso de usuário realizando constantes
operações de desserialização

• Nunca confiar em entradas do usuário:

– Essa afirmação continua verdadeira para objetos serializados
Riscos de Segurança em
Aplicações Web

Módulo 6 Utilização de Componentes

Vulneráveis Conhecidos
2017 A9: Utilização de Componentes
Vulneráveis Conhecidos
Definição
Acontece quando a aplicação utiliza bibliotecas, frameworks e outros
componentes desatualizados e que contém vulnerabilidades conhecidas

Esses componentes frequentemente são executados com os mesmos privilégios da

aplicação. A exploração deles pode levar a perda de dados e o comprometimento
do servidor

Exploração Moderada Impacto Moderado

2017 A9: Utilização de Componentes
Vulneráveis Conhecidos
Como ocorre?
• Atacante identifica componente vulnerável via varredura na aplicação ou análise
manual

• Google Hacking pode ser utilizado:

– "Apache/2.0.40 server at" intitle:index.of

• Atacantes buscam exploits em fórum hacker e executam os ataques

2017 A9: Utilização de Componentes
Vulneráveis Conhecidos
Base de dados de vulnerabilidades
https://nvd.nist.gov/vuln/search
2017 A9: Utilização de Componentes
Vulneráveis Conhecidos
2017 A9: Utilização de Componentes
Vulneráveis Conhecidos
Impactos
• Gama de ataques:
– Falha no controle de acesso
– Injeções
– Ataques de negação de serviço

• O impacto vai depender da vulnerabilidade do componente e do ativo

protegido
2017 A9: Utilização de Componentes
Vulneráveis Conhecidos
Como Evitar?
• Monitorar continuamente as versões dos componentes do sistema. Ferramentas
automatizadas como o OWASP Dependency-Check podem auxiliar

• Remover componentes e dependências não utilizadas

• Só utilizar componentes vindos de fontes oficiais e seguras

Riscos de Segurança em
Aplicações Web

Módulo 6 Registro e Monitoração

Insuficiente*

*Item adicionado via pesquisa na indústria

 2017 A10: Registro e Monitoração Insuficiente

Definição
Registo e monitoramento insuficientes permite que os atacantes possam abusar
do sistema de forma persistente, usar como entrada para atacar outros sistemas e
que alterar, extrair ou destruir dados.

Atacantes confiam na ausência de monitoramento e capacidade de resposta para

atingirem seus objetivos sem serem detectados.

Exploração Moderada Impacto Moderado

 2017 A10: Registro e Monitoração Insuficiente

Cenários de Ataque
• Eventos como autenticação e falhas de autenticação não registrados em logs

• Aplicação incapaz de detectar e alertar em tempo real um ataque em curso

2017 A10: Registro e Monitoração Insuficiente

Impacto
• Muitos ataques bem sucedidos começam com a varredura automática de
vulnerabilidades.

• A não detecção dessas varreduras aumenta a taxa de sucesso para perto dos
100%.
 2017 A10: Registro e Monitoração Insuficiente

Como Evitar
• Utilizar um mecanismo de log centralizado

• Assegurar que todas as autenticações e falhas no controle de acesso sejam

registados e mantidas por tempo suficiente que permita a análise forense.

• Assegurar que todas demais transações críticas do sistema sejam registradas

• Definir processos de monitoramento e alerta capazes de detectar atividades

suspeitas
 Resumo do Módulo

• Os dez riscos de segurança mais

críticos em aplicações web
(OWASP Top 10 – 2017)