Fevereiro 2012

Melhores Prticas de Codificao Segura OWASP Guia de Referncia Rpida

OWASP Secure Coding Practices Quick Reference Guide

Copyright and License

Copyright 2010 The OWASP Foundation. O contedo deste documento distribudo sob a licena Creative Commons Attribution ShareAlike 3.0. Para a utilizao ou redistribuio, deve deixar claro os termos da licena deste trabalho. http://creativecommons.org/licenses/by-sa/3.0/

Verso 1.3

Fevereiro 2012

Notas da verso
Essa verso do OWASP Secure Coding Practices foi desenvolvida como parte integrante da atividade conjunta dos captulos brasileiro e portugus da OWASP, em prol da comunidade de programadores e da segurana dos sistemas desenvolvidos nos pases de lngua portuguesa. Este documento baseado na verso 2.0 de Novembro de 2010 e na reviso da primeira traduo, a verso 1.2, datada de Julho de 2011. Lder do projeto de traduo: Tarcizio Vieira Neto tarcizio.vieira@owasp.org Brasil Participaram desta traduo: Leandro Resende Gomes leandrock@gmail.com Brasil Slvio Fernando Correia Vieira Filho silviofilhosf@gmail.com Brasil Paulo Alexandre Silva me@pauloasilva.com Portugal Alexandre Pupo alexandrepupo@yahoo.com.br Brasil Carlos Serro carlos.serrao@owasp.org Portugal Rogrio Vicente rogeriopvl@gmail.com Portugal Jorge Olimpia jorgeolimpia@gmail.com Brasil A traduo deste documento pretende ser fiel ao texto original, tendo sido introduzidos alguns detalhes explicativos que esto dispersos no texto, em alguns casos, na forma de notas de rodap contendo o prefixo NT: (nota de traduo). Para saber mais sobre os eventos e atividades desenvolvidas pelo captulo Brasil, acesse a pgina (http://www.owasp.org/index.php/Brazil) ou registre-se na lista de discusso OWASP-BR (http://lists.owasp.org/mailman/listinfo/owasp-brazilian). Para saber mais sobre os eventos e atividades desenvolvidas pela delegao da OWASP em Portugal, acesse a pgina (http://www.owasp.org/index.php/Portuguese) ou registre-se na lista de discusso OWASPPT (https://lists.owasp.org/mailman/listinfo/owasp-portuguese).

Verso 1.3

Fevereiro 2012

Sumrio
Introduo.............................................................................................................................................4 Princpios Gerais de Segurana em Aplicaes e Riscos.....................................................................5 Lista de Verificao de Prticas de Programao Segura.....................................................................6 Validao dos Dados de Entrada:.....................................................................................................6 Codificao de Dados de Sada:.......................................................................................................7 Autenticao e Gerenciamento de Credenciais:...............................................................................7 Gerenciamento de Sesses:..............................................................................................................9 Controle de Acessos:......................................................................................................................10 Prticas de Criptografia:.................................................................................................................11 Tratamento de Erros e Log:............................................................................................................11 Proteo de Dados:.........................................................................................................................12 Segurana nas comunicaes:........................................................................................................13 Configurao do Sistema:...............................................................................................................13 Segurana em Banco de Dados:.....................................................................................................14 Gerenciamento de Arquivos:..........................................................................................................14 Gerenciamento de Memria:..........................................................................................................15 Prticas Gerais de Codificao:......................................................................................................16 Apndice A (Recursos externos e referncias)...................................................................................17 Referncias Externas:.....................................................................................................................17 Sites de Avisos de Segurana:........................................................................................................17 Apndice B (Glossrio)......................................................................................................................18

Verso 1.3

Fevereiro 2012

Introduo
Este documento no se baseia apenas em questes tecnolgicas e tem o propsito de definir um conjunto de boas prticas de segurana no desenvolvimento de aplicaes. As recomendaes sero apresentadas no formato de lista de verificaes, que podem ser integradas ao ciclo de desenvolvimento das aplicaes. A adoo destas prticas provavelmente reduzir as vulnerabilidades mais comuns em aplicaes Web. Geralmente, mais barato construir software seguro do que corrigir problemas de segurana aps a entrega do mesmo como um produto final ou pacote completo, sem falar nos custos que podem estar associados a uma falha de segurana. Proteger os recursos crticos das aplicaes tem se tornado cada vez mais importante, pois o foco dos atacantes mudou para a camada de aplicao. Um estudo da SANS em 2009 [1] descobriu que os ataques contra aplicaes Web constituem mais de 60% das tentativas de ataque observados na Internet. Ao utilizar este guia recomendvel que equipes de desenvolvimento avaliem a maturidade do ciclo de vida de desenvolvimento de software e o nvel de conhecimento da equipe. Como este guia no entra em detalhes de como implantar cada prtica de programao, os programadores precisam possuir conhecimento prvio ou devem ter disponveis os recursos que forneam o conhecimento necessrio. Este guia apresenta prticas que podem ser traduzidas em requisitos de desenvolvimento sem a necessidade do programador possuir uma compreenso aprofundada das vulnerabilidades e exploits de segurana. No entanto, outros membros da equipe de desenvolvimento devem possuir responsabilidades, competncias adequadas, ferramentas e recursos para validar se o projeto e a implementao atendem os requisitos de segurana. No apndice B encontra-se um glossrio dos termos importantes usados neste documento, incluindo o ttulo das seces e palavras mostradas em itlico. No faz parte do escopo deste guia fornecer orientaes para implantar um framework de desenvolvimento seguro de software, mas as seguintes prticas gerais e referncias so recomendadas: Definir claramente os papis e responsabilidades Fornecer s equipes de desenvolvimento pessoal com formao adequada em segurana no desenvolvimento de aplicaes Implementar um ciclo de desenvolvimento de software seguro o o o o OWASP CLASP Project OWASP Development Guide Project OWASP Enterprise Security API (ESAPI) Project OWASP Application Security Verification Standard (ASVS) Project Estabelecer padres de programao segura Construir uma biblioteca reutilizvel ou fazer uso de uma biblioteca de segurana1 Verificar a efetividade dos controles de segurana Estabelecer prticas para garantir a segurana quando h terceirizao no desenvolvimento, incluindo a definio dos requisitos de segurana e metodologias de verificao tanto para os requisitos das propostas, como para o contrato a ser firmado entre as partes o OWASP Legal Project

NT: Complemento adicionado pelo tradutor.

Verso 1.3

Fevereiro 2012

Princpios Gerais de Segurana em Aplicaes e Riscos

Construir software seguro exige o conhecimento bsico dos princpios de segurana. Uma reviso abrangente dos princpios de segurana est fora do escopo desse guia, porm os conceitos de segurana sero abordados de forma superficial, mas abrangente. O objetivo da segurana em aplicaes manter a confidencialidade, integridade e disponibilidade dos recursos de informao a fim de permitir que as operaes de negcios sejam bem sucedidas e esse objetivo alcanado atravs da implementao de controles de segurana. Este guia concentra-se nos controles tcnicos, especficos para mitigar as ocorrncias das vulnerabilidades mais comuns no software e como o foco principal so as aplicaes Web e a infraestrutura de apoio, boa parte desse documento pode ser usada para qualquer plataforma de desenvolvimento de software. Para proteger o negcio contra os riscos inaceitveis, isto , relacionados com a dependncia e com a confiana depositada na aplicao, este guia ajuda a compreender o que podemos entender por risco. Deste modo, risco a combinao de fatores que ameaam o sucesso do negcio. Isto pode ser descrito conceitualmente da seguinte forma: um agente de ameaa interage com um sistema, no qual pode haver uma vulnerabilidade latente que quando explorada causa um impacto. Como isto pode parecer um conceito abstrato, pense do seguinte modo: um ladro de carros (agente de ameaa) passa por um estacionamento verificando nos carros presentes (o sistema) a existncia de portas destrancadas (a vulnerabilidade) e quando a encontra, abre a porta (a explorao) 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 diferena fundamental entre a abordagem adotada por uma equipe de desenvolvimento e a abordagem que adotada por algum que est interessado em atacar uma aplicao. Uma equipe de desenvolvimento normalmente desenvolve uma aplicao com base naquilo que ela pretende fazer e isso significa criar uma aplicao para executar tarefas especficas, baseadas em requisitos funcionais e casos de uso documentados. Um atacante, por outro lado, est mais interessado no que a aplicao pode ser levada a fazer e parte do princpio que "qualquer ao no expressamente proibida, permitida". Para resolver isso, alguns elementos adicionais precisam ser integrados nas fases iniciais do ciclo de vida do software e esses novos elementos so requisitos de segurana e casos de abuso. Este guia foi construdo para ajudar a identificar os requisitos de segurana de alto nvel e abordar vrios cenrios de ataques. importante que as equipes de desenvolvimento de aplicaes Web entendam que os mecanismos de controle do lado cliente, como validao de dados de entrada no cliente, campos ocultos e controles de interface (combo box, radio buttons), fornecem pouco ou nenhum benefcio de segurana. Nesse caso, um atacante pode usar ferramentas como proxies do lado cliente, como o OWASP WebScarab, Burp ou ferramentas de captura de pacotes de rede, como o Wireshark, para analisar o trfego da aplicao e enviar requisies manipuladas, burlando todas as interfaces. Alm disso, o Flash, os Applets Java e demais objetos que trabalham no lado cliente podem ser alvo de engenharia reversa e analisados em busca de falhas. As falhas de segurana de software podem ser introduzidas em qualquer fase do ciclo de desenvolvimento, inclusive: No incio, ao no identificar as necessidades de segurana Na criao de arquiteturas conceituais que possuam erros de lgica No uso de ms prticas de programao que introduzam vulnerabilidades tcnicas Na implementao do software de modo inapropriado Na insero de falhas durante a manuteno ou a atualizao

Alm disso, importante entender que as vulnerabilidades de software podem ter um escopo muito maior do que o do prprio software. Dependendo da natureza do software, da vulnerabilidade e da infraestrutura de apoio, o impacto de uma explorao bem sucedida pode comprometer qualquer um, ou mesmo todos os seguintes aspectos: O software e sua informao associada O sistema operacional dos servidores associados A base de dados do backend

Verso 1.3

Fevereiro 2012

Outras aplicaes em um ambiente compartilhado O sistema do usurio Outros softwares com os quais o usurio interage

Lista de Verificao de Prticas de Programao Segura

Validao dos Dados de Entrada:

Efetuar toda a validao dos dados em um sistema confivel. Por exemplo, centralizar todo o processo no servidor Identificar todas as fontes de dados e classific-las como sendo confiveis ou no. Em seguida, validar os dados provenientes de fontes nas quais no se possa confiar (ex: base de dados, stream de arquivos etc.) A rotina de validao de dados de entrada deve ser centralizada na aplicao Especificar o conjunto de caracteres apropriado, como UTF-8, para todas as fontes de entrada de dados Codificar os dados para um conjunto de caracteres comuns antes da validao (Canonicalize) Quando h falha de validao, a aplicao deve rejeitar os dados fornecidos Determinar se o sistema suporta conjuntos de caracteres estendidos UTF-8 e, em caso afirmativo, validar aps efetuar a descodificao UTF-8 Validar todos os dados provenientes dos clientes antes do processamento, incluindo todos os parmetros, campos de formulrio, contedos das URLs e cabealhos HTTP, como, por exemplo, os nomes e os valores dos Cookies. Certificar-se, tambm, de incluir mecanismos automticos de postback2 nos blocos de cdigo JavaScript, Flash ou qualquer outro cdigo embutido Verificar se os valores de cabealho, tanto das requisies, como das respostas, contm apenas caracteres ASCII Validar dados provenientes de redirecionamentos. Os atacantes podem incluir contedo malicioso diretamente para o alvo do mecanismo de redirecionamento, podendo assim contornar a lgica da aplicao e qualquer validao executada antes do redirecionamento Validar tipos de dados esperados Validar intervalo de dados Validar o tamanho dos dados Validar, sempre que possvel, todos os dados de entrada atravs de um mtodo baseado em listas brancas" que utilizem uma lista de caracteres ou expresses regulares para definirem os caracteres permitidos Se qualquer caractere potencialmente perigoso precisa ser permitido na entrada de dados da aplicao, certificar-se de que foram implementados controles adicionais como codificao dos dados de sada, APIs especificas que fornecem tarefas seguras e trilhas de auditoria no uso dos dados pela aplicao. A seguir, como exemplo de caracteres potencialmente perigosos, temos: <, >, ", ', %, (, ), &, +, \, \', \" Se a rotina de validao padro no abordar as seguintes entradas, ento elas devem ser verificadas: a) Verificar bytes nulos (%00) b) Verificar se h caracteres de nova linha (%0d, %0a, \r, \n) c) Verificar se h caracteres ponto-ponto barra (../ ou ..\) que alteram caminhos. Nos casos

NT: http://pt.wikipedia.org/wiki/Postback

Verso 1.3

Fevereiro 2012

de conjunto de caracteres que usem a extenso UTF-8, o sistema deve utilizar representaes alternativas como: %c0%ae%c0%ae/. A canonicalizao deve ser utilizada para resolver problemas de codificao dupla (double encoding3) ou outras formas de ataques por ofuscao

Codificao de Dados de Sada:

Efetuar toda a codificao dos dados em um sistema confivel, por exemplo, centralizar todo o processo no servidor Utilizar uma rotina padro, testada, para cada tipo de codificao de sada Realizar a codificao, baseada em contexto, de todos os dados enviados para o cliente que tm origem em um ambiente fora dos limites de confiana da aplicao. A codificao das entidades HTML um exemplo, mas nem sempre funciona para todos os casos Codificar todos os caracteres, a menos que sejam conhecidos por serem seguros para o interpretador de destino Realizar o tratamento (sanitizao), baseado em contexto, de todos os dados provenientes de fontes no confiveis usados para construir consultas SQL, XML, e LDAP Tratar todos os dados provenientes de fontes que no sejam confiveis que gerem comandos para o sistema operacional

Autenticao e Gerenciamento de Credenciais:

Requerer autenticao para todas as pginas e recursos, exceto para aqueles que so intencionalmente pblicos Os controles de autenticao devem ser executados em um sistema confivel, por exemplo, centralizar todo o processo no servidor Sempre que possvel, estabelecer e utilizar servios de autenticao padronizados e testados Utilizar uma implementao centralizada para realizar os procedimentos de autenticao, disponibilizando bibliotecas que invoquem os servios externos de autenticao Separar a lgica de autenticao do recurso que est a ser requisitado e usar redirecionadores dos controladores de autenticao centralizados Quando ocorrerem situaes excepcionais nos controles de autenticao, executar procedimentos em caso de falha com o propsito de manter o sistema seguro Todas as funes administrativas e de gerenciamento de contas devem ser to seguras quanto o mecanismo de autenticao principal Se a aplicao gerenciar um repositrio de credenciais, esta dever garantir que as senhas so armazenadas na base de dados somente sob a forma de resumo/hash da senha na forma de one-way salted hashes4 e que a tabela/arquivo que armazena as senhas e as prprias chaves so manipuladas apenas pela aplicao. No utilizar o algoritmo de hash MD5, sempre que esse puder ser evitado A gerao dos resumos (hash) das senhas deve ser executada em um sistema confivel, por exemplo, centralizar o controle no servidor Validar os dados de autenticao somente no final de todas as entradas de dados, especialmente para as implementaes de autenticao sequencial As mensagens de falha na autenticao no devem indicar qual parte dos dados de autenticao est

3 4

NT: http://www.owasp.org/index.php/Double_Encoding NT: one-way salted hash um algoritmo de hash gerado com o auxlio de valores aleatrios ou pr-definidos que compem o parmetro da funo de gerao da hash e dificulta o processo de quebra da hash atravs de ataques de dicionrio. Mais informaes sobre o assunto em: http://en.wikipedia.org/wiki/Salt_(cryptography)

Verso 1.3

Fevereiro 2012

incorreta. Por exemplo, em vez de exibir mensagens como Nome de usurio incorreto ou Senha incorreta, utilize apenas mensagens como: Usurio e/ou senha invlidos, para ambos os casos de erro. As respostas de erro devem ser idnticas nos dois casos

Utilizar autenticao para conexo a sistemas externos que envolvam trfego de informao sensvel ou acesso a funes As credenciais de autenticao para acessar servios externos aplicao devem ser cifradas e armazenadas em um local protegido de um sistema confivel, por exemplo, no servidor da aplicao. Obs.: o cdigo-fonte no considerado um local seguro Utilizar apenas requisies POST para transmitir credenciais de autenticao Somente trafegar senhas (no temporrias) atravs de uma conexo protegida (SSL/TLS) ou no formato de dado cifrado, como no caso de envio de e-mail cifrado. Senhas temporrias enviadas por e-mail podem ser um caso de exceo aceitvel Exigir que os requisitos de complexidade de senha estabelecidos pela poltica ou regulamento sejam cumpridos. As credenciais de autenticao devem resistir a ataques que, tipicamente, ameaam o ambiente de produo. Um exemplo pode ser a exigncia do uso simultneo de caracteres alfabticos, numrico e/ou caracteres especiais Exigir que os requisitos de comprimento de senha estabelecidos pela poltica ou regulamento sejam cumpridos. O uso de oito caracteres o mais comum, porm usar 16 mais recomendado. Considere, ainda, o uso de senhas que contenham vrias palavras (uma frase) A entrada da senha deve ser ocultada na tela do usurio. Em HTML, utilizar o campo do tipo "password" Desativar a conta aps um nmero pr-definido de tentativas invlidas de autenticao (ex: cinco tentativas o mais comum). A conta deve ser desativada por um perodo de tempo suficientemente longo para desencorajar a deduo das credenciais pelo mtodo de fora bruta, mas no to longo ao ponto de permitir um ataque de negao de servio Os processos de redefinio de senhas e operaes de mudanas devem exigir os mesmos nveis de controle previstos para a criao de contas e autenticao Esquemas de pergunta/resposta (pr-definidas) usadas para a redefinio da senha devem evitar ataques que lancem respostas aleatrias. Por exemplo, livro favorito uma questo fraca, pois A Bblia uma resposta muito comum Se optar por usar redefinio de senha baseada em e-mail, envie um e-mail somente para o endereo pr-definido contendo um link ou senha de acesso temporrio que permitam ao usurio redefinir a senha O tempo de validade das senhas e dos links temporrios deve ser curto Exigir a mudana de senhas temporrias na prxima vez que o usurio realizar a autenticao no sistema Notificar o usurio quando a senha for reiniciada (reset) Prevenir a reutilizao de senhas As senhas devem ter, pelo menos, um dia de durao antes de poderem ser alteradas, a fim de evitar ataques de reutilizao de senhas Garantir que a troca de senhas est em conformidade com os requisitos estabelecidos na poltica ou regulamento. Sistemas crticos podem exigir alteraes mais frequentes nas credenciais de segurana. O tempo entre as trocas de senhas deve ser controlado administrativamente Desativar a funcionalidade de lembrar a senha nos campos de senha do navegador A data/hora da ltima utilizao (bem ou mal sucedida) de uma conta de usurio deve ser comunicada no prximo acesso ao sistema Realizar monitoramento para identificar ataques contra vrias contas de usurios, utilizando a mesma senha. Esse padro de ataque utilizado para explorar o uso de senhas padro

Verso 1.3

Fevereiro 2012

Modificar todas as senhas que, por padro, so definidas pelos fornecedores, bem como os identificadores de usurios (IDs) ou desativar as contas associadas Exigir nova autenticao dos usurios antes da realizao de operaes crticas Utilizar autenticao de mltiplos fatores (utilizando simultaneamente token, senha, biometria etc.5) para contas altamente sensveis ou de alto valor transacional Caso utilize cdigo de terceiros para realizar a autenticao, inspecione-o cuidadosamente para garantir que o mesmo no afetado por qualquer cdigo malicioso

Gerenciamento de Sesses:

Utilizar controles de gerenciamento de sesso baseados no servidor ou em framework. A aplicao deve reconhecer apenas esses identificadores de sesso como vlidos A criao dos identificadores de sesso deve ser sempre realizada em um sistema confivel, por exemplo, centralizado no servidor O controle de gesto de sesso deve usar algoritmos conhecidos, padronizados e bem testados que garantam a aleatoriedade dos identificadores de sesso Definir o domnio e o caminho para os cookies que contenham identificadores de sesso autenticados, para um valor devidamente restrito ao site A funcionalidade de sada (logout) deve encerrar completamente a sesso ou conexo associada A funcionalidade de sada (logout) deve estar disponvel em todas as pginas que requerem autenticao Estabelecer um tempo de expirao da sesso que seja o mais curto possvel, baseado no balanceamento dos riscos e requisitos funcionais do negcio. Na maioria dos casos no deve ser maior do que algumas horas No permitir logins persistentes (sem prazo de expirao) e realizar o encerramento da sesso periodicamente, mesmo quando ela estiver ativa. Isso deve ser feito, especialmente, em aplicaes que suportam vrias conexes de rede ou que se conectam a sistemas crticos. O tempo de encerramento deve estar de acordo com os requisitos do negcio e o usurio deve receber notificaes suficientes para atenuar os impactos negativos dessa medida Se uma sesso estava estabelecida antes do login ela deve ser encerrada para que uma nova seja estabelecida aps o login Gerar um novo identificador de sesso quando houver uma nova autenticao No permitir conexes simultneas com o mesmo identificador de usurio No expor os identificadores de sesso em URLs, mensagens de erro ou logs. Os identificadores de sesso devem apenas ser encontrados no cabealho do cookie HTTP. Por exemplo, no trafegar os identificadores de sesso sob a forma de parmetros GET Proteger os dados de sesso do lado servidor contra acessos no autorizados por outros usurios do servidor, atravs da implementao de controles de acesso apropriados no servidor Gerar um novo identificador de sesso e desativar o antigo periodicamente. Isso pode mitigar certos cenrios de ataques de sequestro de sesso (session hijacking), quando o identificador de sesso original for comprometido Gerar um novo identificador de sesso caso a segurana da conexo mude de HTTP para HTTPS, como pode ocorrer durante a autenticao. Internamente aplicao, recomendvel utilizar HTTPS de forma constante em vez de alternar entre HTTP e HTTPS Utilizar mecanismos complementares ao mecanismo padro de gerenciamento de sesses para operaes sensveis do lado servidor como no caso de operaes de gerenciamento de contas

NT: Complementao explicativa fornecida pelo tradutor.

Verso 1.3

Fevereiro 2012

atravs da utilizao de tokens aleatrios ou parmetros associados sesso. Esse mtodo pode ser usado para prevenir ataques do tipo Cross Site Request Forgery (CSRF)

Utilizar mecanismos complementares ao gerenciamento de sesses para operaes altamente sensveis ou crticas, utilizando tokens aleatrios ou parmetros em cada requisio em vez de basear-se apenas na sesso Configurar o atributo "secure" para cookies transmitidos atravs de uma conexo TLS Configurar os cookies com o atributo HttpOnly, a menos que seja explicitamente necessrio ler ou definir os valores dos mesmos atravs de scripts do lado cliente da aplicao

Controle de Acessos:

Utilizar apenas objetos do sistema que sejam confiveis, como ocorre com os objetos de sesso do servidor, para realizar a tomada de deciso sobre a autorizao de acesso Utilizar um nico componente em toda a aplicao Web para realizar o processo de verificao de autorizao de acesso. Isto inclui bibliotecas que invocam os servios externos de autorizao Quando ocorrer alguma falha no controle de acesso, ela deve ocorrer de modo seguro Negar todos os acessos, caso a aplicao no consiga ter acesso s informaes contidas na configurao de segurana Garantir o controle de autorizao em todas as requisies, inclusive em scripts do lado servidor, "includes" e requisies provenientes de tecnologias do lado cliente, como AJAX e Flash Isolar do cdigo da aplicao os trechos de cdigo que contm lgica priviligiada Restringir o acesso aos arquivos e outros recursos, incluindo aqueles que esto fora do controle direto da aplicao, somente aos usurios autorizados Restringir o acesso s URLs protegidas somente aos usurios autorizados Restringir o acesso s funes protegidas somente aos usurios autorizados Restringir o acesso s referncias diretas aos objetos somente aos usurios autorizados Restringir o acesso aos servios somente aos usurios autorizados Restringir o acesso aos dados da aplicao somente aos usurios autorizados Restringir o acesso aos atributos e dados dos usurios, bem como informaes das polticas usadas pelos mecanismos de controle de acesso Restringir o acesso s configuraes de segurana relevantes apenas aos usurios autorizados As regras de controle de acesso representadas pela camada de apresentao devem coincidir com as regras presentes no lado servidor Se o estado dos dados deve ser armazenado no lado cliente, utilizar mecanismos de criptografia e verificao de integridade no lado servidor para detectar possveis adulteraes Garantir que os fluxos lgicos da aplicao obedecem as regras de negcio Limitar o nmero de transaes que um nico usurio ou dispositivo pode executar em determinado perodo de tempo. As transaes por perodo de tempo devem estar acima das necessidades reais do negcio, mas abaixo o suficiente para impedirem ataques automatizados Utilizar o campo referer do cabealho somente como forma de verificao suplementar. O mesmo no deve ser usado sozinho como forma de validao de autorizao porque ele pode ter o valor adulterado Se for permitida a existncia de sesses autenticadas por longos perodos de tempo, fazer a revalidao peridica da autorizao do usurio para garantir que os privilgios no foram modificados e, caso tenham sido, realizar o registro em log do usurio e exigir nova autenticao Implementar a auditoria das contas de usurio e assegurar a desativao de contas no utilizadas. Por

Verso 1.3

10

Fevereiro 2012

exemplo, a conta deve ser desativada no mais do que 30 dias aps a expirao da senha

A aplicao deve dar suporte desativao de contas e ao encerramento das sesses quando terminar a autorizao do usurio. Por exemplo, quando ocorrer alguma alterao dos dados do usurio, situao profissional, processos de negcio etc. As contas de servio ou contas de suporte a conexes provenientes ou destinadas a servios externos devem possuir o menor privilgio possvel Criar uma Poltica de Controle de Acesso para documentar as regras de negcio da aplicao, tipos de dados e critrios ou processos de autorizao para que os acessos possam ser devidamente concedidos e controlados. Isto inclui identificar requisitos de acessos, tanto para os dados, como para os recursos do sistema

Prticas de Criptografia:

Todas as funes de criptografia utilizadas para proteger dados sensveis dos usurios da aplicao, devem ser implantadas em um sistema confivel (neste caso o servidor) A senha mestre deve ser protegida contra acessos no autorizados Quando ocorrer alguma falha nos mdulos de criptografia, permitir que as mesmas ocorram de modo seguro Todos os nmeros, nomes de arquivos, GUIDs e strings aleatrias devem ser gerados usando um mdulo criptogrfico com gerador de nmeros aleatrios, somente se os valores aleatrios gerados forem impossveis de serem deduzidos Os mdulos de criptografia usados pela aplicao devem ser compatveis com a FIPS 140-2 ou com um padro equivalente (http://csrc.nist.gov/groups/STM/cmvp/validation.html) Estabelecer e utilizar uma poltica e processo que defina como realizado o gerenciamento das chaves criptogrficas

Tratamento de Erros e Log:

No expor informaes sensveis nas repostas de erros, inclusive detalhes de sistema, identificadores de sesso ou informao da conta do usurio Usar mecanismos de tratamento de erros que no mostrem informaes de depurao (debug) ou informaes da pilha de exceo Usar mensagens de erro genricas e pginas de erro personalizadas A aplicao deve tratar os erros sem se basear nas configuraes do servidor A memria alocada deve ser liberada de modo apropriado quando ocorrerem condies de erro O tratamento de erros lgicos associados com os controles de segurana devem, por padro, negar o acesso Todos os controles de log devem ser implementados em um sistema confivel, por exemplo, centralizar todo o processo no servidor Os controles de log devem dar suporte tanto para os casos de sucesso como os de falha relacionados com os eventos de segurana Garantir que os logs armazenam eventos importantes Garantir que as entradas de log que incluam dados nos quais no se confia no sejam executadas como cdigo-fonte na interface de visualizao de logs Restringir o acesso aos logs apenas para pessoal autorizado Utilizar uma rotina centralizada para realizar todas as operaes de log

Verso 1.3

11

Fevereiro 2012

No armazenar informaes sensveis nos registros de logs, como detalhes desnecessrios do sistema, identificadores de sesso e senhas Garantir o uso de algum mecanismo que conduza (ou facilite) o processo de anlise de logs Registrar em log todas as falhas de validao de entrada de dados Registrar em log todas as tentativas de autenticao, especialmente as que falharam por algum motivo Registrar em log todas as falhas de controle de acesso Registrar em log todos os eventos suspeitos de adulterao, inclusive alteraes inesperadas no estado dos dados Registrar em log as tentativas de conexo com tokens de sesso invlidos ou expirados Registrar em log todas as excees lanadas pelo sistema Registrar em log todas as funes administrativas, inclusive as mudanas realizadas nas configuraes de segurana Registrar em log todas as falhas de conexo TLS com o backend Registrar em log todas as falhas que ocorreram nos mdulos de criptografia Utilizar uma funo de hash criptogrfica para validar a integridade dos registros de log

Proteo de Dados:

Implementar uma poltica de privilgio mnimo, restringindo os usurios apenas s funcionalidades, dados e informaes do sistema que so necessrias para executarem suas tarefas Proteger contra acesso no autorizado todas as cpias temporrias ou registradas em cache que contenham dados sensveis e estejam armazenadas no servidor e excluir esses arquivos logo que no forem mais necessrios Criptografar informaes altamente sensveis quando armazenadas como dados de verificao de autenticao mesmo que estejam no lado servidor, usando sempre algoritmos conhecidos, padronizados e bem testados. Consulte a seo que trata sobre Prticas de Criptografia para orientaes adicionais Proteger o cdigo-fonte presente no servidor para que no sejam acessados por algum usurio No armazenar senhas, strings de conexo ou outras informaes confidenciais em texto claro/legvel ou em qualquer forma criptograficamente insegura no lado cliente. Isso vlido tambm quando h utilizao de formatos inseguros como: MS viewstate, Adobe Flash ou cdigo compilado que executado no lado cliente Remover comentrios do cdigo de produo que podem ser acessados pelos usurios e podem revelar detalhes internos do sistema ou outras informaes sensveis Remover aplicaes desnecessrias e documentao do sistema que possam revelar informaes importantes para os atacantes No incluir informaes sensveis nos parmetros de requisio HTTP GET Desativar a funcionalidade de auto completar nos formulrios que contenham informaes sensveis, inclusive no formulrio de autenticao Desativar a cache realizada no lado cliente das pginas que contenham informaes sensveis. O parmetro Cache-Control: no-store, pode ser usado em conjunto com o controle definido no cabealho HTTP Pragma: no-cache, que menos efetivo, porm compatvel com HTTP/1.0 A aplicao deve dar suporte remoo de dados sensveis quando estes no forem mais necessrios. Por exemplo, informao pessoal ou dados financeiros Implementar mecanismos de controle de acesso apropriados para dados sensveis armazenados no

Verso 1.3

12

Fevereiro 2012

servidor. Isto inclui dados em cache, arquivos temporrios e dados que devem ser acessveis somente por usurios especficos do sistema

Segurana nas comunicaes:

Utilizar criptografia na transmisso de todas as informaes sensveis. Isto deve incluir TLS para proteger a conexo e deve ser complementado com criptografia de arquivos que contm dados sensveis ou conexes que no usam o protocolo HTTP Os certificados TLS devem ser vlidos, possurem o nome de domnio correto, no estarem expirados e serem instalados com certificados intermedirios, quando necessrio Quando ocorrer alguma falha nas conexes TLS, o sistema no deve fornecer uma conexo insegura Utilizar conexes TLS para todo o contedo que requerer acesso autenticado ou que contenha informao sensvel Utilizar TLS para conexes com sistemas externos que envolvam funes ou informaes sensveis Utilizar um padro nico de implementao TLS configurado de modo apropriado Especificar a codificao dos caracteres para todas as conexes Filtrar os parmetros que contenham informaes sensveis, provenientes do HTTP referer, nos links para sites externos

Configurao do Sistema:

Garantir que os servidores, frameworks e componentes do sistema esto executando a ltima verso aprovada Garantir que os servidores, frameworks e componentes do sistema possuem as atualizaes mais recentes aplicadas para a verso em uso Desativar a listagem de diretrios Restringir, para o mnimo possvel, os privilgios do servidor Web, dos processos e das contas de servios Quando ocorrerem excees no sistema, garantir que as falhas ocorram de modo seguro Remover todas as funcionalidades e arquivos desnecessrios Remover cdigo de teste ou qualquer funcionalidade desnecessria para o ambiente de produo, antes de instalar o sistema no servidor de produo Prevenir a divulgao da estrutura de diretrios impedindo que robs6 de busca faam indexao de arquivos sensveis, atravs da configurao do arquivo robots.txt 7. Os diretrios que no devem ser acessados por estes indexadores devem ser colocados em um diretrio isolado. Assim, apenas necessrio negar o acesso ao diretrio pai definido no arquivo robots.txt, evitando ter que negar o acesso a cada diretrio individualmente Definir quais mtodos HTTP, GET ou POST, a aplicao ir suportar e se sero tratados de modo diferenciado nas diversas pginas da aplicao Desativar as extenses HTTP desnecessrias como, por exemplo, o WebDAV. Caso seja necessrio o uso de alguma extenso HTTP com o propsito de suportar a manipulao de arquivos, utilize um mecanismo de autenticao conhecido, padronizado e bem testado
NT: Robs so programas de computador que percorrem automaticamente as pginas da Internet em busca de documentos, com o propsito de index-los, valid-los ou monitorar alteraes de contedo. http://pt.wikipedia.org/wiki/Robots.txt NT: O link abaixo mostra exemplos de como configurar o arquivo robots.txt. http://www.mundoseo.com.br/seo-tecnico/robotstxt-configuracao-seu-site/

Verso 1.3

13

Fevereiro 2012

Se o servidor processa tanto requisies HTTP 1.0 como HTTP 1.1, certificar-se de que ambos so configurados de modo semelhante ou assegure que qualquer diferena existente seja compreendida, como, por exemplo, o manuseio de mtodos HTTP estendidos Remover informaes desnecessrias presentes nos cabealhos de resposta HTTP e que podem estar relacionadas com o sistema operacional, verso do servidor web e frameworks de aplicao O armazenamento da configurao de segurana para a aplicao deve ser capaz de ser produzida de forma legvel para dar suporte auditoria Implementar um sistema de gesto de ativos para manter o registro dos componentes e programas Isolar o ambiente de desenvolvimento da rede de produo e conceder acesso somente para grupos de desenvolvimento e testes. comum os ambientes de desenvolvimento serem configurados de modo menos seguro do que os ambientes de produo. Deste modo, os atacantes podem usar essa diferena para descobrir vulnerabilidades comuns ou encontrar formas de explorao das mesmas Implementar um sistema de controle de mudanas para gerenciar e registrar as alteraes no cdigo, tanto de desenvolvimento, como dos sistemas em produo

Segurana em Banco de Dados:

Usar consultas parametrizadas fortemente tipadas Utilizar validao de entrada e codificao de sada e assegurar a abordagem de meta caracteres. Se houver falha, o comando no dever ser executado no banco de dados Certificar-se de que as variveis so fortemente tipadas Realizar a codificao (escaping) de meta caracteres em instrues SQL8 A aplicao deve usar o menor nvel possvel de privilgios ao acessar o banco de dados Usar credenciais seguras para acessar o banco de dados No incluir strings de conexo na aplicao. As strings de conexo devem estar em um arquivo de configurao separado, armazenado em um sistema confivel e as informaes devem ser criptografadas Usar procedimentos armazenados (stored procedures) para abstrair o acesso aos dados e permitir a remoo de permisses das tabelas no banco de dados Encerrar a conexo assim que possvel Remover ou modificar senhas padro de contas administrativas. Utilizar senhas robustas (pouco comuns ou difceis de deduzir) ou implementar autenticao de mltiplos fatores. Desativar qualquer funcionalidade desnecessria no banco de dados, como stored procedures ou servios no utilizados. Instalar o conjunto mnimo de componentes ou de opes necessrias (reduo da superfcie de ataque) Eliminar o contedo desnecessrio includo por padro pelo fornecedor como esquemas e bancos de dados de exemplo Desativar todas as contas criadas por padro e que no sejam necessrias para suportar os requisitos de negcio A aplicao deve conectar-se ao banco de dados com diferentes credenciais de segurana para cada tipo de necessidade como, por exemplo, usurio, somente leitura, convidado ou administrador

Gerenciamento de Arquivos:

No repassar dados fornecidos pelos usurios diretamente a uma funo de incluso dinmica

NT: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Verso 1.3

14

Fevereiro 2012

Solicitar autenticao antes de permitir que seja feito o carregamento de arquivos Limitar os tipos de arquivos que podem ser enviados para aceitar somente os necessrios ao propsito do negcio Validar se os arquivos enviados so do tipo esperado, atravs da validao dos cabealhos, pois, realizar a verificao apenas pela extenso no suficiente No salvar arquivos no mesmo diretrio de contexto da aplicao Web. Os arquivos devem ser armazenados no servidor de contedos ou no banco de dados Prevenir ou restringir o carregamento de qualquer arquivo que possa ser interpretado ou executado pelo servidor Web Desativar privilgios de execuo nos diretrios de armazenamento de arquivos Implantar o carregamento seguro nos ambientes UNIX por meio da montagem do diretrio de destino como uma unidade lgica, usando o caminho associado ou o ambiente de chroot Ao referenciar arquivos, usar uma lista branca (whitelist) de nomes e de tipos de arquivos permitidos. Realizar a validao do valor do parmetro passado e caso ele no corresponda ao que esperado, rejeitar a entrada ou utilizar um valor padro No transmitir, sem nenhum tipo de tratamento, os dados informados pelo usurio a redirecionamentos dinmicos. Se isso for necessrio, o redirecionamento dever aceitar apenas URLs relativas e validadas No passar caminhos de diretrios ou de arquivos em requisies. Usar algum mecanismo de mapeamento desses recursos para ndices definidos em uma lista pr-definida de caminhos Nunca enviar o caminho absoluto do arquivo para o lado cliente de uma aplicao ou para o usurio Certificar-se de que os arquivos da aplicao e os recursos esto definidos somente com o atributo de leitura Verificar os arquivos que os usurios submeterem atravs do mecanismo de carregamento em busca de vrus e malwares

Gerenciamento de Memria:

Utilizar controle de entrada/sada para os dados que no sejam confiveis Verificar se o buffer to grande quanto o especificado Ao usar funes que aceitem determinado nmero de bytes para realizar cpias, como strncpy(), esteja ciente de que se o tamanho do buffer de destino for igual ao tamanho do buffer de origem, ele no pode encerrar a sequncia de caracteres com valor nulo (null) Verificar os limites do buffer caso as chamadas funo sejam realizadas em ciclos e verificar se no h nenhum risco de ocorrer gravao de dados alm do espao reservado Truncar todas as strings de entrada para um tamanho razovel antes de pass-las para as funes de cpia e concatenao Na liberao de recursos alocados para objetos de conexo, identificadores de arquivo etc., no contar com o garbage collector e realizar a tarefa explicitamente Usar pilhas no executveis, quando disponveis Evitar o uso de funes reconhecidamente vulnerveis como printf(), strcat(), strcpy() etc. Liberar a memria alocada de modo apropriado aps concluir a sub-rotina (funo/mtodo) e em todos pontos de sada

Verso 1.3

15

Fevereiro 2012

Prticas Gerais de Codificao:

Para tarefas comuns, utilizar sempre cdigo testado, gerenciado e aprovado ao invs de criar cdigo novo e no gerenciado Utilizar APIs que executem tarefas especficas para realizar operaes do sistema operacional. No permitir que a aplicao execute comandos diretamente no sistema operacional, especialmente atravs da utilizao de shells de comando iniciadas pela aplicao Utilizar mecanismos de verificao de integridade por checksum ou hash para verificar a integridade do cdigo interpretado, bibliotecas, arquivos executveis e arquivos de configurao Utilizar mecanismos de bloqueio para evitar requisies simultneas para a aplicao ou utilizar um mecanismo de sincronizao para evitar condies de concorrncia (race conditions) Proteger as variveis compartilhadas e os recursos contra acessos concorrentes inapropriados Instanciar explicitamente todas as variveis e dados persistentes durante a declarao, ou antes da primeira utilizao Quando a aplicao tiver que ser executada com privilgios elevados, aumentar os privilgios o mais tarde possvel e revog-los logo que seja possvel Evitar erros de clculo decorrentes da falta de entendimento da representao interna da linguagem de programao usada e de como realizada a interao com os aspectos de clculo numrico. Prestar bastante ateno nas discrepncias de tamanho de byte, preciso, distines de sinal (signed/unsigned), truncamento, converso e casting entre os tipos, clculos que devolvam erros do tipo not-a-number e, tambm, como a linguagem de programao trata a representao interna de nmeros muito grandes ou muito pequenos No transferir, diretamente, dados fornecidos pelo usurio para qualquer funo de execuo dinmica sem realizar o tratamento dos dados de modo adequado Restringir a gerao e a alterao de cdigo por parte dos usurios Revisar todas as aplicaes secundrias, cdigos e bibliotecas de terceiros para determinar a necessidade do negcio e validar as funcionalidades de segurana, uma vez que estas podem introduzir novas vulnerabilidades Implementar atualizaes de modo seguro. Se a aplicao precisar realizar atualizaes automticas, utilizar mecanismos de assinatura digital para garantir a integridade do cdigo e garantir que os clientes faam a verificao da assinatura aps descarregarem as atualizaes. Usar canais criptografados para transferir o cdigo a partir do host do servidor

Verso 1.3

16

Fevereiro 2012

Apndice A (Recursos externos e referncias)

Referncias Externas:
1. Referncia citada Sans and TippingPoint "The Top Cyber Security Risks" http://www.sans.org/top-cyber-security-risks Web Application Security Consortium http://www.webappsec.org Common Weakness Enumeration (CWE) http://cwe.mitre.org Department of Homeland Security Build Security In Portal https://buildsecurityin.us-cert.gov/daisy/bsi/home.html CERT Secure Coding http://www.cert.org/secure-coding MSDN Security Developer Center http://msdn.microsoft.com/en-us/security/default.aspx SQL Injection Cheat Sheet http://ferruh.mavituna.com/sql-injection-cheatsheet-oku Cross Site Scripting (XSS) Cheat Sheet http://ha.ckers.org/xss.html

Sites de Avisos de Segurana:

Estes links podem ser teis para verificar e garantir que a infraestrutura de apoio e os frameworks no possuem vulnerabilidades conhecidas:
Secunia Citrix Vulnerability List http://secunia.com/advisories/search/?search=citrix Security Focus Vulnerability Search http://www.securityfocus.com/vulnerabilities Open Source Vulnerability Database (OSVDB) http://osvdb.org/search/web_vuln_search Common Vulnerability Enumeration http://www.cve.mitre.org

Verso 1.3

17

Fevereiro 2012

Apndice B (Glossrio)
Agente de Ameaa: Qualquer entidade que pode causar um impacto negativo em um sistema. Pode ser tanto um usurio mal-intencionado querendo comprometer os controles de segurana do sistema, quanto um desvio acidental do sistema ou uma ameaa fsica como incndios ou inundaes. Autenticao: um conjunto de controles usados para verificar a identidade de um usurio, ou outra entidade que interage com o software. Autenticao de Mltiplos Fatores: um processo de autenticao que requer vrios tipos de credenciais do usurio. Normalmente baseado em algo que ele possui (ex.: carto inteligente), algo que ele sabe (uma ex.: senha), ou em algo que ele (ex.: dados provenientes de um leitor biomtrico). Autenticao Sequencial: Ocorre quando os dados de autenticao so solicitados em sucessivas pginas, ao invs de serem solicitados em uma nica pgina. Canonicalizao: uma operao realizada para reduzir vrias codificaes e representaes de dados em uma nica forma simplificada. Caracteres Maliciosos: Quaisquer caracteres ou representaes codificadas de caracteres que podem produzir efeitos indesejveis sobre a operao normal de aplicaes ou dos sistemas associados quando so interpretados, por terem significado especial. Estes caracteres podem ser usados para: Modificar a estrutura de cdigo ou de declaraes Inserir cdigo indesejado Modificar caminhos Causar sadas inesperadas das funes ou rotinas dos programas Causar condies de erro Causar qualquer dos efeitos anteriores em aplicaes subjacentes

Casos de Abuso: Descrevem o mau uso, intencional ou no, do software. Os casos de abuso devem desafiar os pressupostos do projeto do sistema. Codificao de Entidade HTML: Processo de substituio de determinados caracteres ASCII pelas entidades HTML equivalentes. Por exemplo, a codificao poderia substituir o caractere < pela entidade HTML equivalente "&lt;". Essas entidades so inertes na maioria dos interpretadores especialmente navegadores e podem atenuar os ataques do lado cliente. Codificao de Sada Baseada em Contexto: a codificao de dados da sada realizada usando como referncia o modo como os dados sero utilizados pela aplicao. Se os dados da sada estiverem includos na resposta ao cliente, deve-se levar em considerao situaes como: o corpo de um documento HTML, um atributo de HTML, codificao JavaScript, codificao dentro de um CSS ou de uma URL. Devem tambm ser levados em considerao outros casos como consultas SQL, XML e LDAP. Codificao de Sada de Dados: um conjunto de controles que abordam o uso de codificao para

Verso 1.3

18

Fevereiro 2012

garantir uma sada de dados segura gerada pela aplicao. Confidencialidade: o ato de garantir que as informaes so divulgadas apenas para as partes autorizadas. Configurao do Sistema: Conjunto de controles que ajudam a garantir que infraestrutura de apoio ao software so implantados de forma segura. os componentes de

Consultas Parametrizadas (prepared statements): Mantm a consulta e os dados separados atravs do uso de espaos reservados. A estrutura de consulta definida por caracteres especiais que representam os parmetros a serem substitudos. A consulta parametrizada enviada para o banco de dados, preparada para receber os parmetros e, em seguida, combinada com os valores dos mesmos. Isto impede que a consulta seja alterada porque os valores dos parmetros so combinados com a declarao compilada e no concatenados diretamente na sequncia de caracteres que compem a consulta SQL. Controle de Acesso: um conjunto de controles que libera ou nega o acesso a um recurso do sistema a um usurio ou outra entidade qualquer. Normalmente baseado em regras hierrquicas e privilgios individuais associados a papis, porm tambm inclui interaes entre sistemas. Controles de Segurana: So aes que mitigam uma vulnerabilidade potencial e ajudam a garantir que o software se comporta conforme o esperado. Cross Site Request Forgery (CSRF): Ocorre quando uma aplicao ou site web externos fora o navegador do cliente a realizar uma requisio involuntria para uma aplicao em que o cliente possua uma sesso ativa. As aplicaes so vulnerveis ao CSRF quando usam URLs e parmetros conhecidos ou previsveis ou quando o navegador transmite todas as informaes da sesso para a aplicao vulnervel de forma automtica em cada solicitao. Esse apenas um dos ataques discutidos nesse documento e s est includo porque a vulnerabilidade associada muito comum, porm mal compreendida. Disponibilidade: a propriedade de estar acessvel e utilizvel quando demandado por uma entidade autorizada. Estado dos Dados: So dados ou parmetros usados pela aplicao ou pelo servidor para emular uma conexo persistente ou controlar o estado (status) de um cliente atravs de um processo de mltiplas requisies ou transaes. Exploit: a ao de aproveitar-se da existncia de uma vulnerabilidade. Normalmente uma ao intencional e tem como objetivo comprometer os controles de segurana do software. Gerncia de Arquivo: um conjunto de controles que resguardam a interao entre o cdigo da aplicao e os arquivos do sistema. Gerenciamento de Memria: um conjunto de controles que dizem respeito ao uso de memria e do buffer. Gerenciamento de Sesso: um conjunto de controles que tratam da manipulao de sesses HTTP de forma segura por aplicaes Web.

Verso 1.3

19

Fevereiro 2012

Impacto: o efeito negativo perceptvel para o negcio, resultante da ocorrncia de um evento indesejvel, que por sua vez o resultado da explorao de vulnerabilidades. Integridade: a garantia de que as informaes so precisas, completas e vlidas, e que no foram alteradas por uma ao no autorizada. Limites de Confiana: Normalmente, um limite de confiana constitudo pelos componentes do sistema sobre os quais se tem controle direto. Todas as conexes e dados do sistema fora desse controle direto incluindo todos os clientes e sistemas gerenciados por terceiros devem ser considerados como no confiveis e necessitam de validao na fronteira, antes de receberem permisses para realizarem interaes com o sistema. Mitigar: So medidas tomadas para reduzir o grau de severidade de uma vulnerabilidade. Essas medidas incluem a remoo de uma vulnerabilidade, seja ao torn-la mais difcil de ser explorada ou ao reduzir o impacto negativo de uma explorao bem sucedida. Prticas de Criptografia: Conjunto de controles para garantir que as operaes de criptografia dentro da aplicao sejam executadas de modo seguro. Prticas Gerais de Codificao: Conjunto de controles abrangendo prticas de codificao que no se encaixam facilmente em outras categorias. Proteo dos Dados: Conjunto de controles para ajudar a garantir que o software trata o armazenamento das informaes de modo seguro. Realizar Log dos Eventos: Esta operao deve incluir os seguintes requisitos: 1. Utilizar um timestamp9 proveniente de um sistema confivel 2. Classificar a severidade para cada evento 3. Destacar eventos de segurana relevantes, caso eles sejam misturados com outros registros de log 4. Registrar o identificador da conta ou usurio que causou o evento 5. Registrar o endereo IP de origem que realizou a requisio 6. Registrar o resultado dos eventos (sucesso ou falha) 7. Registrar a descrio do evento Requisitos de Segurana: Conjunto de requisitos funcionais e de projeto para ajudar a garantir que o software seja construdo e implantado de forma segura. Segurana das Comunicaes: Conjunto de controles para ajudar a garantir o envio e o recebimento das informaes de modo seguro. Segurana de Banco de Dados: Conjunto de controles para garantir que o software interaja com os bancos de dados de forma segura e que os bancos de dados estejam configurados de forma segura.
9

NT: Conjunto de caracteres que representa, de forma no ambgua, o momento do registro da ocorrncia de um evento em um sistema. Para mais informaes, ver a RFC 3339 e a norma ISO 8601, Data elements and interchange formats Information interchange Representation of dates and times.

Verso 1.3

20

Fevereiro 2012

Sistema: um termo genrico que abrange sistemas operacionais, servidores web, frameworks de aplicaes e infraestrutura relacionada. Tratamento de Erros e Log: Conjunto de prticas para garantir que a aplicao realize o tratamento dos erros de modo seguro e, tambm realize o registro de log dos eventos de modo apropriado. Tratamento dos Dados: o processo de tornar seguros os dados potencialmente prejudiciais atravs do processo de remoo, substituio, codificao ou escaping10 dos caracteres. Validao de Entrada de Dados: Conjunto de controles para verificar se as propriedades de todas as entradas de dados correspondem ao que esperado pela aplicao, como, por exemplo, tipo dos dados, tamanho, intervalos, conjunto de caracteres aceitveis e ausncia de caracteres maliciosos. Vulnerabilidade: uma fragilidade que torna um sistema suscetvel a um ataque ou a um dano.

10

NT: Nesse contexto a representao de caracteres especiais por conjuntos especficos de caracteres. Como exemplo, tem-se a substituio do caractere & pela entidade HTML equivalente &amp;.

Verso 1.3

21