Escolar Documentos
Profissional Documentos
Cultura Documentos
O conteúdo deste documento está licenciado sobre a licença Creative Commons Attribution ShareAlike 3.0.
Para qualquer reuso ou distribuição deste trabalho, você deve deixar claro os termos da licença deste
trabalho.
http://creativecommons.org/licenses/by-sa/3.0/
Versão 1.0 1
Dezembro 2010
Notas da versão
Esta versão do OWASP Secure Coding Practices foi desenvolvida como parte das atividades do
capítulo Brasil da OWASP em prol da comunidade de desenvolvedores e da segurança dos sistemas
desenvolvidos no Brasil. Este documento é baseado na versão 2.0 de Novembro de 2010. Participaram
desta tradução:
● Leandro Resende Gomes – leandrock@gmail.com
● Sílvio Fernando Correia Vieira Filho – silviofilhosf@gmail.com
● Tarcizio Vieira Neto – tarciziovn@gmail.com
Para saber mais sobre os eventos e atividades desenvolvidas pelo capítulo Brasil, acesse a página
(http://www.owasp.org/index.php/Brazil) ou cadastre-se na lista de discussão OWASP-BR
(http://lists.owasp.org/mailman/listinfo/owasp-brazilian).
Versão 1.0 2
Dezembro 2010
Sumário
Introdução.......................................................................................................................................................4
Princípios Gerais de Segurança em Aplicações e Riscos................................................................................5
Checklist de Prática de Codificação Segura ...................................................................................................7
Validação de Entrada de Dados: ...............................................................................................................7
Codificação da Saída de Dados:................................................................................................................8
Autenticação e Gerenciamento de Senhas:................................................................................................8
Gerenciamento de Sessão:.......................................................................................................................10
Controle de Acessos:................................................................................................................................11
Práticas de Criptografia:..........................................................................................................................12
Tratamento de Erros e Log:.....................................................................................................................12
Proteção de Dados:..................................................................................................................................13
Segurança nas comunicações:..................................................................................................................13
Configuração do Sistema:........................................................................................................................14
Segurança em Base de Dados:.................................................................................................................15
Gerenciamento de Arquivos:...................................................................................................................15
Gerenciamento de Memória:...................................................................................................................16
Práticas Gerais de Codificação:...............................................................................................................16
Apêndice A (Recursos externos e referências)..............................................................................................18
Apêndice B (Glossário)................................................................................................................................19
Versão 1.0 3
Dezembro 2010
Introdução
Este documento não se baseia apenas em questões tecnológicas e tem o propósito de definir um
conjunto de boas práticas de segurança de codificação de aplicações. As recomendações serão apresentadas
em um formato de checklist, que podem ser integradas ao ciclo de desenvolvimento de aplicações. A
adoção destas práticas provavelmente vai reduzir as vulnerabilidades mais comuns em aplicações web.
Geralmente é mais barato construir software seguro do que corrigir problemas de segurança após a
entrega do software como um produto final ou pacote completo de software, sem falar nos custos que
podem estar associados a uma falha de segurança.
Proteger os recursos críticos de aplicações tem se tornado cada vez mais importante, pois o foco
dos atacantes mudou para a camada de aplicação. Um estudo da SANS em 2009[1] descobriu que os
ataques contra aplicações web constituem mais de 60% do total das tentativas de ataque observados na
Internet.
Ao utilizar este guia, é recomendável que as equipes de desenvolvimento avaliem a maturidade do
ciclo de vida de desenvolvimento de software e o nível de conhecimento da sua equipe de desenvolvimento.
Como este guia não entra em detalhes de como implementar cada prática de codificação, os
desenvolvedores precisam possuir um conhecimento prévio ou ter disponível os recursos suficientes que
forneçam o direcionamento necessário. Este guia apresenta práticas de codificação que podem ser
traduzidas em requisitos de codificação sem a necessidade do desenvolvedor possuir uma compreensão
aprofundada das vulnerabilidades e exploits de segurança. No entanto, outros membros da equipe de
desenvolvimento devem possuir responsabilidades, treinamentos adequados, ferramentas e recursos para
validar se o projeto e a implementação atendem os requisitos de segurança.
Um glossário contendo termos importantes usados neste documento, incluindo títulos das seções e
palavras mostradas em itálico, é fornecido no apêndice B.
Não faz parte do escopo deste guia fornecer orientações para implementar um framework de
desenvolvimento seguro de software, no entanto, as seguintes práticas gerais e referências são
recomendadas:
● Definir claramente os papéis e responsabilidades
● Fornecer às equipes de desenvolvimento pessoal com formação adequada em segurança no
desenvolvimento de aplicações
● Implementar um ciclo de desenvolvimento de software seguro
○ OWASP CLASP Project
● Estabelecer padrões de codificação segura
○ OWASP Development Guide Project
● Construir uma biblioteca reutilizável ou fazer uso de uma biblioteca de segurança1
○ OWASP Enterprise Security API (ESAPI) Project
● Verificar a efetividade dos controles de segurança
○ OWASP Application Security Verification Standard (ASVS) Project)
● Estabelecer práticas para garantir a segurança quando há terceirização no desenvolvimento,
incluindo a definição dos requisitos de segurança e metodologias de verificação tanto para as
requisições das propostas, como para o contrato a ser firmado entre as partes.
○ OWASP Legal Project
Versão 1.0 4
Dezembro 2010
Construir software seguro exige ter o conhecimento básico dos princípios de segurança. Uma
revisão abrangente dos princípios de segurança está fora do escopo deste guia, porém os conceitos de
segurança serão abordados de forma superficial e abrangente.
O objetivo da segurança em aplicações é manter a confidencialidade, integridade e disponibilidade
dos recursos de informação a fim de permitir que as operações de negócios sejam bem sucedidas. Esse
objetivo é alcançado através da implementação de controles de segurança. Este guia se concentra nos
controles técnicos específicos para mitigar as ocorrências de vulnerabilidades mais comuns de software.
Como o foco principal são as aplicações web e sua infra-estrutura de apoio, boa parte deste guia pode ser
usado para qualquer plataforma de desenvolvimento de software.
Para proteger o negócio contra os riscos inaceitáveis, isto é, relacionados a dependência e confiança
depositada na aplicação, este guia ajuda a compreender o que podemos entender por risco. Deste modo,
risco é a combinação de fatores que ameaçam o sucesso do negócio. Isto pode ser descrito conceitualmente
da seguinte forma: um agente de ameaça interage com um sistema, no qual pode haver uma
vulnerabilidade latente que pode ser explorada e causar um impacto. Como isto pode parecer um conceito
abstrato, pense do seguinte modo: um ladrão de carros (agente de ameaça) passa por um estacionamento de
carros verificando nos carros presentes (o sistema) procurando por portas destrancadas (a vulnerabilidade) e
quando a encontra, abre a porta (a exploração) e leva para si o que está dentro do carro (o impacto). Todos
esses fatores desempenham um papel no desenvolvimento de software seguro.
Existe uma diferença fundamental entre a abordagem adotada por uma equipe de desenvolvimento
e a abordagem que é adotada por alguém que está interessado em atacar uma aplicação. Uma equipe de
desenvolvimento normalmente desenvolve uma aplicação com base naquilo que ela pretende fazer. Isso
significa criar uma aplicação para executar tarefas específicas baseadas em requisitos funcionais e casos de
uso documentados. Um atacante, por outro lado, está mais interessado no que a aplicação pode ser levada a
fazer e partem do princípio que "qualquer ação não expressamente proibida, é permitida". Para resolver
isso, alguns elementos adicionais precisam ser integrados nas fases iniciais do ciclo de vida do software.
Estes novos elementos são requisitos de segurança e casos de abuso. Este guia foi construído para ajudar a
identificar os requisitos de segurança de alto nível e abordar vários cenários de ataques.
É importante que as equipes de desenvolvimento de aplicações web entendam que os controles do
lado cliente, como validação de entrada de dados no cliente, campos ocultos e controles de interface
(combo box, radio buttons), fornecem pouco ou nenhum benefício de segurança. Neste caso, um atacante
pode usar ferramentas como proxies do lado do cliente, como o OWASP WebScarab, Burp ou ferramentas
de captura de pacotes de rede, como o Wireshark, para analisar o tráfego de aplicativo e enviar requisições
manipuladas, burlando todas as interfaces. Além disso, o Flash, os Applets Java e demais objetos que
trabalham no lado cliente podem ser compilados e analisados em busca de falhas.
As falhas de segurança de software podem ser introduzidas em qualquer fase do ciclo de
desenvolvimento de software, inclusive:
● Não identificar as necessidades de segurança no início.
● Criação de arquiteturas conceituais que possuem erros de lógica.
● Usando práticas ruins de codificação que introduzem vulnerabilidades técnicas.
● Implantação do software de modo inapropriado.
● Inserção de falhas durante a manutenção ou atualização.
Além disso, é importante entender que as vulnerabilidades de software podem ter um escopo muito
além do próprio software. Dependendo da natureza do software, da vulnerabilidade e da infra-estrutura de
apoio, os impactos de uma exploração bem sucedida podem comprometer qualquer ou todos os seguintes
aspectos:
● O software e sua informação associada.
● O sistema operacional dos servidores associados.
Versão 1.0 5
Dezembro 2010
Versão 1.0 6
Dezembro 2010
2 http://pt.wikipedia.org/wiki/Postback
3 http://www.owasp.org/index.php/Double_Encoding
Versão 1.0 7
Dezembro 2010
4 Nota do tradutor: one-way salted hash é um algoritmo de hash gerado com auxílio de valores aleatórios ou pré-
definidos que compõem o parâmetro da função de geração do hash e dificulta o processo de quebra do hash através
de ataques de dicionário. Mais sobre o assunto em: http://en.wikipedia.org/wiki/Salt_(cryptography)
Versão 1.0 8
Dezembro 2010
Versão 1.0 9
Dezembro 2010
código para garantir se o mesmo não é afetado por qualquer código malicioso.
Gerenciamento de Sessão:
□ Utilize controles de gerenciamento de sessão baseados no servidor ou em framework. A aplicação
deve reconhecer apenas os identificadores de sessão como válidos.
□ A criação dos identificadores de sessão devem ser sempre realizados em um sistema confiável, por
exemplo: centralizar todo controle no servidor.
□ Usar algoritmos bem controlados que garantam a aleatoriedade dos identificadores de sessão.
□ Defina o domínio e o caminho para os cookies que contém identificadores de sessão autenticados
para um valor devidamente restrito para o site.
□ A funcionalidade de logout deve encerrar completamente a sessão ou conexão associada.
□ A funcionalidade de logout deve estar disponível em todas as páginas que requerem autenticação.
□ Estabelecer um tempo de expiração da sessão que seja o mais curto possível, baseado no
balanceamento dos riscos e requisitos funcionais do negócio. Na maioria dos casos não deve ser
mais do que algumas horas.
□ Não permitir logins persistentes (sem prazo para expirar sessão) e realizar o encerramento da sessão
periodicamente, mesmo quando a sessão estiver ativa. Especialmente para aplicações que suportam
várias conexões de rede ou que se conectam a sistemas críticos. O tempo de encerramento deve
apoiar os requisitos de negócio, enquanto o usuário deve receber notificação suficientes para
atenuar os impactos negativos destas medidas.
□ Se uma sessão estava estabelecida antes do login, então esta sessão deve ser encerrada para que
uma nova sessão seja estabelecida após o login.
□ Gerar um novo identificador de sessão quando houver alguma nova autenticação.
□ Não permitir conexões simultâneas com o mesmo identificador de usuário.
□ Não expor os identificadores de sessão em URLs, mensagens de erro ou logs. Os identificadores de
sessão devem apenas serem localizados no cabeçalho do cookie HTTP. Por exemplo, não trafegar
os identificadores de sessão na forma de parâmetros GET.
□ Proteger os dados de sessão do lado servidor contra acessos não autorizados, por outros usuários do
servidor, através da implementação de controle de acesso apropriado no servidor.
□ Gerar um novo identificador de sessão e desativar o antigo identificador periodicamente. Isto pode
mitigar certos cenários de ataques de sequestro de sessão (session hijacking), quando o
identificador de sessão original é comprometido.
□ Gerar um novo identificador de sessão caso a segurança da conexão mude de HTTP para HTTPS,
como pode ocorrer durante a autenticação. Internamente à aplicação, é recomendável utilizar
HTTPS de forma constante em vez de alternar entre HTTP para HTTPS.
□ Utilize mecanismos complementares ao mecanismo de gerenciamento de sessão padrão para
operações sensíveis do lado do servidor, como é o caso de operações de gerenciamento de contas,
através da utilização de tokens aleatórios ou parâmetros associados à sessão. Este método pode ser
usado para prevenir-se de ataques do tipo Cross Site Request Forgery.
□ Utilize mecanismos complementares ao gerenciamento de sessão para operações altamente
sensíveis ou críticas utilizando tokens aleatórios ou parâmetros em cada requisição.
□ Utilizar somente identificadores de sessão gerados pelo sistema para gerenciamento de sessão do
lado cliente. Evite usar parâmetros ou outros dados fornecidos pelos clientes para o gerenciamento
do estado.
□ Configurar o atributo "secure" para cookies transmitidos através de uma conexão TLS.
□ Configurar os cookies com o atributo HttpOnly, a menos que seja explicitamente necessário ler ou
definir os valores dos cookies através de scripts do lado cliente da aplicação.
Versão 1.0 10
Dezembro 2010
Controle de Acessos:
□ Utilizar apenas objetos do sistema que sejam confiáveis, como ocorre com os objetos de sessão do
servidor, para realizar a tomada de decisões de autorização de acesso.
□ Utilize um único componente em todo o site para realizar o processo de verificação de autorização
de acesso. Isso inclui bibliotecas que invocam os serviços externos de autorização.
□ Quando ocorrer alguma falha no controle de acesso elas devem ocorrer de modo seguro.
□ Negar todos os acessos caso a aplicação não consiga ter acesso as informações contidas na
configuração de segurança.
□ Garantir o controles de autorização em todas requisições, inclusive em scripts do lado do servidor,
"includes" e requisições provenientes de tecnologias do lado cliente, como AJAX e Flash.
□ Separar os trechos de código que contém a lógica privilegiada da aplicação do restante do código
da aplicação.
□ Restringir o acesso aos arquivos e outros recursos, incluindo aqueles que estão fora do controle
direto da aplicação, somente a usuários autorizados.
□ Restringir o acesso às URLs protegidas somente aos usuários autorizados.
□ Restringir o acesso às funções protegidas somente aos usuários autorizados.
□ Restringir o acesso às referências diretas aos objetos somente aos usuários autorizados.
□ Restringir o acesso aos serviços somente aos usuários autorizados.
□ Restringir o acesso aos dados da aplicação somente aos usuários autorizados.
□ Restringir o acesso aos atributos e dados dos usuários, bem como informações das políticas usadas
pelos mecanismos de controle de acesso.
□ Restringir o acesso às configurações de segurança relevantes apenas para usuários autorizados.
□ As regras de controle de acesso representados pela camada de apresentação devem coincidir com as
regras presentes no lado servidor.
□ Se o estado dos dados devem ser armazenados no lado cliente, utilize mecanismos de criptografia e
verificação de integridade no lado servidor para detectar possíveis adulterações no estado dos
dados.
□ Garantir que os fluxos lógicos da aplicação respeitem as regras de negócio.
□ Limitar o número de transações que um único usuário ou dispositivo podem executar em um
determinado período de tempo. As transações por período de tempo devem estar acima da
necessidade real do negócio, mas abaixo o suficiente para impedir ataques automatizados.
□ Use o campo “referer” do cabeçalho somente como forma de verificação suplementar. Ele não deve
ser usado sozinho como forma de checagem de autorização, pois o valor deste campo pode ser
adulterado.
□ Se é permitido a permanência de sessões autenticadas por longos períodos de tempo, faça
revalidação periódica da autorização do usuário para garantir que seus privilégios não foram
modificados e caso forem, realize o registro em log do usuário e exija nova autenticação.
□ Implementar a auditoria das contas de usuário e assegure a desativação de contas não utilizadas.
Por exemplo: após não mais do que 30 dias após expirar a senha da conta, a mesma deve ser
desativada.
□ A aplicação deve dar suporte a desativação de contas e encerramento das sessões quando encerrar a
autorização do usuário, por exemplo: quando ocorrem alterações de mudança de papéis de usuário,
situação profissional, processos de negócio, etc.
□ As contas de serviço ou contas de suporte a conexões provenientes ou destinadas a serviços
externos devem possuir o menor privilégio possível.
□ Criar uma Política de Controle de Acesso para documentar as regras de negócio da aplicação, tipos
de dados e critérios ou processos de autorização de acesso para que os acessos possam ser
Versão 1.0 11
Dezembro 2010
devidamente concedidos e controlados. Isso inclui identificar requisitos de acessos, tanto para os
dados, como para os recursos do sistema.
Práticas de Criptografia:
□ Todos as funções de criptografia utilizados para proteger dados sensíveis dos usuários da aplicação
devem ser implementados em um sistema confiável (neste caso o servidor).
□ A senha mestre deve ser protegida contra acessos não autorizados.
□ Quando ocorrer alguma falha dos módulos de criptografia, permitir que as falhas ocorram de modo
seguro.
□ Todos os números aleatórios, nomes de arquivos aleatórios, GUIDs aleatórios, e strings aleatórias
devem ser geradas usando um módulo criptográfico com gerador de números aleatórios aprovado
somente se os valores aleatórios gerados forem impossíveis de serem deduzidos.
□ Os módulos de criptografia usados pela aplicação devem ser compatíveis com a FIPS 140-2 ou
padrão equivalente (http://csrc.nist.gov/groups/STM/cmvp/validation.html)
□ Estabelecer e utilizar uma política e processo que define como é realizado o gerenciamento das
chaves de criptografia.
Versão 1.0 12
Dezembro 2010
Proteção de Dados:
□ Implementar política de privilégio mínimo, restringindo os usuários apenas às funcionalidades,
dados e informações do sistema que são necessárias para executar suas tarefas.
□ Proteger todas as cópias temporárias ou registradas em cache que contenham dados sensíveis e
estejam armazenados no servidor contra acesso não autorizado e realizar a remoção destes arquivos
tão logo não sejam mais necessários.
□ Criptografar informações altamente sensíveis quando armazenadas, como dados de verificação de
autenticação, mesmo que estejam no lado servidor. Sempre usar algoritmos bem controlados.
Consulte a seção que trata sobre “Práticas de Criptografia” para orientações adicionais.
□ Proteger o código-fonte presente no servidor para que não sejam baixados por algum usuário.
□ Não armazenar senhas, strings de conexão ou outras informações confidenciais em texto claro ou
em qualquer forma criptograficamente insegura no lado cliente. Isso vale também quando há
incorporação de formatos inseguros como: MS viewstate, Adobe Flash ou código compilado que
roda no lado cliente.
□ Remover comentários do código de produção que são acessíveis pelos usuários e podem revelar
detalhes internos do sistema ou outras informações sensíveis.
□ Remover aplicações desnecessárias e documentação do sistema que possam revelar informações
importantes para os atacantes.
□ Não incluir informações sensíveis nos parâmetros de requisição HTTP GET.
□ Desabilitar a funcionalidade de auto completar nos formulários que contenham informações
sensíveis, inclusive no formulário de autenticação.
□ Desabilitar o cache realizado no lado cliente das páginas que contenham informações sensíveis. O
parâmetro Cache-Control: no-store, pode ser usado em conjunto com o controle definido no
cabeçalhos HTTP “Pragma: no-cache”, que é menos efetivo, mas é compatível com HTTP/1.0.
□ A aplicação deve dar suporte a remoção de dados sensíveis quando os mesmos não forem mais
necessários. Por exemplo: informação pessoal ou determinados dados financeiros.
□ Implementar mecanismos de controle de acesso apropriados para dados sensíveis armazenados no
servidor. Isto inclui dados em cache, arquivos temporários e dados que devem ser acessíveis
somente por usuários específicos do sistema.
Versão 1.0 13
Dezembro 2010
□ Quando ocorre falha nas conexões TLS, o sistema não deve retornar uma conexão insegura.
□ Utilizar conexões TLS para todo conteúdo que requer acesso autenticado ou manutenção da
confidencialidade das informações sensíveis.
□ Utilizar um padrão único de implementação TLS que é configurado de modo apropriado.
□ Especificar a codificação dos caracteres para todas as conexões.
□ Filtrar os parâmetros que contenham informações sensíveis, provenientes do HTTP referer, quando
realizar apontamentos para sites externos.
Configuração do Sistema:
□ Garantir que os servidores, frameworks e componentes do sistema estão executando a última versão
aprovada.
□ Garantir que os servidores, frameworks e componentes do sistema possuam os patches mais
recentes aplicados para a versão em uso.
□ Desabilitar a listagem de diretórios.
□ Restringir os privilégios do servidor web, dos processos e das contas de serviços para o mínimo
possível.
□ Quando exceções ocorrem no sistema, permitir que as falhas ocorram de modo seguro.
□ Remover todas as funcionalidades e arquivos desnecessários.
□ Remover o código de teste ou qualquer funcionalidade desnecessária para o ambiente de produção,
antes que seja realizada a implantação do sistema.
□ Prevenir a divulgação da estrutura de diretórios impedindo que robôs 6 de busca façam indexação de
arquivos sensíveis, através da correta configuração7 do arquivo robots.txt, definindo diretórios que
devem ser inacessíveis a estes indexadores em um diretório subjacente isolado. Assim, o acesso ao
diretório pai definido no arquivo robots.txt deve estar desabilitado em vez de desabilitar cada
diretório individualmente.
□ Definir quais métodos HTTP, Get ou Post, a aplicação irá suportar e se serão tratados de modo
diferenciado nas diversas páginas da aplicação.
□ Desativar os métodos HTTP desnecessários, como extensões WebDAV. Caso for necessário o uso
de algum método HTTP estendido para suportar manipulação de arquivos, então utilize algum
mecanismo de autenticação bem controlado.
□ Se o servidor processa tanto requisições HTTP 1.0 e 1.1, certificar-se de que ambos são
configurados de modo semelhante ou assegurar que qualquer diferença que possa existir sejam
compreendidas (ex. manuseio de métodos HTTP extendidos).
□ Remover informações desnecessárias presentes nos cabeçalhos de resposta HTTP que podem estar
relacionadas ao sistema operacional, versão do servidor web e frameworks de aplicação.
□ O armazenamento da configuração de segurança para a aplicação deve ser capaz de ser produzida
de forma legível para dar suporte à auditoria.
□ Implementar um sistema de gestão de ativos para manter o registro dos componentes e programas
nele.
□ Isolar o ambiente de desenvolvimento da rede de produção e prover acesso somente para grupos de
desenvolvimento e testes. Os ambientes de desenvolvimento comumente são configurados de modo
menos seguro do que os ambientes de produção. Assim, os atacantes podem usar esse diferencial
para descobrir vulnerabilidades compartilhadas ou encontrar caminhos para explorar as
vulnerabilidades.
6 Robôs são programas de computador que percorrem automaticamente as páginas da Internet em busca de
documentos, a fim de indexá-los, validá-los ou monitorar alterações de conteúdo.
http://pt.wikipedia.org/wiki/Robots.txt
7 http://www.mundoseo.com.br/seo-tecnico/robotstxt-configuracao-seu-site/
Versão 1.0 14
Dezembro 2010
Gerenciamento de Arquivos:
□ Não repassar dados fornecidos pelos usuários diretamente a uma função de inclusão dinâmica.
□ Solicitar autenticação antes de permitir que seja feito o upload de um arquivo.
□ Limitar os tipos de arquivos que podem ser enviados para aceitar somente os tipos que são
necessários para os propósitos do negócio.
□ Validar se os arquivos enviados são do tipo esperado através da checagem dos cabeçalhos. Realizar
a verificação de tipo de arquivo apenas pela extensão não é suficiente.
□ Não salvar arquivos no mesmo diretório de contexto da aplicação web. Os arquivos devem ser
armazenados no servidor de conteúdos ou na base de dados.
□ Prevenir ou restringir upload de qualquer arquivo que possa ser interpretado pelo servidor web.
□ Desabilitar privilégios de execução nos diretórios de upload de arquivos.
□ Implementar o upload seguro nos ambientes UNIX por meio da montagem do diretório de destino
como um unidade lógica, usando o caminho associado ou o ambiente de chroot.
□ No referenciamento de arquivos existentes, use uma lista branca (white list) de nomes e tipos de
arquivos permitidos. Realize a validação do valor do parâmetro passado e caso não corresponda ao
8 http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Versão 1.0 15
Dezembro 2010
que é esperado, rejeite a entrada ou utilize um valor de arquivo especificado por padrão pela
aplicação.
□ Não transmitir sem nenhum tratamento os dados informados pelo usuário a redirecionamentos
dinâmicos. Se isto deve ser permitido, então o redirecionamento deve aceitar somente URLs
relativas e validadas.
□ Não passar parâmetros de caminhos de diretórios ou arquivos nas requisições. Utilize algum
mecanismo de mapeamento dos caminhos em disco para índices que são repassados para os
usuários e servem para serem mapeados em uma lista pré-definida de caminhos dos arquivos.
□ Nunca enviar o caminho absoluto do arquivo para o cliente.
□ Certificar-se de que os arquivos da aplicação e os recursos são do tipo somente leitura.
□ Escanear arquivos que os usuários submeteram por mecanismo de upload em busca de vírus e
malwares.
Gerenciamento de Memória:
□ Utilize controle de entrada/saída para dados não confiáveis.
□ Verificar se o buffer é tão grande quanto o especificado.
□ Ao usar funções que aceitam um determinado número de bytes para realizar cópias, como
strncpy(), esteja ciente de que se o tamanho do buffer de destino for igual ao tamanho do buffer de
origem, ele não pode encerrar a seqüência de caracteres com valor nulo (null).
□ Verificar os limites do buffer caso as chamadas a função são realizadas em um loop e verificar se
não há nenhum perigo de escrever além do espaço alocado.
□ Truncar todas as strings de entrada para um tamanho razoável antes de passá-las para as funções de
cópia e concatenação.
□ Encerre os recursos de modo específico, sem contar com o garbage collector na liberação dos
recursos alocados para objetos de conexão, identificadores de arquivo, etc.
□ Usar pilhas não-executáveis, quando disponíveis.
□ Evitar o uso de funções reconhecidas por serem vulneráveis, por exemplo: printf, strcat, strcpy, etc.
□ Liberar a memória alocada de modo apropriado após concluir a sub-rotina (função/método) e em
todos pontos de saída.
Versão 1.0 16
Dezembro 2010
Versão 1.0 17
Dezembro 2010
Referências Externas:
1. Referência citada
Sans and TippingPoint "The Top Cyber Security Risks"
http://www.sans.org/top-cyber-security-risks/
Versão 1.0 18
Dezembro 2010
Apêndice B (Glossário)
Agente de Ameaça: Qualquer entidade que pode ter um impacto negativo sobre o sistema. Este pode ser
tanto um usuário mal-intencionado que quer comprometer os controles de segurança do sistema, como um
desvio acidental do sistema ou uma ameaça física como incêndios ou inundações.
Autenticação: É um conjunto de controles que são usados para verificar a identidade de um usuário, ou
outra entidade, que interage com o software.
Autenticação Seqüencial: Ocorre quando os dados de autenticação são solicitados em sucessivas páginas,
em vez de serem solicitados em uma única página.
Autenticação de múltiplos fatores: É um processo de autenticação que requer vários tipos de credenciais
produzidas pelo usuário. Normalmente é baseado em algo que eles possuem (ex.: cartão inteligente), algo
que eles sabem (uma ex.: senha), ou algo que eles são (ex.: dados provenientes de um leitor biométrico).
Canonicalização: É uma operação realizada para reduzir várias codificações e representações de dados em
uma única forma simplificada.
Caracteres Maliciosos: São caracteres ou representação codificada de um caractere que podem produzir
efeitos indesejáveis sobre a operação normal da aplicação ou dos sistemas associados quando são
interpretados, por terem significado especial. Estes caracteres podem ser usados para:
● Modificar a estrutura de código existente
● Inserir novo código não intencional
● Modificar caminhos
● Causar saídas inesperadas das funções ou rotinas
● Causar condições de erro
● Ter qualquer dos efeitos anteriores nas aplicações subjacentes
Casos de Abuso: Descreve o mau uso intencional (ou não) do software. Os casos de abuso desafiam os
pressupostos do projeto do sistema.
Codificação de saída baseada em contexto: Ocorre quando a codificação de dados de saída é realizada
com base em como ela será utilizada pela aplicação. Os métodos específicos variam dependendo da forma
como os dados são usados. Se os dados de saída estiverem incluídos na resposta ao cliente, é levado em
conta como cenários de inclusão, situações como: o corpo de um documento HTML, um atributo de
HTML, codificação JavaScript, codificação CSS ou em uma URL. Deve também ser levado em conta
outros casos como consultas SQL, XML e LDAP.
Versão 1.0 19
Dezembro 2010
Codificação de saída de dados: É um conjunto de controles que abordam o uso de codificação para
garantir que a saída de dados gerada pela aplicação seja segura.
Confidencialidade: Para garantir que as informações sejam divulgadas apenas para as partes autorizadas.
Controle de Acesso: É um conjunto de controles que libera ou nega o acesso a um recurso do sistema a um
usuário, ou qualquer outra entidade. Normalmente é baseado em regras hierárquicas e privilégios
individuais associados a papéis, porém também inclui interações entre sistemas.
Controles de Segurança: Uma ação que elimina uma vulnerabilidade potencial e ajuda a garantir que o
software se comporte conforme o esperado.
Cross Site Request Forgery (CSRF): Uma aplicação ou site web externos forçam o navegador do cliente
a realizar uma requisição involuntária para um aplicativo que o cliente possua uma sessão ativa. As
aplicações são vulneráveis quando usam URLs e parâmetros conhecidas ou previsíveis, ou quando o
navegador automaticamente transmite todas informações solicitadas pela sessão em cada solicitação para a
aplicação vulnerável. Isto é apenas um dos ataques discutidos de modo especifico neste documento e só
está incluído porque a vulnerabilidade associada é muito comum e mal compreendida.
Disponibilidade: Propriedade de estar acessível e utilizável quando demandado por uma entidade
autorizada.
Estado dos Dados: Ocorre quando os dados ou parâmetros são usados, através da aplicação ou servidor,
para emular uma conexão persistente ou controlar o status de um cliente através de um processo de
múltiplas requisições ou transações.
Exploit: É uma ação que tira proveito de uma vulnerabilidade. Normalmente é uma ação intencional
destinada a comprometer os controles de segurança do software, aproveitando a existência de uma
vulnerabilidade.
Gerência de Arquivo: É um conjunto de controles que abrangem a interação entre o código da aplicação e
os arquivos do sistema.
Gerenciamento de Sessão: É um conjunto de controles que ajudam a garantir que as aplicações web lidem
com sessões http de um modo seguro.
Versão 1.0 20
Dezembro 2010
Impacto: É o perceptível efeito negativo para o negócio, resultante da ocorrência de um evento indesejável,
que por sua vez é o resultado de uma, ou mais, vulnerabilidade(s) explorada(s).
Integridade: É a garantia de que as informações são precisas, completas e válidas, e que não foram
alteradas por uma ação não autorizada.
Limites de Confiança: Normalmente um limite de confiança constitui nos componentes do sistema sob seu
controle direto. Todas as conexões e dados do sistema fora de seu controle direto, incluindo todos os
clientes e sistemas gerenciados por terceiros, devem ser considerados como não-confiáveis e que
necessitam ser validados na fronteira, antes de permitir uma maior interação com o sistema.
Mitigar: São medidas tomadas para reduzir o impacto de uma vulnerabilidade. Estas medidas incluem a
remoção de uma vulnerabilidade, seja ao tornar uma vulnerabilidade mais difícil de ser explorada, ou ao
reduzir o impacto negativo de uma exploração bem sucedida.
Práticas de Codificação Geral: É um conjunto de controles que abrangem práticas de codificação que não
se encaixam facilmente em outras categorias.
Proteção dos Dados: É um conjunto de controles que ajuda a garantir que o software trata o
armazenamento das informações de modo seguro.
Realizar log dos eventos: Esta operação deve incluir os seguintes requisitos:
1. Utilizar o timestamp proveniente de um sistema confiável
2. Classificar a severidade para cada evento
3. Marcar eventos de segurança relevantes, caso forem misturados com outros registros de log
4. Registrar o identificador da conta ou usuário que causou o evento
5. Registrar o IP de origem que realizou a requisição
6. Registrar o resultado dos eventos (sucesso ou falha)
7. Registrar a descrição do evento
Requisitos de segurança: É um conjunto de requisitos funcionais e de projeto que ajudam a garantir que o
software seja construído e implantado de forma segura.
Segurança das Comunicações: É um conjunto de controles que ajudam a garantir o envio e o recebimento
das informações de modo seguro.
Segurança de Banco de Dados: É um conjunto de controles que garantem que o software interage com o
banco de dados de forma segura e garantem também que o banco de dados esteja configurado de forma
segura.
Sistema: É um termo genérico que abrange os sistemas operacionais, servidores web, frameworks de
aplicativos e infraestrutura relacionada.
Versão 1.0 21
Dezembro 2010
Tratamento de erros e log: É um conjunto de práticas que garantem que a aplicação realiza o tratamento
dos erros de modo seguro, como também realiza de modo apropriado o registro de log dos eventos.
Tratamento dos Dados: É o processo de tornar seguros os dados potencialmente prejudiciais através do
processo de remoção, substituição, codificação ou escaping dos caracteres.
Versão 1.0 22