Apresentação 2 - Biblioteca de segurança para tratar as principais

Biblioteca de
segurança para tratar
as principais
vulnerabilidades web
Tarcizio Vieira Neto
DIOPE/COGSI/SISEC/SIDES
Líder em soluções de TI para governo
Apresentação pessoal
Tarcizio Vieira Neto
 4 anos de SERPRO, desde 2009 na área de segurança de
software
 certificado MCSO
 certificado CSSLP
[email protected]
(61) 2021-7486
Objetivos

Conhecer as principais vulnerabilidades de segurança
comumente encontradas em aplicações Web – OWASP Top 10

Apresentar a arquitetura da biblioteca OWASP ESAPI e como
esta arquitetura ajuda a resolver alguns das vulnerabilidades
listadas no Top 10
Motivação

Riscos de segurança em aplicações
– Os atacantes podem usar diversos caminhos através da aplicação
que potencialmente podem prejudicar o negócio ou a organização.
– Cada um desses caminhos representa um risco que pode, ou não,
ser prejudicial o suficientemente para justificar a sua atenção.
OWASP Top 10

A OWASP produz uma publicação chamada OWASP Top 10,
onde lista as 10 principais vulnerabilidades que afetam os
sistemas Web. Sobre a publicação:
– É lançada a cada 3 anos.
– A versão mais recente foi lançada em abril de 2013.
– O Top 10 não trata somente como evitar as vulnerabilidades,
mas também trata sobre gerenciamento de riscos.
– Para gerenciar estes riscos, as organizações precisam além
de ações de sensibilização, testes de aplicação e correção,
um programa de gestão de riscos de aplicações.
– As versões anteriores são de 2004, 2007 e 2010.
OWASP Top 10










A1: Falha de Injeção
A2: Quebra de autenticação e no Gerenciamento de Sessão
A3: Cross-Site Scripting (XSS)
A4: Referência Insegura e Direta a Objetos
A5: Configuração Incorreta de Segurança
A6: Exposição de Dados Sensíveis
A7: Falta de Função para Controle do Nível de Acesso
A8: Cross-Site Request Forgery (CSRF)
A9: Utilização de Componentes Vulneráveis Conhecidos
A10: Redirecionamentos e Encaminhamentos Inválidos
OWASP ESAPI

O que é a ESAPI?
– É uma API de segurança corporativa.
– Desenvolvido pela OWASP
– Licença BSD
– Linguagens:
• Java (Java EE)
• .NET
• ASP classico
• PHP
• ColdFusion
• Python
• Haskell
• Javascript
OWASP ESAPI
Fonte: Chris Schmidt, Solving Real World Problems with ESAPI, FROC 2010
OWASP ESAPI
Fonte: Chris Schmidt, Solving Real World Problems with ESAPI, FROC 2010
OWASP ESAPI
Problemática atual:
OWASP ESAPI

Arquitetura
OWASP ESAPI

Tratando Configuração de Segurança da Aplicação
OWASP ESAPI

Configurando a ESAPI
– A ESAPI foi projetada para ser facilmente extensível.
• As implementações de referência podem ser substituídas
por implementações próprias que se integram à
infraestrutura
de
segurança
já
existente.
• Isto permite que implementações de segurança sejam
facilmente substituídas sem a necessidade de reescrever
toda a aplicação.
A1: Falhas de Injeção

Características:
– Ocorrem quando dados não confiáveis são enviados para um
interpretador como parte de um comando ou consulta
– Os dados do ataque podem iludir o interpretador a executar
comandos indesejáveis ou acessar dados de forma não
autorizada.
– Os ataques de SQL Injection, baseiam-se na tentativa de
utilizar os parâmetros de entrada da aplicação para inserir
sequências de caracteres com propósitos maliciosos.
– Causados também por falta ou falha na validação de entrada
de dados
A1: Falhas de Injeção

Podem ser do tipo:
– SQL Injection (mais comum)
– XPATH Injection
– LDAP Injection,
– Comand Injection (tem como alvo o sistema operacional do
servidor)
– Injection into SOAP
– SMTP Command Injection
→ Os princípios são os mesmos, o que muda é a tecnologia.
A1: Falhas de Injeção

Ilustração: cenário de ataque SQL Injection
A1: Falhas de Injeção

Ilustração: cenário de ataque SQL Injection
A requisição pode ser enviada da seguinte forma:
http://example.com/app/accountView?userID=0'+or+1=1--
String userID = request.getParameter("userID");
Statement statement = connection.createStatement(
"SELECT * FROM accounts WHERE user_id = '"+ userID +"';");
ResultSet rs = statement.executeQuery();
Resultado da concatenação:
SELECT * FROM accounts WHERE user_id = '0' or 1=1--';
A1: Falhas de Injeção
Como evitar:
– Considerar todas as entradas de dados como não confiáveis
e fazer a validação
– Filtrar as entradas com uma lista de caracteres permitidos
(lista branca), rejeitando a entrada de tudo o que estiver fora
da lista
– Uma lista contendo os caracteres não permitidos (lista
negra) é uma opção que pode ser usada em conjunto com a
anterior
Obs.: Utilizar somente a lista negra é insuficiente, pois o
atacante pode utilizar formas variadas para uma mesma
entrada de dados!
A1: Falhas de Injeção

Como evitar (cont...):
– Realizar codificação dos dados de saída
– Utilizar consultas Parametrizadas:
String userID = request.getParameter("userID");
PreparedStatement prepStmt =
con.prepareStatement("SELECT * FROM accounts WHERE user_id = ?");
prepStmt.setString(1, userID);
ResultSet rs = prepStmt.executeQuery();
A1: Falhas de Injeção

Ilustração:
- Defesa através da codificação dos dados de entrada:
A1: Falhas de Injeção

Ilustração:
- Defesa através da codificação dos dados de entrada:
A1: Falhas de Injeção

Tratando Validação e Codificação com a ESAPI
A1: Falhas de Injeção

Codificação e Decodificação de Dados não Confiáveis
A1: Falhas de Injeção

Configurando Validator – ESAPI.properties
(...)
# Global HTTP Validation Rules
# Values with Base64 encoded data (e.g. encrypted state) will need at least [a-zA-Z0-9\/+=]
Validator.HTTPScheme=^(http|https)$
Validator.HTTPServerName=^[a-zA-Z0-9_.\\-]*$
Validator.HTTPParameterName=^[a-zA-Z0-9_]{1,32}$
Validator.HTTPParameterValue=^[a-zA-Z0-9.\\-\\/+=@_ ]*$
Validator.HTTPCookieName=^[a-zA-Z0-9\\-_]{1,32}$
Validator.HTTPCookieValue=^[a-zA-Z0-9\\-\\/+=_ ]*$
Validator.HTTPHeaderName=^[a-zA-Z0-9\\-_]{1,32}$
Validator.HTTPHeaderValue=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$
Validator.HTTPContextPath=^[a-zA-Z0-9.\\-\\/_]*$
Validator.HTTPServletPath=^[a-zA-Z0-9.\\-\\/_]*$
Validator.HTTPPath=^[a-zA-Z0-9.\\-_]*$
Validator.HTTPQueryString=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ %]*$
Validator.HTTPURI=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$
Validator.HTTPURL=^.*$
Validator.HTTPJSESSIONID=^[A-Z0-9]{10,30}$
# Validation of file related input
Validator.FileName=^[a-zA-Z0-9!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{1,255}$
Validator.DirectoryName=^[a-zA-Z0-9:/\\\\!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{1,255}$
(...)
A1: Falhas de Injeção

Configurando Validator - validation.properties
Validator.SafeString=^[.\\p{Alnum}\\p{Space}]{0,1024}$
Validator.Email=^[A-Za-z0-9._%'-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$
Validator.IPAddress=^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$
Validator.URL=^(ht|f)tp(s?)\\:\\/\\/[0-9a-zA-Z]([-.\\w]*[0-9a-zA-Z])*(:(0-9)*)*(\\/?)([a-zA-Z0-9\\-\\.\\?\\,\\:\\'\\/\\\\\\
+=&%\\$#_]*)?$
Validator.CreditCard=^(\\d{4}[- ]?){3}\\d{4}$
Validator.SSN=^(?!000)([0-6]\\d{2}|7([0-6]\\d|7[012]))([ -]?)(?!00)\\d\\d\\3(?!0000)\\d{4}$

Chamada referenciando expressão regular de validação:
String input = request.getParameter("email");
int maxLength = 512;
Boolean allowNull = false;
UserBean bean = new UserBean();
try {
bean.setEmail( ESAPI.validator()
.getValidInput("User Email", input, "Email", maxLength, allowNull));
}
A2: Quebra de autenticação e no Gerenciamento de
Sessão

Características:
– As funções de uma aplicação relacionadas com autenticação
e gestão de sessões muitas vezes são implementadas de
forma incorreta
• Desta forma, os atacantes podem comprometer senhas,
chaves, identificadores de sessão ou ainda explorar
outras falhas de implementação para assumirem a
identidade de outros usuários.
A2: Quebra de autenticação e no Gerenciamento de
Sessão

A aplicação está vulnerável se:
– As credenciais de autenticação de usuário não estão
protegidas utilizando hash ou criptografia, quando
armazenadas. Obs.: Ver A6.
– As credenciais podem ser descobertas através de funções de
gerenciamento
de
contas
fracas
por exemplo: criação de conta, alteração de senha,
recuperação de senha, IDs de sessão fracos.
– IDs
de
sessão
são
expostos
por exemplo: reescrita de URL.
na
URL
– IDs de sessão são vulneráveis a ataques de fixação de
sessão.
A2: Quebra de autenticação e no Gerenciamento de
Sessão

A aplicação está vulnerável se (cont...):
– IDs de sessão não expiram, ou sessões de usuário ou tokens
de autenticação, particularmente aqueles baseados em
single sign-on (SSO), e não são devidamente invalidados
durante o logout.
– IDs de sessão não são rotacionados após o login bemsucedido.
– Senhas, IDs de sessão, e outras credenciais são enviadas
através
de
conexões
não
criptografadas.
Obs.: Ver A6.
A2: Quebra de autenticação e no Gerenciamento de
Sessão

Como evitar:
– Um único modelo de controles para autenticação e
gerenciamento de sessão. Estes controles devem ser
capazes de:
• Atender todos os requisitos para autenticação e
gerenciamento de sessão definidos nas áreas V2
(Autenticação) e V3 (Gerenciamento de Sessão) do
Application Security Verification Standard (ASVS)
publicado pela OWASP.
– Fornecer uma interface simples para os desenvolvedores.
Obs.: Esforços devem ser tomados para evitar a ocorrência de
falhas de XSS que podem ser utilizados para roubar os IDs de
sessão. Obs.: ver A3
A2: Quebra de autenticação e no Gerenciamento de
Sessão

Tratando Autenticação com ESAPI
A2: Quebra de autenticação e no Gerenciamento de
Sessão

Tratando Autenticação com ESAPI
(...)
Tentativas de login permitidas
#======================================================================
# ESAPI Authenticator
Número de senhas que não podem se repetir
#
para determinado usuário
Authenticator.AllowedLoginAttempts=3
Authenticator.MaxOldPasswordHashes=13
Authenticator.UsernameParameterName=username
Authenticator.PasswordParameterName=password Nome dos campos de login/senha
# RememberTokenDuration (in days)
do formulário de login
Authenticator.RememberTokenDuration=14
# Session Timeouts (in minutes)
Authenticator.IdleTimeoutDuration=20
Tempo de duração do token em dias
Authenticator.AbsoluteTimeoutDuration=120
para implementar a funcionalidade
“Rember me”
Parâmetros de Timeout
#======================================================================
(...)
A3: Cross-Site Scripting (XSS)

Características:
– As falhas XSS ocorrem sempre que uma aplicação obtém
dados fornecidos pelo usuário (não confiáveis) e os envia
para um navegador web sem realizar o processo de
validação ou codificação daquele conteúdo de modo
conveniente.
– O XSS permite aos atacantes executarem scripts no
navegador da vítima, que pode ser usado para sequestrar
sessões de usuário, modificar a aparência de sites Web
e redirecionar o usuário para sites maliciosos.
A3: Cross-Site Scripting (XSS)

Tipos:
– Persistente
– Não Persistente
A3: Cross-Site Scripting (XSS)

XSS Persistente
– Cenário de ataque:
• Dados enviados por usuários são armazenados e
posteriormente mostrados para outro ou outros usuários
sem
que
sejam
codificados
• Podem atingir grandes quantidades de usuários (blogs,
forums)
• Dados armazenados (banco de dados, arquivo, etc)
• Sem validar entrada de dados
• Sem codificar saída de dados
A3: Cross-Site Scripting (XSS)

XSS Persistente - cenário de ataque (parte 1)
A3: Cross-Site Scripting (XSS)

XSS Persistente - cenário de ataque (parte 2)
A3: Cross-Site Scripting (XSS)

Ilustração: -Defesa através da validação dos dados de entrada
A3: Cross-Site Scripting (XSS)

Ilustração: -Defesa através do mecanismo de codificação dos
dados de saída
A3: Cross-Site Scripting (XSS)

XSS Não Persistente
– Cenário de ataque:
• Dado enviado por usuário ao servidor é enviado de volta
ao usuário na resposta do servidor
• Caso haja código em meio a esses dados, ele pode ser
executado no navegador do cliente
A3: Cross-Site Scripting (XSS)

XSS Não Persistente - cenário de ataque
A3: Cross-Site Scripting (XSS)

XSS Não Persistente - cenário de ataque
– A aplicação usa dados não confiáveis na construção dos tags
HTML sem realizar a codificação dos dados, conforme o
exemplo a seguir:
<html>
(...)
Nome: <%= request.getParameter("nome") %>
(...)
</html>
– A URL inclui um script no parâmetro da aplicação
http://www.example.com/view.jsp?nome="<script>alert(document.cookie)</script>"
A3: Cross-Site Scripting (XSS)

XSS Não Persistente Defesa através da validação dos dados de entrada
A3: Cross-Site Scripting (XSS)

XSS Não Persistente Defesa através através do mecanismo de codificação dos dados
de saída
A3: Cross-Site Scripting (XSS)

Como evitar XSS (de modo geral):
– Tratar as saídas (output) para o cliente usando escaping ou
encoding de caracteres, fazendo com que o script submetido
pelo atacante seja tratado como texto a ser renderizado pelo
navegador, ex:
<script> alert (); </script>
↓
<script> alert() <script>

Como tratar a saída:
– Utilizando frameworks que auxiliam na proteção contra XSS
– Para conteúdo rico considere bibliotecas de auto-sanitização
como OWASP's AntiSamy ou o Java HTML Sanitizer Project.
A3: Cross-Site Scripting (XSS)

Codificação e Decodificação de Dados não Confiáveis
A4: Referência Insegura e Direta a Objetos

Características:
– Uma referência direta a um objeto ocorre quando um
programador expõe uma referência para um objeto interno da
implementação, como:
• Arquivo
• Diretório
• Chave de uma tabela no banco de dados
• URL
• Parâmetro de formulário
A4: Referência Insegura e Direta a Objetos

Cenário de ataque:
– Sem uma verificação de controle de acesso ou outra
proteção semelhante, os atacantes podem manipular estas
referências para acessar informações ou outros objetos nãoautorizados.
– Cenário 1: Mudança no identificador presente na URL
URL gerada pela aplicação:
http://www.example.com/visualiza_info_conta.jsp?userId=4325110 ← acesso legítimo
URL adulterada:
http://www.example.com/visualiza_info_conta.jsp?userId=5432112
← acesso indevido
A4: Referência Insegura e Direta a Objetos

Cenário de ataque:
– Cenário 2: Mudança no identificador de um arquivo presente
na
URL
URL gerada pela aplicação:
http://www.example.com/downloadFile.do?filePath="/var/lib/docs/file1.doc"
← acesso legítimo
URL adulterada:
http://www.example.com/downloadFile.do?filePath="/var/lib/docs/file2.doc" ← acesso indevido
http://www.example.com/downloadFile.do?filePath="/etc/shadow"
← acesso indevido
A4: Referência Insegura e Direta a Objetos

Como evitar:
– Evite expor referências a objetos internos.
– Verificar o acesso – através de verificação de controle de
acesso para garantir se o usuário está autorizado a acessar
o recurso solicitado
– Use referência indiretas a objetos por usuário ou sessão.
• Isso
impede que o atacante atinja diretamente os
recursos não autorizados.
• A aplicação tem que mapear as referências indiretas por
usuário de volta para a chave do banco de dados real no
servidor.
A4: Referência Insegura e Direta a Objetos

Tratando Referências Direta a Objetos com a ESAPI
A4: Referência Insegura e Direta a Objetos

Como evitar (cont...):
– Use referência indiretas a objetos por usuário ou sessão
– Exemplo de URL gerada utilizando mapa de referência
indireta aos objetos
http://www.example.com/visualiza_info_conta.jsp?userId=12F01BA430
A5: Configuração Incorreta de Segurança

Características:
– A segurança depende também da existência de
configurações seguras específicas definidas e usadas na
aplicação, frameworks, servidor de aplicação, servidor de
Web e plataforma.
– Todas as configurações devem ser definidas, implementadas
e mantidas → muitas vezes elas não vem aplicadas
diretamente do fornecedor com padrões de segurança
definidos.
– Isto inclui também possuir todo o software atualizado,
incluindo todas as bibliotecas de código usadas pela
aplicação.
– Possui mais ligação com o ambiente de produção do que
com o código da aplicação.
A5: Configuração Incorreta de Segurança

Como evitar:
– Um processo de hardening recorrente que torne fácil e rápido
de implantar outro ambiente que está devidamente blindado
– Um processo para se manter a par e implantar todas as
novas atualizações e correções de software (patch de
segurança) em tempo hábil e em cada ambiente.
– Executar varreduras de segurança e fazer auditorias
periodicamente para ajudar a detectar erros futuros de
configuração ou correções ausentes
A6: Exposição de Dados Sensíveis

Características:
– Muitas aplicações Web não protegem devidamente dados
sensíveis, como números dos cartões de créditos, dados
pessoais e credenciais de autenticação com algoritmos de
cifra ou de resumo (hash).
– Os atacantes podem roubar ou modificar estes dados,
protegidos de forma deficiente, para realizar roubos de
identidade, fraude com cartões de crédito ou outros crimes.
A6: Exposição de Dados Sensíveis

Como evitar:
– Para todos dados sensíveis devemos assegurar que:
• Sejam criptografados nos locais onde são armazenados a
longo prazo, especialmente nos backups de dados.
• Somente usuários autorizados podem acessar as cópias
dos dados decriptografados.
• Um padrão de algoritmo de criptografia forte
(preferencialmente os recomendados pelo e-ping e ICPBrasil) esteja sendo utilizado.
• Uma chave forte tenha sido gerada, protegida contra
acesso não autorizado e que a troca das chaves seja
planejada.
A6: Exposição de Dados Sensíveis

Tratando Informações Sensíveis com a ESAPI
A6: Exposição de Dados Sensíveis

Tratando Informações Sensíveis com a ESAPI
A6: Exposição de Dados Sensíveis

Configurando o Encryptor
(...)
#==========================================================================
# ESAPI Encryption
# To calculate these values, you can run:
#
java -classpath esapi.jar org.owasp.esapi.reference.crypto.JavaEncryptor
Encryptor.MasterKey=a6H9is3hEVGKB4Jut+lOVA==
Encryptor.MasterSalt=SbftnvmEWD5ZHHP+pX3fqugNysc=
Encryptor.PreferredJCEProvider=SunJCE
# Warning: This property does not control the default reference implementation for
#
ESAPI 2.0 using JavaEncryptor. Also, this property will be dropped
#
in the future.
# @deprecated
# Encryptor.EncryptionAlgorithm=AES
#
For ESAPI Java 2.0 - New encrypt / decrypt methods use this.
Encryptor.CipherTransformation=AES/CBC/PKCS5Padding
Encryptor.cipher_modes.combined_modes=GCM,CCM,IAPM,EAX,OCB,CWC
Encryptor.cipher_modes.additional_allowed=CBC
(...)
A7: Falta de Função para Controle do Nível de Acesso

Características:
– Muitas aplicações Web verificam os direitos de acesso a uma
URL antes de exibirem links e botões protegidos.
– As aplicações devem realizar verificações de controles de
acesso semelhantes cada vez que estas páginas são
acessadas.
– Caso contrário, os atacantes podem forjar URLs e acessar
estas páginas escondidas, sem qualquer controle.
A7: Falta de Função para Controle do Nível de Acesso

Cenário de ataque:
– O atacante modifica o apontamento da URL de destino no
browser
URL gerada pela aplicação:
http://example.com/app/getappInfo
← acesso legítimo
URL adulterada:
http://example.com/app/admin_getappInfo
← acesso indevido
A7: Falta de Função para Controle do Nível de Acesso

Como evitar:
– A aplicação deve ter um módulo de autorização
– Consistente e fácil de analisar
– Que seja chamado por todas as suas funções de negócio.
– Deve haver processo para gerenciar os direitos
– De fácil atualização e auditoria
– Deve negar todo o acesso por padrão
– Deve exigir direitos explícitos para papéis específicos no
acesso a todas as funções
A7: Falta de Função para Controle do Nível de Acesso

Tratando o Controle de Acesso com AccessController da
ESAPI
A7: Falta de Função para Controle do Nível de Acesso

O módulo AccessControl depende dos seguintes arquivos e
configuração:
– ESAPI-AccessControlPolicy.xml (políticas de controle de
acesso)
– URLAccessRules.txt (regras de restrição de acesso às
URLs)

URLAccessRules.txt
# Regras de Acesso a URL #
/app/getappInfo | any | allow |
/app/admin_getappInfo | admin | allow |
A8: Cross-Site Request Forgery (CSRF)

Características:
– Um ataque CSRF força o navegador de uma vítima que
tenha uma sessão ativa a enviar uma requisição HTTP
forjada
para
uma
aplicação
Web
vulnerável.
• A requisição é pré-autenticada e inclui o cookie de sessão
e outras informações da sessão, como informação de
autenticação.
– Esta falha permite ao atacante forçar o navegador da vítima
a criar requisições que a aplicação vulnerável aceite como
requisições legítimas oriundos do computador da vítima.
A8: Cross-Site Request Forgery (CSRF)

Cenário de ataque
A8: Cross-Site Request Forgery (CSRF)

Como evitar:
– Usar parâmetro que não pode ser adivinhado pelo atacante
– Formas:
• Token Secreto → mais fácil e mais recomendável
• Requisitar senha nas operações sensíveis
A8: Cross-Site Request Forgery (CSRF)

Como evitar:
– Token secreto.
• São associados à sessão do usuário
• Os tokens (teoricamente) não podem ser adivinhados pelo
atacante
• Duas formas de implementar:
– A aplicação passa o token em hidden fields nas
páginas de resposta e o usuário envia token a cada
requisição
– A aplicação adiciona o token nos parâmetros das
requisições
Ex:
http://example.com/action?param=1&ctoken=8FD4B2
A8: Cross-Site Request Forgery (CSRF)

Tratando CSRF utilizando HTTP Utilities
A8: Cross-Site Request Forgery (CSRF)

Tokens CSRF são atribuídos aos usuários na autenticação
A8: Cross-Site Request Forgery (CSRF)

Como evitar:
– Requisitar Senha
• Os atacantes (teoricamente) não conhecem a senha
• Solicitar a senha em todas as requisições
– Atrapalha a usabilidade
– A aplicação deve requisitar apenas para operações
sensíveis
A9: Utilização de Componentes Vulneráveis Conhecidos

Características:
– Qualquer sistema depende de bibliotecas e subsistemas
– Uma vulnerabilidade presente nestes componentes poderá
afetar negativamente a aplicação ou sistema
A9: Utilização de Componentes Vulneráveis Conhecidos

Cenários de ataque:
– Apache CXF Authentication Bypass – Ao não fornecer um
token de identidade, atacantes podem chamar qualquer
serviço web com todas as permissões.
– Obs.: Apache CXF é um framework de serviços
– Spring Remote Code Execution – Abuso da implementação
de Linguagem Expression no Spring permitiu aos atacantes
executarem código arbitrário, efetivamente comprometendo a
segurança
do
servidor
– Heartbeat - Vulnerabilidade presente no OpenSSL nas
versões 1.0.1 e 1.0.2-beta para os sistemas Linux que
permite roubo de informação protegida pelas criptografias
nos protocolos SSL/TLS.
A9: Utilização de Componentes Vulneráveis Conhecidos

Como evitar:
– Identificar todos os componentes e as versões que você está
utilizando, incluindo todas as dependências.
– Monitorar a segurança desses componentes em banco de
dados públicos, listas de e-mail de projetos e segurança, e
mantê-los atualizados.
– Estabelecer políticas de segurança que definam o uso do
componente, assim como exigir certas práticas de
desenvolvimento de software, passando em testes de
segurança, e licenças aceitáveis.
– Considere a adição de invólucros de segurança em torno dos
componentes para desabilitar funcionalidades não utilizadas
e/ou proteger falhas ou aspectos vulneráveis do componente.
A10: Redirecionamentos e Encaminhamentos Inválidos

Características:
– Ocorre quando as aplicações Web redirecionam e
encaminham usuários para outras páginas e sítios de Web e
usam para isto dados não confiáveis para determinar as
páginas de destino.
– Sem uma validação adequada, os atacantes podem
redirecionar as vítimas para sítios de phishing ou malware,
ou então usar o mecanismo de encaminhamento para
acessar páginas não autorizadas.
A10: Redirecionamentos e Encaminhamentos Inválidos

Cenário de ataque:
– Cenário 1: A aplicação possui uma página chamada
“redirect.jsp” que recebe apenas um parâmetro “url”. O
atacante cria uma URL maliciosa que redireciona os usuários
para o site malicioso, que executa phishing e instala
malware.
http://www.example.com/redirect.jsp?url=www.evil.com
A10: Redirecionamentos e Encaminhamentos Inválidos

Cenário de ataque:
– Cenário 2: A aplicação usa encaminhamentos para rotear
requisições entre partes diferentes do site.
• Para facilitar, algumas páginas usam um parâmetro para
indicar onde o usuário deve ser enviado se a transação for
efetuada com sucesso.
• Neste caso, o atacante cria uma URL que irá passar pela
verificação de controle de acesso e encaminhá-lo para
uma funcionalidade administrativa que o atacante não
teria autorização para acessá-la.
http://www.example.com/page.jsp?fwd=admin.jsp
A10: Redirecionamentos e Encaminhamentos Inválidos

Como evitar:
– Não utilizar parâmetros dos usuários para o cálculo da URL
de destino, ou então utilizar referências indiretas para as
URLs.
– Assegurar que os valores fornecidos são válidos e
autorizados para o usuário.
Considerações Finais

A razão pela qual criamos princípios de segurança no
desenvolvimento é ajudar os desenvolvedores a construírem
aplicações seguras e não apenas para evitar as
vulnerabilidades mais comuns.

Ensinar o desenvolvedor a se prevenir contra uma
determinada vulnerabilidade fará com que ele se previna
dela.
– Ensiná-lo a desenvolver de forma segura fará com que
ele se previna de muitas vulnerabilidades.
Biblioteca de segurança para tratar as principais
vulnerabilidades web

Dúvidas?
Referências



Chris Schmidt, Solving Real World Problems with ESAPI,
FROC 2010
Jeff Williams, Establishing an Enterprise Security API to
Reduce Application Security Costs, Aspect Security
OWASP Top 10
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

OWASP ESAPI
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
Serviço Federal de Processamento de Dados - Serpro
Edifício Sede: SGAN 601 - Módulo V - CEP 70836-900
Fone: (61) 2021-8000 - Brasília DF
www.serpro.gov.br