baseline fábrica de software e desenvolvimento

Diretoria de Segurança Corporativa

Superintendência de Segurança da Informação

Baseline de Segurança da Informação

Avaliação de Fornecedor

Fábrica de Software

Baseline de Análise de Risco em Fornecedores

09/04/15 Pág: 2

SUMÁRIO:

1. SEGURANÇA DA REDE: .......................................................................................................................................... 5

2. PATCHES DE SEGURANÇA: .................................................................................................................................... 5

3. HARDENING: ........................................................................................................................................................ 5

4. SCANNING: ........................................................................................................................................................... 6

5. PEN TEST: ......................................................................................................................................................... 6

6. PROCEDIMENTOS PARA TRATAMENTO DE INFORMAÇÃO: ................................................................. 6

7. REGISTRO DE USUÁRIO: ............................................................................................................................... 7

8. RETIRADA DE DIREITOS DE ACESSO:........................................................................................................ 7

9. SEGREGAÇÃO DE FUNÇÕES: ...................................................................................................................... 7

10. GERENCIAMENTO DE SENHA DO USUÁRIO: ............................................................................................ 8

11. PROCEDIMENTOS SEGUROS DE ENTRADA NOS SISTEMAS: ............................................................... 8

12. NAVEGAÇÃO INTERNET: ............................................................................................................................... 9

13. MENSAGENS ELETRÔNICAS: ....................................................................................................................... 9

14. POLÍTICA DE ESTAÇÃO DE TRABALHO:.................................................................................................... 9

15. SENHA DE BIOS / ACESSO VIA USB: ......................................................................................................... 10

16. FERRAMENTA DE CAPTURA REMOTA: ..................................................................................................... 10

17. AUTENTICAÇÃO PARA CONEXÃO EXTERNA DO USUÁRIO: ................................................................ 10

18. REGISTROS E PROTEÇÃO DE TRILHAS DE AUDITORIA: ...................................................................... 10

19. CRIPTOGRAFIA DE DISCO:........................................................................................................................... 11

20. SISTEMA OPERACIONAL ATUALIZADO COM VERSÕES SUPORTADAS PELO FABRICANTE: ..... 11

21. SINCRONIZAÇÃO DOS RELÓGIOS: ............................................................................................................ 11

22. CONTROLES CONTRA CÓDIGOS MALICIOSOS: ...................................................................................... 11

23. GESTÃO DE MUDANÇAS: ............................................................................................................................. 12

24. SEPARAÇÃO DOS RECURSOS DE DESENVOLVIMENTO, TESTE E DE PRODUÇÃO: ...................... 12

25. CÓPIAS DE SEGURANÇA DAS INFORMAÇÕES: ...................................................................................... 12

26. POLÍTICA DE SEGURANÇA DA INFORMAÇÃO: ........................................................................................ 12

27. POLÍTICA DE MESA LIMPA: .......................................................................................................................... 13

28. POLÍTICA DE TELA LIMPA: ........................................................................................................................... 13

29. COORDENAÇÃO DA SEGURANÇA DA INFORMAÇÃO:........................................................................... 13

30. RESPONSABILIDADES E PROCEDIMENTOS (INCIDENTES DE SEGURANÇA DA INFORMAÇÃO):

13

31. RECOMENDAÇÕES PARA CLASSIFICAÇÃO: ........................................................................................... 14

32. ACORDOS DE CONFIDENCIALIDADE: ........................................................................................................ 14

33. CONSCIENTIZAÇÃO, EDUCAÇÃO E TREINAMENTO EM SEGURANÇA DA INFORMAÇÃO: ............ 15

34. INVENTÁRIO DOS ATIVOS: ........................................................................................................................... 15

35. REMOÇÃO DE PROPRIEDADE: .................................................................................................................... 15

36. CONTROLES DE ENTRADA FÍSICA: ............................................................................................................ 15


09/04/15 Pág: 3

37. CONTINUIDADE DE NEGÓCIOS: .................................................................................................................. 16

38. INSPEÇÕES PERIÓDICAS DE VERIFICAÇÃO DE COMPLIANCE AOS REQUISITOS DE

SEGURANÇA: .......................................................................................................................................................... 16

ANEXO A – SEGURANÇA PARA DESENVOLVIMENTO DE APLICAÇÕES ................................................... 17

1. INTRODUÇÃO .................................................................................................................................................. 17

2. DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS GERAIS ........................................................ 17

3. REVISÃO SEGURA DE CÓDIGO – PRÁTICAS GERAIS ............................................................................ 19

4. DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS ESPECÍFICAS ............................................. 20

4.1. PROTEÇAO PARA WEBSERVICES .............................................................................................................. 20

4.2. PROTEÇÃO PARA APLICATIVOS MÓVEIS ................................................................................................ 21

4.3. PROTEÇAO PARA BANCO DE DADOS ....................................................................................................... 23

4.4. GERENCIAMENTO E EXECUÇÃO MALICIOSA DE ARQUIVOS .............................................................. 24

4.4.1. EXEMPLOS: ............................................................................................................................................... 24

4.4.2. REFERENCIAS:......................................................................................................................................... 25

4.5. FALHAS DE INJEÇÃO .................................................................................................................................... 25

4.5.1. PROTEÇÃO – SQL INJECTION .............................................................................................................. 26

4.5.2. PROTEÇÃO – OS COMMAND INJECTION ........................................................................................... 26

4.5.3. PROTEÇÃO – PATH TRAVERSAL/DISCLOSURE ............................................................................... 26

4.5.4. EXEMPLOS ................................................................................................................................................ 27

4.5.5. REFERÊNCIAS .......................................................................................................................................... 27

4.5.6. REVISÂO DE CÒDIGO ............................................................................................................................. 27

4.6. FALHA DE AUTENTICAÇÃO E GERENCIAMENTO DE SESSÃO ............................................................ 27

4.6.1. PROTEÇÃO - REPLAY DE SESSÃO ...................................................................................................... 29

4.6.2. PROTEÇÃO – HIJACKING DE SESSÃO ............................................................................................... 29

4.6.3. EXEMPLOS ................................................................................................................................................ 29

4.6.4. REFERÊNCIAS .......................................................................................................................................... 29

4.6.5. REVISÃO DE CÓDIGO ............................................................................................................................. 30

4.7. PROTEÇÃO CONTRA CROSS-SITE SCRIPTING (XSS) ............................................................................ 30

4.7.1. EXEMPLOS ................................................................................................................................................ 31

4.7.2. REFERÊNCIAS .......................................................................................................................................... 31

4.7.3. REVISÃO DE CÓDIGO .................................................................................................................................... 31

4.8. REFERÊNCIA DIRETA INSEGURA A OBJETOS ....................................................................................... 31

4.8.1. EXEMPLOS ................................................................................................................................................ 32

4.8.2. REFERÊNCIAS .......................................................................................................................................... 32

4.9. INFRAESTRUTURA E AMBIENTE ................................................................................................................. 32

4.9.1. LOGS PARA AUDITORIA ........................................................................................................................ 34

4.10. ARMAZENAMENTO CRIPTOGRÁFICO INSEGURO ........................................................................... 34

4.10.1. EXEMPLOS ............................................................................................................................................ 35


09/04/15 Pág: 4

4.10.2. REFERÊNCIAS ...................................................................................................................................... 36

4.11. FALHAS AO RESTRINGIR ACESSO A URLS ...................................................................................... 36

4.11.1. EXEMPLOS ............................................................................................................................................ 37

4.11.2. REFERÊNCIAS ...................................................................................................................................... 37

4.12. COMO EVITAR CROSS-SITE REQUEST FORGERY (CSRF) ............................................................. 37

4.12.1. EXEMPLOS ............................................................................................................................................ 38

4.12.2. REFERÊNCIAS ...................................................................................................................................... 38

4.12.3. REVISÃO DE CÓDIGO ................................................................................................................................ 38

4.13. REDIRECIONAMENTOS E ENCAMINHAMENTOS INVÁLIDOS ......................................................... 38

4.13.1. EXEMPLOS ............................................................................................................................................ 39

4.13.2. REFERÊNCIAS ...................................................................................................................................... 39

4.14. EVITANDO O BUFFER OVERFLOWS/OVERRUNS ............................................................................. 39

4.14.1. REFERENCIA ........................................................................................................................................ 39

4.14.2. REVISÃO DE CÓDIGO ......................................................................................................................... 40

4.15. TRATAMENTO DE DADOS CONTRA INTEGER AND ARITHMETIC OVERFLOWS ....................... 40

4.15.1. EXEMPLOS ............................................................................................................................................ 40

4.15.2. REFERÊNCIAS ...................................................................................................................................... 40

4.16. FORMAT SPRING NÃO CONTROLADA ................................................................................................ 41

4.16.1. EXEMPLOS ............................................................................................................................................ 41

4.16.2. REFERÊNCIAS ...................................................................................................................................... 41

4.17. CONDIÇÕES DE CONCORRÊNCIA ....................................................................................................... 41

4.17.1. REFERÊNCIAS ...................................................................................................................................... 42

4.17.2. REVISÃO DE CÓDIGO ......................................................................................................................... 42

4.18. COMUNICAÇÕES INSEGURAS .............................................................................................................. 42

4.18.1. EXEMPLOS ............................................................................................................................................ 43

4.18.2. REFERÊNCIAS ...................................................................................................................................... 43


09/04/15 Pág: 5

Os controles de segurança a seguir devem ser implantados:

1. Segurança da rede:

Manter atualizado o diagrama da rede, mostrando os componentes de rede que garantam a

proteção das informações do Itaú Unibanco necessários à operacionalização do serviço (incluir

nessa representação roteadores, switches, firewalls dedicados e eventuais topologias de rede

sem fio existentes). Os pré-requisitos mínimos de rede devem estar aplicados, conforme abaixo:

conexão dedicada com o Itaú Unibanco, ficando o modelo triangulado (derivação da rede

para outros sites) como não recomendado;

firewall com controle de sessão, respeitando um tempo de vida de sessão de 1 hora;

controle de acesso aos pontos de rede via 802.1X, para validação de certificados de

máquina e de usuário através de servidor Radius, que tratará as requisições informando

aos switches se devem direcionar o acesso para a rede corporativa (no caso de

certificados validados) ou para a rede de visitantes (no caso de certificados inválidos ou

inexistentes);

sistemas de detecção de invasão e/ou sistemas de prevenção contra invasão para

monitorar/bloquear todo o tráfego malicioso;

formalização, justificativa, aprovação e teste de todas as regras configuradas do firewall,

roteador e switch, não podendo haver regras com origem, destino ou porta “any” (qualquer

protocolo ou endereço IP);

se houver rede WI-FI, deverá ser implementada segurança via WPA2 com autenticação

através do protocolo 802.1X;

não deverá existir “Trust” (confiança entre domínios) entre servidores Windows da

operação Itaú Unibanco com qualquer outro servidor.

2. Patches de Segurança:

Um procedimento de identificação e atualização de Patches de Segurança deve ser posto em

prática para que os patches sejam instalados em até 30 dias da divulgação pelo fabricante e

obedecidos os critérios de homologação.

3. Hardening:

Aplicar procedimento de blindagem dos equipamentos (hardening) para prover proteção a esses

recursos. Vide documentos a seguir, que deverão ser solicitados para a Área de Segurança da

Informação do Itaú, assim que o serviço for contratado:

Itau_Hardening_PTB - Network Devices – Router;

Itau_Hardening_PTB - Network Devices – Switch;


09/04/15 Pág: 6

Itau_Hardening_PTB - Windows IIS;

Itau_Hardening_PTB - Windows Servidor;

Itau_Hardening_PTB - Windows Workstation.

Obs.: Estes documentos devem ter acesso restrito às equipes envolvidas

4. Scanning:

Um procedimento de varredura de vulnerabilidades em equipamentos de rede (scanning) deve

ser executado ao menos 01 vez ao mês e/ou após modificações significativas no ambiente.

5. Pen Test:

Realizar PenTest (teste de invasão) no perímetro interno e externo para identificação de

vulnerabilidades pelo menos uma vez ao ano ou após modificações significativas no ambiente.

6. Procedimentos para tratamento de informação:

Em caso de empresa com acesso ao ambiente do Itaú:

Deverá ser feito exclusivamente ao ambiente de desenvolvimento com o VDI.

Em caso de empresa que irá receber Código Fonte:

para a transmissão/recepção das documentações e códigos fonte deve ser utilizada solução homologada pela área de tecnologia, com garantia de autenticidade, criptografia e regras de Firewall específicas autorizadas e liberadas através de rede DMZ;

O processo de inserção do código fonte enviado pela fábrica no ambiente de desenvolvimento deverá seguir o fluxo atualmente previsto na metodologia de desenvolvimento de sistemas;

Não encaminhar informações do Itaú Unibanco para empresas terceiras sem a prévia

avaliação e consentimento da área de Segurança da Informação do Itaú. deve existir

um procedimento de gestão de acessos (fluxo com alçadas de aprovação para

cadastro e revogação e revisão de acessos de usuários);

criar mecanismos de trilha de auditoria em todo o ciclo de vida da informação

(recepção, processamento e saídas).

O Datacenter da empresa deverá estar no Brasil, em função da diversidade de legislações em

outros países, dificuldades de investigação e atuação no caso de problema.

A área de Segurança da Informação do Itaú deverá ser informada quando houver a intenção de

terceirização do Datacenter (Colocation e Hosting) para emitir uma avaliação de Risco.


09/04/15 Pág: 7

7. Registro de usuário:

Estabelecer procedimentos que orientem a concessão e revogação de contas de acesso,

tornando obrigatório:

identificação de usuário (ID) único, pessoal e exclusivo para assegurar a responsabilidade de cada usuário por suas ações;

disponibilização de acessos levando em consideração o mínimo privilégio (necessidade para o negócio ou por razões operacionais);

formalizar os direitos de acesso fornecidos aos usuários;

liberar acesso aos usuários somente após conclusão dos procedimentos de autorização;

não permitir a utilização de usuário genérico no ambiente de produção;

manter um registro formal de todas as pessoas com direito de acesso concedido;

assegurar a remoção imediata, ou bloqueio dos direitos de acesso, de usuários que mudaram de cargos, funções ou deixaram a empresa.

8. Retirada de direitos de acesso:

Um fluxo de ‘exclusão/bloqueio’ imediato de acessos físicos e lógicos, de forma que reflita as

ações do RH, deve estar aplicado para:

suspender funcionários em ausência legal (ex. férias, licenças, etc.) por todo o período que estiverem fora da empresa;

ter procedimento para casos de necessidade de exclusão imediata de acessos físicos e lógicos;

ter processo de revisão mensal em todas as plataformas de acessos (redes e sistemas), inclusive de clientes.

9. Segregação de funções:

Um critério de segregação de funções baseado em ‘cargos/funções/atividades/cliente/ operação’,

deve estar estabelecido, de forma que o funcionário tenha somente acesso ao indispensável para

a execução da atividade para a qual foi contratado. Além disso:

estágios críticos de processo, desempenhadas, por exemplo, pelo administrador do sistema, security officer ou auditor fiquem a cargo de dois ou mais funcionários;

categorias e perfis de usuários aos quais privilégios especiais de acesso precisam ser concedidos devem estar identificados e registrados (ex: no AD, RACF ou outro sistema de controle).


09/04/15 Pág: 8

10. Gerenciamento de senha do usuário:

Uma política de senhas ‘forte’ deve ser criada de acordo com a tabela a seguir:

Políticas Parâmetro

Histórico de senhas Manter as últimas 24 senhas

Duração máxima da senha 30 dias

Duração mínima da senha 1 dia

Tamanho mínimo da senha

mínimo de 8 caracteres para usuários comuns

mínimo de 15 caracteres para usuários

administradores

Duração do bloqueio Manual – Requer intervenção da área de suporte

Exclusão de conta por inatividade de uso

Remover as contas dos usuários inativos há 60

dias. Exceção: usuário de conta de sistema ou

especiais

Números de tentativas inválidas de logon 3

Complexidade

As senhas devem ser compostas por no mínimo

três das regras abaixo:

Caracteres maiúsculos (A, B, C...).

Caracteres minúsculos (a, b, c...)

Numerais (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)

Caracteres especiais (@ # &)

Adicionalmente, devem ser criados procedimentos para:

verificar a identidade do usuário antes de fornecer uma senha temporária, de substituição ou nova;

nunca armazenar as senhas nos sistemas de um computador de forma desprotegida;

aplicar a criptografia no mínimo Kerberos para cache de senhas;

orientar usuários a manter a confidencialidade das senhas e evitar manter anotadas as senhas, a menos que elas possam ser armazenadas de forma segura;

controlar o uso de senhas de usuários com perfil de administração (ex: root, sa, administrator, etc), que deverão ser digitadas por pelo menos duas pessoas, envelopadas e mantidas em local com controle de acesso físico.

11. Procedimentos seguros de entrada nos sistemas:

Um aviso geral informando que somente pessoas autorizadas devem obter acesso ao

computador deve ser exibido no início do processo de login.

Mensagens de ajuda durante o procedimento de entrada nos sistemas não devem ser exibidas,

para que não auxiliem um eventual usuário não autorizado na tentativa de acesso.


09/04/15 Pág: 9

12. Navegação internet:

Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado o acesso

a Navegação Internet.

13. Mensagens eletrônicas:

Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado o acesso

para envio e recebimento de E-mail Externo.

14. Política de Estação de Trabalho:

Deve ser implementado o bloqueio nos itens abaixo:

botão Executar;

botão Configurações;

compartilhamento entre estações de trabalho;

gerenciador de tarefas;

gravação em mídia removível;

browsers para a execução de programas;

acessos administrativos;

alteração de horário;

cache de credenciais;

programas e serviços (ver necessidade da Operação);

execução automática de programa (autorun), que deverá estar desabilitada em todos os drivers;

instalação de impressora;

gravação de arquivos na estação de trabalho pelos usuários da operação.

Além disso, racks e cadeados devem ser utilizados para evitar acesso físico não autorizado nas

estações, impedindo troca ou furto do disco rígido do equipamento.

A execução de Scripts deve ser desabilitada através de restrições nos arquivos cscript.exe e no

wscript.exe, também se faz necessário desativar o Windows Script Runtime (SCRRUN.DLL). Vl,

verificar também, no caso da utilização do pacote office, politicas de grupo para desativar a

execução de macros (vide: http://technet.microsoft.com/en-us/library/ee857085.aspx ).

Adicionalmente, incluir os demais controles do documento anexo (Itaú_hardening-ptb_windows

Workstation.docx). Caso o sistema operacional das estações seja diferente de Windows,

consultar a área de Segurança da Informação do Itaú para avaliação dos controles necessários.

http://technet.microsoft.com/en-us/library/ee857085.aspx


09/04/15 Pág: 10

15. Senha de BIOS / Acesso via USB:

Uma senha de BIOS deve ser definida e utilizada para que não seja possível iniciar o sistema

operacional das estações através de mídia removível. Cuidados especiais devem ser adotados

para que esta senha seja utilizada apenas em caso de manutenções.

A prevenção ao uso de USBs nas estações não deverá ser provida apenas por soluções

baseadas em ‘Filter Drivers’. Assim, desabilitar a USB na BIOS e proteger a mesma com senha,

ou desativar o hardware do USB dentro da estação (nesta última situação, desde que haja

controle robusto que impeça o acesso ao interior do gabinete da máquina).

16. Ferramenta de Captura Remota:

Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado a

utilização de ferramenta de captura remota.

17. Autenticação para conexão externa do usuário:

Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado acesso

remoto.

18. Registros e proteção de Trilhas de Auditoria:

Devem ser padronizados os registros de logs de auditoria para as atividades de usuários,

exceções e outros eventos de rede e sistemas, incluindo:

identificação (ID) do usuário;

data e o horário de entrada (logon) e saída (logoff) dos eventos-chave;

tipo do evento;

os arquivos cujo acesso foi obtido, os programas ou utilitários utilizados;

todas as operações privilegiadas (utilização de contas administrativas);

inicialização e finalização do sistema e tentativas de acesso não autorizado (intrusion detection);

violação da política de acesso e notificações para gateways e firewalls da rede;

alertas dos sistemas proprietários de detecção de intrusão e de falhas do sistema (alertas ou mensagens do console);

registro das exceções do sistema.

Além disso, os seguintes critérios de proteção e retenção devem ser aplicados:

não permitir que os administradores de sistemas e redes tenham permissão de exclusão ou desativação dos registros de log de suas próprias atividades, seguindo as orientações estabelecidas nas regras de segregação de funções;


09/04/15 Pág: 11

aplicar medidas de segregação de funções para assegurar que as pessoas autorizadas que realizam atividades nos servidores de log sejam diferentes daquelas que realizam a auditoria;

utilizar protocolos seguros (por exemplo: SSL/SSH) para acesso remoto aos servidores de log;

registrar todas as atividades executadas nos servidores de log;

documentar todos os procedimentos dos servidores de log, tais como: configuração e instalação, administração e operação, backup e manutenção, acessos a todas as trilhas de auditoria, inicialização dos registros de auditoria;

manter um histórico do registro de log de auditoria conforme determinações de órgãos reguladores ou por pelo menos um ano, com um mínimo de três meses, imediatamente disponível para análise (por exemplo, online, arquivado ou recuperável a partir do backup).

19. Criptografia de disco:

Criptografia no disco das estações de trabalho deve estar implementada, com algoritmo mínimo 3DES. O sistema operacional dessas estações deve ser Windows 7 ou superior, pois a ferramenta ‘Bitlocker’ já se encontra nativa nas versões Enterprise ou Ultimate (a manutenção de versões anteriores no ambiente tecnológico, Windows XP, por exemplo, torna obrigatório o uso de uma solução de criptografia de disco).

20. Sistema Operacional atualizado com versões suportadas pelo fabricante:

Manter o parte tecnológico atualizado. Ex: Como o WinXP perde o suporte em 04/2014, o mínimo seria Win7, no caso de plataforma Windows.

21. Sincronização dos relógios:

Implementar mecanismo que permita a sincronização dos relógios de computadores a um padrão

de tempo confiável, por exemplo, o tempo coordenado universal ("Coordinated Universal Time" -

UTC) ou um padrão de tempo local (Observatório Nacional - ON).

22. Controles contra códigos maliciosos:

Softwares maliciosos, tais como vírus de computador, cavalos de Tróia e "worms" de rede, devem

ser controlados através de:

política formal de uso de software;

homologação pela Área de Tecnologia;

software antivírus atualizado em todas as estações de trabalho e servidores;

varredura de vírus em qualquer arquivo recebido por mídias e redes;

manutenção em estações de trabalho sendo feitas somente por pessoal autorizado.


09/04/15 Pág: 12

23. Gestão de mudanças:

Deve haver um processo formalizado para gestão de mudanças com:

fluxo de comunicação com os detalhes das mudanças para todas as pessoas envolvidas, incluindo o Itaú;

identificação, registro e aprovação formal das mudanças significativas;

planejamento, teste e avaliação de impactos operacionais e de segurança das mudanças;

procedimentos de recuperação em caso de insucesso ou ocorrência de eventos inesperados.

24. Separação dos recursos de desenvolvimento, teste e de produção:

Segregação dos ambientes de ‘desenvolvimento/teste’ dos de produção, implementando:

perfis diferentes de acesso de usuários em situação de desenvolvimento, de teste e de produção;

proteção e controle dos dados de teste (mascaramento), não utilizando os dados de produção;

controle para impedir que informações do ambiente de produção não sejam transferidas para outros ambientes.

25. Cópias de segurança das informações:

Prover cópias de segurança das informações pertencentes à operação do Itaú Unibanco,

conforme periodicidade acordada, com no mínimo:

teste mensal das cópias;

identificação das mídias de armazenamento;

As mídias contendo as cópias deverão ser armazenadas em local com segurança compatível a

existente na proteção da sala de servidores, com acesso restrito ao ambiente, monitoração por

câmeras, controle de movimentação dessas mídias e necessidade de autorização (nível

gerencial) na realização dos restores dos dados.

26. Política de segurança da informação:

Um documento que possa nortear a gestão da segurança das informações corporativas deve

existir, com no mínimo:

aprovação pela Alta Administração;

divulgação e disponibilidade para consulta de todos os funcionários e terceiros da empresa, através da Intranet ou outro meio;


09/04/15 Pág: 13

revisão uma vez ao ano, com registro da versão e da data;

definição de papéis e responsabilidades dos custodiantes de informações críticas;

definição de sanções em caso de descumprimento de com qualquer item.

27. Política de mesa limpa:

Deve haver um documento disciplinando cuidados com a política de mesa limpa,

‘definindo/orientando’ (no mínimo):

os autorizados a utilizar impressora e fax no ambiente de atendimento;

a retirada imediata de informações sensíveis e classificadas, quando impressas, das impressoras e fax;

o local apropriado para armazenar os papéis (relatórios) e mídia eletrônica.

28. Política de tela limpa:

Assim como na política de mesa limpa, um documento deverá existir para orientar sobre a

necessidade de:

desligamento dos computadores pessoais, terminais de computador e impressoras quando não estiverem sendo utilizados;

bloqueio da estação e da console dos servidores sempre que a pessoa se ausentar.

29. Coordenação da segurança da informação:

Uma estrutura de gerenciamento de segurança da informação deve existir na Organização,

definindo responsáveis:

pelo desenvolvimento e implementação de controles, com independência da Área de Tecnologia;

por definir e garantir a aderência da empresa às diretrizes de Segurança da Informação;

por identificar as ameaças significativas e a exposição da informação;

por promover a conscientização de todos os funcionários e terceiros;

monitorar os controles e realizar uma análise crítica dos incidentes.

30. Responsabilidades e Procedimentos (Incidentes de Segurança da Informação):

Quanto aos incidentes de Segurança da Informação, deve have planos de respostas para cada

um dos incidentes, prevendo:

falhas;


09/04/15 Pág: 14

códigos maliciosos;

negação de serviço;

erros resultantes de dados incompletos ou inconsistentes;

violações de confidencialidade e integridade e uso impróprio de sistemas de informação;

definição das responsabilidades no tratamento aos incidentes;

garantia da proteção das trilhas de auditoria e evidências relacionadas ao incidente;

comunicação imediata do incidente de segurança envolvendo o Itaú Unibanco.

31. Recomendações para classificação:

Um procedimento para classificar informações, que defina um conjunto apropriado de níveis de

proteção e determine a necessidade de medidas especiais de tratamento para cada um desses

níveis deverá existir, considerando, no mínimo:

estar baseado nos requisitos contratuais ou de conformidade legal, como o PCI, ISO 27001, SOX etc.;

ter a designação dos responsáveis, custodiantes e usuários das informações;

rótulos e regras para o tratamento seguro das informações durante todo o ciclo de vida;

critérios de armazenamento, backup, transmissão e descarte seguro para informações impressas e lógicas;

três níveis de classificação, por exemplo, Públicas, Internas e Confidenciais, considerando que toda informação encaminhada pelo Itaú Unibanco deve ser classificada como Confidencial.

32. Acordos de confidencialidade:

Deve existir um documento assinado por todos os funcionários e terceiros para que estejam

cientes das suas responsabilidades de Segurança da Informação, com no mínimo:

aprovação pelo Jurídico da empresa;

consideração sobre riscos, controles de segurança, políticas e procedimentos para os sistemas de informação, no que diz respeito à questão de sigilo e condições de uso das informações disponibilizadas em rede de computadores e/ou estações de trabalho no contrato entre as partes;

assinatura e data;

indicação de que a confidencialidade deve ser mantida mesmo após o desligamento do funcionário ou terceiro;


09/04/15 Pág: 15

definição de sanções em caso de violação.

33. Conscientização, educação e treinamento em segurança da informação:

Um programa para garantir que os colaboradores sejam conscientizados em Segurança da

Informação deverá ser aplicado, desde a contratação e em campanhas periódicas, com no

mínimo:

reconhecimento do conteúdo do treinamento, através de formalização;

atualizações regulares sobre as políticas e procedimentos organizacionais;

meios de divulgação da campanha de forma que todos os funcionários e terceiros tenham acesso;

campanha no mínimo uma vez ao ano.

34. Inventário dos ativos:

Um inventário dos ativos de TI deve manter o registro de identificação, localização e informação

armazenada. Esse controle deverá conter as seguintes informações mínimas:

ativos físicos: especificação, tipo, número de série, MAC address/hostname de equipamentos computacionais (estação, notebook, servidor, roteador, firewall e switch), localização (prédio, andar, operação/setor). Considerar também: mídia magnética (fita e CD/DVD), equipamentos de comunicação (celulares) e outros equipamentos técnicos (exemplo: no-break e gerador);

inventário de software: nome, versão de aplicativos, sistemas, ferramentas de desenvolvimento e utilitários.

35. Remoção de propriedade:

Um fluxo formalizado de retirada e devolução de equipamentos (ex: dispositivos de comunicação

móvel), informações ou software deve estar sendo aplicado, contendo descrição do ativo e motivo

da retirada, autorizada pelo responsável pelo ativo (no mínimo gerente).

36. Controles de entrada física:

Controles de entrada apropriados devem estar implementados para assegurar que somente

pessoas autorizadas tenham acesso físico a empresa e áreas restritas (ex: Datacenter e

Operação), com no mínimo:

segregação das áreas críticas (ex: Datacenter e Operação);

identificação para acesso às áreas autorizadas por biometria, crachá (com foto) ou senha;

registro de data e hora de entrada e saída, mantendo histórico dos acessos por 90 dias;


09/04/15 Pág: 16

monitoração de CFTV, garantindo que todas as entradas, saídas e corredores sejam monitorados, retendo as imagens por no mínimo 90 dias;

procedimento para que terceiros que realizam serviços de suporte, tenha acesso restrito às áreas necessárias ao atendimento, sempre monitorado por um funcionário autorizado;

procedimento para formalização de inclusão, exclusão e revisão dos acessos concedidos;

equipamentos posicionados de forma que o ângulo de visão seja restrito;

proibição de entrada no ambiente de Operação com pertences que possam ser utilizados para saída de informação, tais como: papéis, canetas, bolsas, celulares, máquinas fotográficas, filmadoras etc;

portas e janelas trancadas, quando não utilizadas, e dotadas de proteção externa;

cabeamento da rede dentro de racks trancados com chave quando não estiverem sofrendo manutenção.

37. Continuidade de Negócios:

A empresa deverá possuir um Plano de Continuidade de Negócios, quando for previsto em

Contrato que a prestação do serviço não pode ser interrompida. Para isso deverá:

ter documento de BCP, alinhado com a necessidade do negócio do Itaú;

realizar testes de disaster recovery.

38. Inspeções periódicas de verificação de compliance aos requisitos de segurança:

A empresa deverá permitir e facilitar a realização de inspeções periódicas, pela área de

Segurança do Itaú, nas instalações que estiverem sendo usadas para atendimento aos serviços

contratados.

ANEXO A – SEGURANÇA PARA DESENVOLVIMENTO DE APLICAÇÕES

1. INTRODUÇÃO

Esta documentação lista as melhores práticas e recomendações para o desenvolvimento de

software seguro e que podem se relacionar com diversos tipos de aplicações: Mobile, WebApp,

WebService e Desktop. É recomendado aplicar os requisitos descritos em cada uma das

subseções seguintes para mitigar os riscos de segurança no desenvolvimento de aplicações.

As seções seguintes descrevem os métodos de prevenção para tais problemas.

2. ESCOPO

Não faz parte do escopo deste documento:

Descrever práticas que não produzam benefícios diretamente relacionados à segurança das

aplicações ou que visem outros objetivos tais como desempenho, robustez e usabilidade,

entre outros.

Detalhar exaustivamente o uso seguro de recursos, estruturas e comandos das diversas

linguagens de programação utilizadas no Itaú, embora casos especiais, normalmente

justificados por sua ampla utilização ou criticidade, possam ser explorados mais

extensamente.

3. DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS GERAIS

1. Criar e manter uma política de privacidade para o produto ou linha de serviço cobrindo

o uso de dados pessoais e disponibilize para o usuário, especialmente quando eles

fazem escolhas de consentimento.

2. O aplicativo deve gravar os arquivos que cria em um diretório diferente daquele em que

o código executável da aplicação é armazenado.

3. O aplicativo não deve usar cookies ou qualquer outra tecnologia web que recolha

informações de identificação do usuário, tais como listas extensas dos sites visitados

anteriormente, endereços de e-mail ou outras informações para identificar ou criar perfis

de usuários individuais.

4. O aplicativo não pode utilizar cookie persistente como mecanismo de coleta de dados

sensíveis e controle de sessão. Esse requisito garante que as informações do usuário

não serão armazenadas de forma irregular e insegura, podendo ser utilizada por

usuários maliciosos ou atacantes, e evitando possíveis problemas com usuários.

5. A opção autocomplete=off deve estar configurada em todos os formulários que solicitem

informações pessoais.

6. Os formulários de cadastro ou qualquer outro parâmetro enviado à aplicação devem ser

validados pela aplicação e não por meio de scripts presentes no próprio código html do

site.

7. Quando enviados segredos para endereços de e-mail, como um mecanismo de reset de

password. Use números randômicos limited time-only para reiniciar o acesso e envie

um e-mail de retorno assim que a senha for re-configurada. Cuidado ao permitir que


09/04/15 Pág: 18

usuários registrados mudem seus endereços de e-mail – envie uma mensagem para o

e-mail anterior antes de efetuar a mudança.

8. Certifique-se que o controle de acesso (ou autorização) é realizado em todos os passos

de um fluxo e não apenas no passo inicial de um processo.

9. Para evitar exploração de Clickjacking, aplicar o cabeçalho “X-Frame-Options:” com

valores DENY ou SAMEORIGIN que irão bloquear respectivamente framing ou framing

de sites de origens diferentes.

10. O mecanismo de gestão de senhas da aplicação deve ser capaz de reconhecer que o

usuário está tentando utilizar uma de suas senhas anteriores e deve impedir o usuário

de escolher tal senha. O administrador deve ter a possibilidade de especificar o número

de senhas expiradas que não devem ser escolhidas pelo usuário.

11. O aplicativo deve garantir a confidencialidade da conta e dos dados do usuário. A

aplicação deve garantir que quando uma tentativa de login for realizada utilizando um

nome de usuário inválido, ela não revelará se o usuário existe ou não.

12. O aplicativo deve garantir proteção contra bloqueio inadvertido de contas. Esse requisito

garante que as contas serão bloqueadas da forma correta, sob as circunstâncias

planejadas, e não em decorrência de um ataque.

13. Deve ser avaliado a possibilidade de execução de teste de turing (CAPTCHA) durante

o cadastro ou outras funcionalidades críticas em áreas não autenticadas da aplicação,

caso seja percebido anomalias no acesso como um número específico de cadastros da

mesma origem. Esse requisito garante que será possível diferenciar usuários e sistemas

automatizados durante a criação de um novo cadastro.

14. O aplicativo deve garantir a validade de um cadastro através da verificação da validade

do e-mail ou celular cadastrado pelo usuário. Esse requisito garante que após o

preenchimento do cadastro, será feita uma validação do endereço de e-mail ou número

de celular que foi cadastrado, que funcionará atrelado a um tempo determinado de

validade, que uma vez atingida, invalidará o cadastro.

15. Toda aplicação deve possuir controles de permissão para restrição de acesso, limitando

os acessos baseando-se na premissa do privilégio mínimo. Restrição dos direitos de

acesso a IDs de usuários privilegiados ao menor número de privilégios necessários para

desempenhar as responsabilidades.

16. O aplicativo deve garantir ID exclusivo para cada indivíduo que possua direito de acesso.

Não é permitido ID compartilhado ou ID genérico. Ao garantir que todos os usuários

sejam individualmente identificados, em vez de usar um ID para vários funcionários, uma

organização consegue manter a responsabilidade individual pelas ações e uma trilha de

auditoria eficaz por funcionário. Isso ajudará a apressar a resolução e a contenção de

problemas quando ocorrer mau uso ou tentativa mal-intencionada.

17. Toda aplicação deve garantir que uma conta com várias tentativas de acessos incorretas

em um pequeno espaço de tempo seja bloqueada por um tempo mínimo ou exigida outra

forma de confirmação de identidade. Se uma conta estiver bloqueada em função de uma

pessoa tentar continuamente adivinhar a senha, os controles para atrasar a reativação

dessas contas bloqueadas evitarão que o indivíduo mal-intencionado continue a tentar

adivinhar a senha.


09/04/15 Pág: 19

18. Não permita que o processo de login comece de uma página não criptografada. Sempre

inicie o processo de login de uma segunda página criptografa ou de um novo código de

sessão, para prevenir o roubo de credenciais ou da sessão, phishing e ataques de

fixação de sessão.

19. Considere gerar uma nova sessão após uma autenticação que obteve sucesso ou

mudança do nível de privilégio.

20. Use períodos de expiração de prazo que automaticamente realizam logout em sessões

inativas, bem como o conteúdo das informações que estão sendo protegidas.

21. Não exponha nenhum identificador de sessão ou qualquer parte válida das credenciais

em URLs e logs (não regrave ou armazene informações de senhas de usuários em logs).

22. Além de invalidar os tokens adequadamente (no lado do servidor), durante os principais

eventos do aplicativos, também é fundamental que os próprios tokens sejam gerados

corretamente. Eles devem ser suficientemente longos e complexos, e pseudoaleatórios,

de modo a ser resistente aos ataques de adivinhação\antecipação.

23. Nunca permitir contas padrão, as senhas padrão ou vazio, ou grupo de contas de acesso

ao sistema;

24. Utilizar a autenticação de dois fatores sempre que a informação que está sendo

manipulada é sensível e que o acesso pode ser concedido a partir de várias origens não

confiáveis;

25. Usar algoritmos de hash sobre a senha dos usuários antes de armazena-la.

26. Especifique o cabeçalho X-Content-Type-Options: nosniff para garantir que o

browser não tente detector um um Content-Type diferente o que foi enviado.

4. REVISÃO SEGURA DE CÓDIGO – REQUISITOS GERAIS

1. Deve ser tomado como base e guia para revisão e certificação de software a

metodologia ASVS (Application Security Verification Standard -2014) considerando o

nível 3 para os requisitos a serem verificados.

2. O código deve ser revisado com o intuito que sejam removidos componentes, plug-ins

e trechos desnecessários. Esses artefatos podem introduzir vulnerabilidades ao

software.

3. Aplicações que incluem códigos de terceiros devem incluir as versões mais recentes do

código, com todos os patches de segurança aplicados de acordo com o processo de

implantação aprovado.

4. O software, código ou componentes deve ser revisado a fim de entregar ao Banco um

produto livre de vulnerabilidades comuns, conforme especificado pelo Common

Vulnerabilities and Exposures (CVE®) - O padrão para nomes de vulnerabilidades de

segurança da informação que podem ser acessados em http://cve.mitre.org/.


produto livre de brechas conhecidas, tal como especificado na Common Weakness

Enumeration (CWE) - Um dicionário dos tipos de vulnerabilidades conhecidas que

podem ser acessadas em http://cwe.mitre.org/.

https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf

http://cve.mitre.org/

http://cwe.mitre.org/


09/04/15 Pág: 20


produto livre de qualquer tipo de agente malicioso, incluindo bombas lógicas,

ransonwares, spywares e trojan.


produto livre de credenciais hardcoded e chaves de criptografia em texto claro nas linhas

do código ou em arquivos de configuração.


produto livre de maintenance hooks (backdoors).


produto livre de códigos de depuração (debugging code) e flags.


produto livre de comentários desnecessários ou informação sensível nos comentários

do código.


produto livre de contas de testes antes do processo de implantação da aplicação em

produção.

5. DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS ESPECÍFICAS

5.1. PROTEÇAO PARA WEBSERVICES

As seguintes práticas não devem ser tomadas como únicos métodos para proteção de aplicações

baseadas em WebServices mas sim como complemento específico para esse tipo de tecnologia,

tome como referencia todas sessões desse documento para construção segura de uma aplicação

baseada em WebServices.

12. Considere usar apenas a chave de sessão de token ou API para manter o estado do

cliente em um cache do lado do servidor. Isto é diretamente equivalente à forma como

web apps normais fazem, e há uma razão para isso é moderadamente seguro.

13. Anti-replay. Atacantes vão copiar e colar uma sessão e tornar-se outra pessoa.

Considere o uso de uma chave de criptografia de tempo limitado, fechado contra a chave

de sessão de token ou API, data, hora e endereço IP de entrada. Em geral, implemente

alguma proteção de armazenamento do cliente local do token de autenticação para

mitigar ataques de repetição.

14. Proteja os métodos HTTP. Uma política ou controle de acesso pra determinando token

de sessão/API com acesso a uma coleção de recursos, usuário ou ação deve ser

definido para cada método HTTP.

15. Whitelist Metodos Permitidos. Da mesma forma que o requisito anterior é importante que

o serviço restrinja os métodos permitidos para determinada entidade, todos os outros

métodos devem retornar o código de resposta adequado (por exemplo, 403 Forbidden).

16. Proteja ações privilegiadas e coleções de recursos sensíveis. O token de sessão ou API

key devem ser enviados juntamente como parâmetro de cookie ou no body para garantir


09/04/15 Pág: 21

que recursos privilegiados ou ações sejam devidamente protegidos contra uso não

autorizado.

17. Web services precisam garantir que a saída enviada aos clientes é codificada para ser

consumida como dados e não como scripts. Isto torna-se muito importante quando os

clientes de web services usam a saída para renderizar páginas HTML, direta ou

indiretamente por meio de objetos AJAX.

18. A mesma questão acima é relevante quanto a JSON encoders que devem evitar

execução de código JavaScript no browser ou Node.js no servidor. No caso de XML

encoding deve sempre ser utilizado um XML serializer para garantir que o conteúdo

enviado ao browser é “parseável” e não contém injeção de XML.

19. Proteja ações privilegiadas e coleções de recursos sensíveis. O token de sessão ou API

key devem ser enviados juntamente como parâmetro de cookie ou no body para garantir

que recursos privilegiados ou ações sejam devidamente protegidos contra uso não

autorizado.

20. Log e conte falhas de validação de input, qualquer um pode executar chamadas no Web

Service, então considere implementar rate limiting para falhas na validação de input em

determinado período de tempo. Implemente esse controle parametrizável para

acompanhar a evolução do negócio.

21. É difícil de executar a maioria dos ataques se os valores permitidos apenas são true ou

false, um número, ou ainda um de um pequeno número de valores aceitáveis.

Especifique o tipo de dados de entrada o mais cedo possível.

22. Valide o Contente-Type. O cliente nunca deve assumir o Content-Type (ex.:

application/xml ou appication/json), mas sempre verifique se o cabeçalho Content-Type

e o conteúdo são do mesmo tipo. A falta de cabeçalho Content-Type ou um cabeçalho

Content-Type inesperado, deve resultar no servidor rejeitar o conteúdo com uma

resposta 406 Not Acceptable.

23. O servidor de autorização deve considerar a limitação do número de tokens de acesso

concedidos por usuário. Deve ser incluída uma quantidade entropia adequada nos

"códigos" de autorização. Um invasor pode esgotar o pool de "códigos" de autorização

direcionando repetidamente o navegador do usuário a solicitar autorização de "códigos"

ou tokens de acesso.

24. Log e conte falhas de validação de input, qualquer um pode executar chamadas no Web

Service, então considere implementar rate limiting para falhas na validação de input em

determinado período de tempo. Implemente esse controle parametrizável para

acompanhar a evolução do negócio.

5.2. PROTEÇÃO PARA APLICATIVOS MÓVEIS

As seguintes práticas não devem ser tomadas como únicos métodos para proteção de aplicações

baseadas em Mobile mas sim como complemento específico para esse tipo de tecnologia, tome

como referencia todas as sessões desse documento para construção segura de uma aplicação

baseada em Mobile.


09/04/15 Pág: 22

1. Não guarde senhas ou segredos no binário do aplicativo. Não use um segredo para

integração com a infraestrutura (como uma senha embutida no código). Binários de

aplicativos móveis podem ser facilmente baixados e sobrepujados por engenharia

reversa.

2. Não permitir o uso de versões com vulnerabilidades. Forçar atualização do aplicativo

quando funções críticas e bugs de segurança tiverem sido identificados e corrigidos.

3. Não autorizar código/app a executar como root/privilégios de administrador.

4. Devido a requisitos de uso off-line, podem ser solicitados a aplicativos móveis

autenticação local ou verificações de autorização no código do aplicativo móvel. Se este

for o caso, os desenvolvedores devem adicionar controles locais de verificação de

integridade dentro do código para detectar qualquer alteração não autorizada.

5. Autenticação persistente (Remember Me) funcionalidade implementada dentro de

aplicações móveis nunca devem guardar a senha de um usuário no dispositivo.

6. Sempre que possível, garantir que todas as solicitações de autenticação sejam

executadas no lado do servidor. Após a autenticação bem sucedida, os dados do

aplicativo serão carregado para o dispositivo móvel. Isso irá garantir que os dados do

aplicativo só estarão disponível após a autenticação bem-sucedida.

7. A aplicação deve forçar o fechamento de uma sessão inativa por determinado período

de tempo. Este período deve ser determinado de acordo com o negócio da aplicação.

8. O aplicativo mobile deve garantir que tokens de sessão de alta entropia e imprevisíveis

sejam implementados.

9. Toda aplicação deve garantir controle sobre número máximo de tentativas sem sucesso

de logins em um determinado período de tempo. O mecanismo de Identificação e

Autenticação deve permitir ao administrador a configuração do número máximo de

tentativas de login, configurável por utilizador ou por regra, dentro de um determinado

período de tempo.

10. Aplicações que possuam identificação ou autenticação implementadas com base em ID

de usuário, senha estática e dados pessoais de usuários, deverão garantir

codificação/criptografia em todos os campos sensíveis ou garantir o uso de one-time

cookie criptografado. Os cookies nunca poderão ser persistentes.

11. O aplicativo deve garantir a identificação e autenticação sempre que uma nova sessão

for estabelecida. A aplicação não deve armazenar senhas do usuário em cookies, scripts

client ou server-side, ou qualquer outra forma automatizada de login de usuário para que

o usuário não tenha que digitar sua senha de login, quando iniciar uma nova sessão.

12. Nunca armazene credenciais no sistema de arquivos do telefone. Forçar o usuário a se

autenticar usando um sistema web ou API de login padrão (HTTPS) para a aplicação

em cada abertura e garantir que o tempo limite de sessão está definido para atender os

requisitos mínimos de experiência do usuário.

13. Evite confiar exclusivamente em chaves de criptografia ou descriptografia codificados

ao armazenar os ativos de informações sensíveis.

14. Considere fornecer uma camada adicional de criptografia além de qualquer mecanismos

de encriptação padrão fornecido pelo sistema operacional.


09/04/15 Pág: 23

15. Proteja o binário da aplicação. Siga técnicas de codificação segura para os seguintes

componentes de segurança dentro do aplicativo móvel:

Controles de detecção para Jailbreak;

Controles de Checksum;

Controles de Certificados fixados;

Controle de detecção para Debugger;

Para mitigar outros riscos técnicos residuais expostos acima o ideal é que os desenvolvedores ou a

empresa terceira impeça de forma adequada que um usuário mal intencionado possa analisar o

aplicativo usando técnicas estáticas ou dinâmicas de análise e engenharia reversa; e o app deve ser

capaz de detectar durante o runtime que código foi adicionado ou alterado a partir do que ele conhece

sobre a sua própria integridade durante a compilação. Ele deve ser capaz de reagir de forma

adequada durante o runtime a uma violação da integridade do código.

5.3. PROTEÇAO PARA BANCO DE DADOS

1. Usar consultas parametrizadas para acesso as informações do banco de dados;

2. Utilizar validação de entrada e codificação de saída e assegurar a abordagem de meta

caracteres. Se houver falha, o comando não deverá ser executado no banco de dados;

3. Realizar a codificação (escaping) de meta caracteres em instruções SQL;

4. A aplicação deve usar o menor nível possível de privilégios ao acessar o banco de

dados;

5. Usar credenciais seguras para acessar o banco de dados;

6. Não incluir strings de conexão na aplicação. As strings de conexão devem estar em um

arquivo de configuração separado, armazenado em um sistema confiável e as

informações devem ser criptografadas;

7. Usar procedimentos armazenados (stored procedures) para abstrair o acesso aos dados

e permitir a remoção de permissões das tabelas no banco de dados;

8. Encerrar a conexão assim que possível;

9. Remover ou modificar senhas padrão de contas administrativas. Utilizar senhas

robustas (pouco comuns ou difíceis de deduzir) ou implementar autenticação de

múltiplos fatores. Desativar qualquer funcionalidade desnecessária no banco de dados,

como serviços não utilizados. Instalar o conjunto mínimo de componentes ou de opções

necessárias (redução da superfície de ataque);

10. Eliminar o conteúdo desnecessário incluído por padrão pelo fornecedor como esquemas

e bancos de dados de exemplo;

11. Desativar todas as contas criadas por padrão e que não sejam necessárias para suportar

os requisitos de negócio;


09/04/15 Pág: 24

12. A aplicação deve conectar-se ao banco de dados com diferentes credenciais de

segurança para cada tipo de necessidade como, por exemplo, usuário, somente leitura,

convidado ou administrador;

5.4. GERENCIAMENTO E EXECUÇÃO MALICIOSA DE ARQUIVOS

Em muitas plataformas, frameworks permitem o uso de referências a objetos externos, como

referências a URLs ou a arquivos de sistema. Quando o dado é insuficientemente verificado, isto

pode levar a uma inclusão arbitrária remota que será processada ou invocar um conteúdo hostil

pelo servidor web.

1. Usar um mapeamento indireto de objetos de referência. Por exemplo, quando um nome

de arquivo parcial é uma vez usado, considere um hash para a referência parcial.

2. Limitar os tipos de arquivos que podem ser enviados para aceitar somente os

necessários ao propósito do negócio;

3. Validar se os arquivos enviados são do tipo esperado, através da validação dos

cabeçalhos, pois, realizar a verificação apenas pela extensão não é suficiente;

4. Não salvar arquivos no mesmo diretório de contexto da aplicação Web. Os arquivos

devem ser armazenados no servidor de conteúdos ou no banco de dados.

Recomendamos a utilização de um Sandbox para essas finalidade;

5. Prevenir ou restringir o carregamento de qualquer arquivo que possa ser interpretado

ou executado pelo servidor Web;

6. Desativar privilégios de execução nos diretórios de armazenamento de arquivos;

7. Implantar o carregamento seguro nos ambientes UNIX por meio da montagem do

diretório de destino como uma unidade lógica, usando o caminho associado ou o

ambiente de “chroot”;

8. Ao referenciar arquivos, usar uma lista branca (whitelist) de nomes e de tipos de arquivos

permitidos. Realizar a validação do valor do parâmetro passado e caso ele não

corresponda ao que é esperado, rejeitar a entrada ou utilizar um valor padrão;

9. Não passar caminhos de diretórios ou de arquivos em requisições. Usar algum

mecanismo de mapeamento desses recursos para índices definidos em uma lista pré-

definida de caminhos;

10. Nunca enviar o caminho absoluto do arquivo para o lado cliente de uma aplicação;

11. Certificar-se de que os arquivos da aplicação e os recursos estão definidos somente

com o atributo de leitura;

12. Verificar os arquivos que os usuários submeterem através do mecanismo de

carregamento em busca de vírus e malwares;

5.4.1. EXEMPLOS:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360





09/04/15 Pág: 25


5.4.2. REFERENCIAS:

CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95

(Evalinjection), CWE-434 (Unrestricted file upload)

WASC Threat Classification:

http://www.webappsec.org/projects/threat/classes/os_commanding.shtml

OWASP Guide:

http://www.owasp.org/index.php/File_System#Includes_and_Remote_files

OWASP Testing Guide,

https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-

001)

5.5. FALHAS DE INJEÇÃO

1. Falhas de injeção acontecem quando os dados que o usuário passa de entrada são

enviados como parte de um comando ou consulta. Os atacantes confundem o

interpretador para o mesmo executar comandos manipulados enviando dados

modificados.

2. Evite o uso de interpretadores quando possível. Caso invoque um interpretador, o

método chave para evitar injeções está no uso de APIs seguras, como por exemplo,

queries parametrizadas e bibliotecas de mapeamento objeto relacional (ORM).

3. Se uma API parametrizada não estiver disponível, você deve cuidadosamente filtrar os

caracteres especiais utilizando a sintaxe para esse interpretador;

4. “Lista branca" ou validação de entrada positiva também é recomendada, mas não é uma

defesa completa já que muitas aplicações requerem caracteres especiais em suas

entradas. Se os caracteres especiais são exigidos, somente as abordagens 1. e 2. acima

tornarão a sua utilização segura;

5. Localize erros de canonicalização. As entradas devem ser decodificadas e convertidas

para a representação interna corrente antes de ser validada. Certifique-se que sua

aplicação não decodifica a mesma entrada duas vezes. Tais erros podem ser usados

para ultrapassar esquemas de whitelist pela introdução de entradas perigosas após sua

validação.

6. Quando há falha de validação, a aplicação deve rejeitar os dados fornecidos;

7. Validar dados provenientes de redirecionamentos. Os atacantes podem incluir conteúdo

malicioso diretamente para o alvo do mecanismo de redirecionamento, podendo assim

contornar a lógica da aplicação e qualquer validação executada antes do

redirecionamento;

8. Realizar o tratamento (sanitização), baseado em contexto, de todos os dados

provenientes de fontes não confiáveis usados para construir as consultas SQL;

9. Testar a utilização de funções escape no SGBD e em stored procedures caso não cause

overhead. Testes de desempenho antes da utilização dessas funções são altamente

recomendados.





https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001)



09/04/15 Pág: 26

10. Se a rotina de validação padrão não abordar as seguintes entradas, então elas devem

ser verificadas:

a) Verificar bytes nulos (%00);

b) Verificar se há caracteres de nova linha (%0d, %0a, \r, \n);

5.5.1. PROTEÇÃO – SQL INJECTION

1. Nunca execute queries formadas a partir de entradas ou parâmetros fornecidos pelo

usuário sem a devida verificação.

2. Valide e corrija o conteúdo de toda variável passada para o banco.

3. Verifique se a entrada tem o tipo de dado esperado.

4. Utilize sempre aspas para a entrada de dados passada ao banco.

5. Nunca disponibilizar parâmetros de usuário e senha do banco de dados em interface

com o usuário.

5.5.2. PROTEÇÃO – OS COMMAND INJECTION

1. Verificar toda entrada de dados.

2. Nunca passar entrada de dados não verificada como parâmetro para comandos de

sistema.

3. Nunca passar entrada de dados não verificada como parâmetro para pipes.

4. Verifique se a entrada de dados contém comandos de sistema.

5. Verificar todos os argumentos passados em system calls.

6. Utilizar sempre full pathnames.

7. Sempre configurar o diretório de trabalho corrente.

8. Verificar retorno de funções.

9. Garantir que as bibliotecas utilizadas sejam íntegras e livres de códigos maliciosos.

10. Utilizar sempre que possível; recursos de timeout em leituras e escritas de rede.

11. Verificar as informações retornadas na comunicação entre processos pais e filhos.

12. Utilizar mecanismos de autenticação/verificação na comunicação inter-processos.

13. Aplicações não devem ser executadas com privilégios de administrador. Se necessário,

isolar a porção crítica do código de forma que somente ela seja executada com privilégio

adicional. Se possível, adotar o conceito de Privilege Separation, onde porções de

código que demandam níveis de privilégios diferentes são executadas por processos

diferentes.

5.5.3. PROTEÇÃO – PATH TRAVERSAL/DISCLOSURE

1. Tratar a entrada em busca de meta caracteres que descrevem trilhas, como “.”, “/” e “\”.


09/04/15 Pág: 27

2. Procure utilizar trilhas absolutas e extensões hard-coded na aplicação.

5.5.4. EXEMPLOS

http://cwe.mitre.org/data/definitions/77.html




5.5.5. REFERÊNCIAS

CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection),

CWE-91 (XMLInjection), CWE-93 (CRLF Injection).



http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml

http://www.webappsec.org/projects/threat/classes/sql_injection.shtml

OWASP - Command Injection and OS Command Injection

https://www.owasp.org/index.php/OS_Command_Injection

https://www.owasp.org/index.php/Command_Injection

OWASP Code Review Guide:

http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection

OWASP – SQL Injection and Query Parameterization:

http://www.owasp.org/index.php/SQL_Injection

https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

OWASP Guide:

http://www.owasp.org/index.php/Guide_to_SQL_Injection

https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-006)

5.5.6. REVISÂO DE CÒDIGO

OWASP - Injection:

https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection

https://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection

https://www.owasp.org/index.php/Reviewing_Code_for_Data_Validation

5.6. FALHA DE AUTENTICAÇÃO E GERENCIAMENTO DE SESSÃO

Falhas nesta área geralmente envolvem a falha na proteção de credenciais e nos tokens da

sessão durante seu tempo de vida. Estas falhas podem estar ligadas à roubo de contas de

usuários ou administradores, contornando controles de autorização e de responsabilização,

causando violações de privacidade. As principais recomendações são descritas a seguir::

1. Um conjunto único de controles fortes de autenticação e gerenciamento de sessão. Tais

controles devem procurar:

a) Cumprir todos os requisitos de autenticação e gerenciamento de sessão definidos

no Padrão de Verificação de Segurança da Aplicação do OWASP (ASVS), áreas V2

(Autenticação) e V3 (Gerenciamento de Sessão);






http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml

http://www.webappsec.org/projects/threat/classes/sql_injection.shtml

https://www.owasp.org/index.php/OS_Command_Injection

https://www.owasp.org/index.php/Command_Injection

http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection

http://www.owasp.org/index.php/SQL_Injection

https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

http://www.owasp.org/index.php/Guide_to_SQL_Injection



https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection

https://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection

https://www.owasp.org/index.php/Reviewing_Code_for_Data_Validation

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project


09/04/15 Pág: 28

b) Ter uma interface simples para os desenvolvedores. Considere o ESAPI

Authenticator e User APIs como bons exemplos para simular, usar ou construir como

base;

2. Grande esforço também deve ser feito para evitar falhas de XSS (Cross Site Scripting)

que podem ser utilizados para roubar os IDs de sessão;

3. Todas as funções administrativas devem ser isoladas do acesso dos usuários comuns

e o gerenciamento de contas devem ser tão seguras quanto o mecanismo de

autenticação principal;

4. A funcionalidade de saída (logout) deve encerrar completamente a sessão ou conexão

associada;

5. A funcionalidade de saída (logout) deve estar disponível em todas as páginas que

requerem autenticação;

6. Gerar um novo identificador de sessão quando houver uma nova autenticação;

7. Não permitir conexões simultâneas com o mesmo identificador de usuário;

8. Gerar um novo identificador de sessão e desativar o antigo periodicamente. Isso pode

mitigar certos cenários de ataques de sequestro de sessão, quando o identificador de

sessão original for comprometido;

9. Considere o uso de uma chave de criptografia de tempo limitado, fechado contra a chave

de sessão de token ou API, data, hora e endereço IP de entrada. Em geral, implemente

alguma proteção de armazenamento do cliente local do token de autenticação para

mitigar ataques de repetição.

10. Não permita que o processo de login comece de uma página não criptografada. Sempre

inicie o processo de login de uma segunda página criptografa ou de um novo código de

sessão, para prevenir o roubo de credenciais ou da sessão, phishing e ataques de

fixação de sessão.

11. Considere gerar uma nova sessão após uma autenticação que obteve sucesso ou

mudança do nível de privilégio.

12. Use períodos de expiração de prazo que automaticamente realizam logout em sessões

inativas, bem como o conteúdo das informações que estão sendo protegidas.

13. Use somente funções de proteção secundárias eficientes, tais como perguntas e

respostas e reset de senha, pois estas credenciais são como senhas, nomes de usuários

e tokens. Aplique one-way hash nas respostas para prevenir ataques nos quais a

informação pode ser descoberta.

14. Configurar o atributo "secure" para cookies que trafegam informações sensíveis

incluindo cookies de sessão que são transmitidos através de uma conexão TLS;

15. Configurar os cookies com o atributo “HttpOnly”;

16. Assegure-se que todas as páginas tenham um link de logout. O logout deve destruir

todas as sessões e cookies de sessão. Considere os fatores humanos: não pergunte

por confirmação, pois usuários acabarão fechando a aba ou janela ao invés de sair com

sucesso.

https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API


09/04/15 Pág: 29

17. Não exponha nenhum identificador de sessão ou qualquer parte válida das credenciais

em URLs e logs (não regrave ou armazene informações de senhas de usuários em logs).

18. Verifique a senha antiga do usuário quando ele desejar mudar a senha.

19. Não confie em credenciais falsificáveis como forma de autenticação, como endereços

de IP ou máscaras de rede, endereço de DNS ou verificação reversa de DNS,

cabeçalhos da origem ou similares.

5.6.1. PROTEÇÃO - REPLAY DE SESSÃO

1. Gere identificadores de sessão que sejam difíceis de aplicar engenharia reversa,

criptografia forte e Message Digest robusto.

2. Preveja o uso de SSL na aplicação para proteção do cookie em seu trânsito entre o

navegador e o servidor. Garanta que todos os cookies tenham o campo secure

habilitado.

3. Preveja uma função de encerramento de sessão ou logout, que expire todos os cookies

e tokens de autenticação.

5.6.2. PROTEÇÃO – HIJACKING DE SESSÃO

1. Re-autentique usuário antes que ações críticas sejam executadas.

2. Se possível, tente vincular tokens de sessão a cada instância de navegador, por

exemplo, utilizando um hash do endereço MAC do computador cliente e o process id do

navegador.

3. Siga as contra medidas para prevenir ataques de Força Bruta e Replay de Sessão.

5.6.3. EXEMPLOS




5.6.4. REFERÊNCIAS

CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials),

CWE-311 (Reflection attack in an authentication protocol), others.


http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml

http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml

http://www.webappsec.org/projects/threat/classes/session_fixation.shtml

OWASP Guide:

http://www.owasp.org/index.php/Guide_to_Authentication

OWASP Code Review Guide:

http://www.owasp.org/index.php/Reviewing_Code_for_Authentication

http://www.owasp.org/index.php/Testing_for_authentication




http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml

http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml

http://www.webappsec.org/projects/threat/classes/session_fixation.shtml

http://www.owasp.org/index.php/Guide_to_Authentication

http://www.owasp.org/index.php/Reviewing_Code_for_Authentication

http://www.owasp.org/index.php/Testing_for_authentication


09/04/15 Pág: 30

RSNAKE01:

http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you

5.6.5. REVISÃO DE CÓDIGO

OWASP – Integridade de Sessão

https://www.owasp.org/index.php/Reviewing_Code_for_Session_Integrity

5.7. PROTEÇÃO CONTRA CROSS-SITE SCRIPTING (XSS)

O XSS permite que atacantes executem script no navegador da vítima, podendo sequestrar

sessões de usuários, desfigurar web sites, inserir conteúdo hostil, conduzir ataques de roubo de

informações pessoais - conhecido como phishing e obter o controle do navegador do usuário

usando um script mal intencionado, tal como um malware.

1. A opção apropriada é filtrar adequadamente todos os dados não confiáveis com base

no contexto HTML (corpo, atributo, JavaScript, CSS ou URL) no qual os dados serão

colocados;

2. “Lista branca" ou validação de entrada positiva também é recomendada pois ajuda a

proteger contra XSS, mas não é uma defesa completa, já que muitas aplicações

requerem caracteres especiais em sua entrada. Tal validação deve, tanto quanto

possível, validar o tamanho, caracteres, formato, e as regras de negócio sobre os dados

antes de aceitar a entrada;

3. Não use validação de blacklist para detectar XSS na entrada ou codificação de saída. A

procura ou troca de poucos caracteres ,"<" ">" e outros caracteres similares ou frases

como script, é fraco e tem sido explorado com sucesso. Mesmo uma tag <b> não

verificada é insegura em alguns contextos. O XSS possui um conjunto surpreendente

de variantes que torna simples ultrapassar validações de blacklist.

4. Implementar a Política de Segurança de Conteúdo (CSP): CSP é um mecanismo do

browser que permite criar recursos de whitelists para o lado do cliente utilizado pela

aplicação Web. Por exemplo: JavaScript, CSS, imagens e etc. CSP via cabeçalho HTTP

especial instrui o Browser para executar somente ou “renderizar” recursos desta fonte.

Por exemplo, o cabeçalho CSP abaixo permite conteúdo apenas de um domínio, o seu

domínio próprio e subdomínios: Content-Security-Policy: default-src 'self'

*.mydomain.com

5. Determinar se o sistema suporta conjuntos de caracteres estendidos UTF-8 e, em caso

afirmativo, validar após efetuar a descodificação UTF-8;

6. Validar todos os dados provenientes dos clientes antes do processamento, incluindo

todos os parâmetros, campos de formulários, conteúdos das URLs e cabeçalhos HTTP,

como, por exemplo, os nomes e os valores dos Cookies;

7. Cuidado com os erros de conversão. As entradas devem ser decodificadas e convertidas

para a representação interna corrente antes de ser validada. Certifique-se que sua

aplicação não decodifica a mesma entrada duas vezes. Tais erros podem ser usados

para ultrapassar esquemas de whitelist pela introdução de entradas perigosas após

serem checados.

http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you

https://www.owasp.org/index.php/Reviewing_Code_for_Session_Integrity


09/04/15 Pág: 31

5.7.1. EXEMPLOS




5.7.2. REFERÊNCIAS

CWE: CWE-79, Cross-Site scripting (XSS)


http://www.webappsec.org/projects/threat/classes/crosssite_scripting.shtml

OWASP – Cross Site Scripting:

http://www.owasp.org/index.php/Cross_Site_Scripting

OWASP – Testing for XSS,

http://www.owasp.org/index.php/Testing_for_Cross_site_scripting

OWASP Stinger Project (A Java EE validation filter)

http://www.owasp.org/index.php/Category:OWASP_Stinger_Project

OWASP PHP Filter Project:

http://www.owasp.org/index.php/OWASP_PHP_Filters

OWASP Encoding Project:

http://www.owasp.org/index.php/Category:OWASP_Encoding_Project

Klein, A., DOM Based Cross Site Scripting:

http://www.webappsec.org/projects/articles/071105.shtml

Fortify Javascript Hijacking:

http://james.padolsey.com/wp-content/uploads/javascript_hijacking.pdf

OWASP Enterprise Security API:

http://www.owasp.org/index.php/ESAPI


OWASP XSS

https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Scripting

5.8. REFERÊNCIA DIRETA INSEGURA A OBJETOS

Uma referência direta a um objeto acontece quando um desenvolvedor expõe uma referência a

um objeto de implementação interna, como por exemplo, um arquivo, diretório, registro na base

de dados ou chave, uma URL ou um parâmetro de um formulário. Um atacante pode manipular

diretamente referências a objetos para acessar outros objetos sem autorização, a não ser que

exista um mecanismo de controle de acesso.

1. Uso de referência indireta a objetos por usuário ou sessão. Isso impede que o atacante

atinja diretamente os recursos não autorizados. Por exemplo, em vez de utilizar a chave

de banco de dados do recurso, uma lista de seis recursos autorizados para o usuário

atual poderia utilizar os números de 1 a 6 para indicar qual valor o usuário selecionou.

A aplicação tem que mapear as referências indiretas por usuário de volta para a chave

do banco de dados real no servidor;




http://www.webappsec.org/projects/threat/classes/crosssite_scripting.shtml

http://www.owasp.org/index.php/Cross_Site_Scripting

http://www.owasp.org/index.php/Testing_for_Cross_site_scripting

http://www.owasp.org/index.php/Category:OWASP_Stinger_Project

http://www.owasp.org/index.php/OWASP_PHP_Filters

http://www.owasp.org/index.php/Category:OWASP_Encoding_Project

http://www.webappsec.org/projects/articles/071105.shtml

http://james.padolsey.com/wp-content/uploads/javascript_hijacking.pdf

http://www.owasp.org/index.php/ESAPI

https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Scripting


09/04/15 Pág: 32

2. Verificar o acesso. Cada utilização de uma referência direta a objeto de uma origem não

confiável deve incluir uma verificação de controle de acesso para garantir que o usuário

está autorizado para o objeto requisitado;

3. Garantir o controle de autorização em todas as requisições, inclusive em scripts do lado

servidor;

4. Se for permitida a existência de sessões autenticadas por longos períodos de tempo,

fazer a revalidação periódica da autorização do usuário para garantir que os privilégios

não foram modificados e, caso tenham sido, realizar o registro em log do usuário e exigir

nova autenticação;

5. Verificar a integridade de parâmetros para verificar quais parâmetros não foram

mudados. Essa verificação de integridade pode ser adicionada como um parâmetro

adicional utilizando criptografia ou técnicas de hashing;

6. A melhor solução é usar um valor de índice ou um mapa de referência para prevenir

ataques de manipulação de parâmetro.

7. Outra solução é verificar a integridade de parâmetros para verificar quais parâmetros

não foram mudados. Essa verificação de integridade pode ser adicionada como um

parâmetro adicional utilizando criptografia ou técnicas de hashing.

5.8.1. EXEMPLOS




5.8.2. REFERÊNCIAS

CWE: CWE-22 (Path Traversal), CWE-472 (Web Parameter Tampering)


http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml

http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml

OWASP Testing Guide:

https://www.owasp.org/index.php/Testing_for_business_logic

https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-

001)

GST Assist attack details:

http://www.abc.net.au/7.30/stories/s146760.htm

5.9. INFRAESTRUTURA E AMBIENTE

As recomendações primárias são para estabelecer todas as medidas:

1. Um processo de hardening recorrente que torne fácil e rápido de implantar outro

ambiente que está devidamente blindado. Ambientes de desenvolvimento, controle de

qualidade e produção devem ser todos configurados de forma idêntica (com senhas

diferentes usadas em cada ambiente). Este processo deve ser automatizado para

minimizar o esforço necessário para configurar um novo ambiente seguro;





http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml

https://www.owasp.org/index.php/Testing_for_business_logic



http://www.abc.net.au/7.30/stories/s146760.htm


09/04/15 Pág: 33

2. Certifique-se de que a plataforma de back-end (servidor) está funcionando com uma

configuração blindada (hardening) com os últimos patches de segurança aplicados no

SO, Web Server e outros componentes de aplicação.

3. Um processo para se manter a par e implantar todas as novas atualizações e correções

de software em tempo hábil e para cada ambiente. Este processo, deve incluir todas as

bibliotecas de código;

4. Uma arquitetura de aplicação forte que forneça a separação segura e eficaz entre os

componentes;

5. Considere executar varreduras e fazer auditorias periodicamente para ajudar a detectar

erros futuros de configuração ou correções ausentes;

6. Verificar o acesso. Cada utilização de uma referência direta a objeto de uma origem não

confiável deve incluir uma verificação de controle de acesso para garantir que o usuário

está autorizado para o objeto requisitado;

7. Criar uma Política de Controle de Acesso para documentar as regras de negócio da

aplicação, tipos de dados e critérios ou processos de autorização para que os acessos

possam ser devidamente concedidos e controlados. Isto inclui identificar requisitos de

acessos, tanto para os dados, como para os recursos do sistema;

8. As contas de serviço ou contas de suporte a conexões provenientes ou destinadas a

serviços externos devem possuir o menor privilégio possível;

9. Usar mecanismos de tratamento de erros que não mostrem informações de depuração

(debug) ou informações da pilha de exceção;

10. Usar mensagens de erro genéricas e páginas de erro personalizadas;

11. O tratamento de erros lógicos associados com os controles de segurança devem, por

padrão, negar o acesso;

12. Todos os controles de log devem ser implementados em um sistema confiável, por

exemplo, centralizar todo o processo no servidor;

13. Não armazenar informações sensíveis nos registros de logs, como detalhes

desnecessários do sistema, identificadores de sessão e senhas;

14. Remover aplicações desnecessárias e documentação do sistema que possam revelar

informações importantes para os atacantes;

15. Desativar a listagem de diretórios;

16. Definir quais métodos HTTP, GET ou POST, a aplicação irá suportar e se serão tratados

de modo diferenciado nas diversas páginas da aplicação;

17. Desativar as extensões HTTP desnecessárias como, por exemplo, o WebDAV. Caso

seja necessário o uso de alguma extensão HTTP com o propósito de suportar a

manipulação de arquivos, utilize um mecanismo de autenticação conhecido,

padronizado e bem testado;

18. Remover informações desnecessárias presentes nos cabeçalhos de resposta HTTP e

que podem estar relacionadas com o sistema operacional, versão do servidor web e

frameworks de aplicação;


09/04/15 Pág: 34

19. Servidores que recebem qualquer conexão da Internet, por exemplo http ou https, não

devem possuir aplicações ou acessos liberados para que esses efetuem conexões de

saída à Internet ou qualquer rede pública.

20. Deve ser implementada apenas uma função principal por componente, host virtual ou

host físico. Temos que garantir que servidores desempenharão somente uma função

principal da aplicação garantindo arquitetura “componentizada” e segurança em

camadas.

21. Levar em consideração a construção de um ambiente Sandbox (separado da infra em

produção) para integração de parceiros.

22. A arquitetura deve ser concebida de forma a garantir o deployment dinâmico e sem

interrupção do serviço durante os deliveries (exemplo: stick balance entre front-end e

back-end).

23. Garantir o isolamento de ambientes de desenvolvimento, homologação e produção, bem

como dos serviços corporativos. Isso quer dizer que os dados não podem ser

compartilhados entre as redes e tampouco transferidos.

24. Assegure que as comunicações entre os elementos da infraestrutura, como servidores

de web e sistemas de banco de dados, estão propriamente protegidas pelo uso de

camadas de transporte de segurança ou de criptografia de nível de protocolo para

credenciais e informações de valor intrínseco.

5.9.1. LOGS PARA AUDITORIA

1. As aplicações devem logar todos os eventos de segurança relevantes configurados pelo

administrador, para o seu próprio log seguro de auditoria/eventos ou serviço de logs

centralizado, ou transmitir esses dados de forma segura para uma facilidade de coleta

de auditoria externa;

2. A funcionalidade de auditoria usada pela aplicação deve permitir que o administrador

selecione os eventos que serão logados e a informação que será capturada sobre cada

evento;

3. A facilidade de auditoria utilizada pela aplicação deve anexar a identificação individual

do usuário causador - ou associado com a causa, do evento de auditoria para o registro

de auditoria daquele evento;

4. Os controles de acesso utilizados pela aplicação devem proibir ler, escrever, excluir,

executar, mover ou copiar os dados de auditoria de acesso da aplicação por processos

ou usuários não autorizados;

5. Todos os acessos aos relatórios devem ser registrados em log;

6. Todas as tentativas de login ao banco de dados, que falharem, deverão se logadas;

7. Uma das coisas mais importantes de se implantar é um log de auditoria para controles

de autenticação e autorização. Devemos ser capazes de responder facilmente as

seguintes questões: Quem logou, quando, qual origem, que transações foram

executadas e que dados foram acessados?

5.10. ARMAZENAMENTO CRIPTOGRÁFICO INSEGURO


09/04/15 Pág: 35

Os perigos da criptografia insegura, o uso de TLS/SSL e proteção de dados estão muito além

das informações descritas nesse documento. Dito isto, no mínimo, faça todas as

recomendações:

1. Considerando que você pretende proteger os dados de ameaças (como por exemplo,

ataque interno ou de usuário externo), tenha a certeza de criptografar todos os dados

sensíveis em repouso e em trânsito de uma forma que iniba estas ameaças;

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

possível. Dados que você não tem não podem ser roubados;

3. Certifique-se que o nível utilizado nos algoritmos e chaves são fortes, e que o

gerenciamento de chaves está aplicado adequadamente. Considere utilizar os módulos

criptográficos validados do FIPS-140-2;

4. Desabilite o auto completar em formulários de coleta de dados sensíveis e desabilite o

cache em páginas que contenham dados sensíveis;

5. Se a aplicação gerenciar um repositório de credenciais, esta deverá garantir que as

senhas são armazenadas na base de dados somente sob a forma de resumo/hash da

senha na forma de one-way salted hashes e que a tabela/arquivo que armazena as

senhas e as próprias chaves são manipuladas apenas pela aplicação;

6. Desativar a funcionalidade de auto completar nos formulários que contenham

informações sensíveis, inclusive no formulário de autenticação;

7. Desativar o cache realizado no lado cliente das páginas que contenham informações

sensíveis. O parâmetro Cache-Control: no-store, pode ser usado em conjunto com o

controle definido no cabeçalho HTTP “Pragma: no-cache”, que é menos efetivo, porém

compatível com HTTP/1.0;

8. Toda aplicação que requeira uso de criptografia deve garantir a validação de

certificados, recusando e não utilizando certificados inválidos, auto-assinados ou

revogados. As aplicações que requerem uso de criptografia devem garantir que as

validações e revogações dos certificados sejam sempre realizadas corretamente.

9. Não crie algoritmos de criptografia. Somente use algoritmos aprovados publicamente

como, AES, Criptografia de chaves publicas RSA, SHA-256 ou melhores para hash.

10. Não use algoritmos fracos, como MD5/SHA1. Use mecanismos mais seguros como

SHA-256 ou melhores.

11. Hashing não é criptografia. Se um atacante souber qual algoritmo de hashing está sendo

usado, ele pode fazer um ataque de força bruta para crackear o valor do hash.

12. Crie chaves offline e armazene chaves privadas e simétricas com extremo cuidado.

Nunca transmita chaves privadas ou simétricas em canais inseguros.

13. As chaves de criptografia das informações devem ser de propriedade e administração

do Itaú Unibanco.

5.10.1. EXEMPLOS






09/04/15 Pág: 36

5.10.2. REFERÊNCIAS

CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of

hard-coded Cryptographic key), CWE-325 (Missing Required Cryptographic Step)

OWASP:

https://www.owasp.org/index.php/Guide_to_Cryptography

OWASP Guide:

http://www.owasp.org/index.php/Insecure_Storage

https://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL%27s

PCI Data Security Standard:

https://www.pcisecuritystandards.org/pdfs/pci_dss_portuguese.pdf

Bruce Schneier:

http://www.schneier.com/

CryptoAPI Next Generation:

http://msdn2.microsoft.com/en-us/library/aa376210.aspx

5.11. FALHAS AO RESTRINGIR ACESSO A URLs

Segurança por obscuridade não é suficiente para proteger dados e funções sensíveis em uma

aplicação. Verificações de controles de acesso devem ser executadas antes de permitir uma

solicitação a uma função sensível, na qual garante que somente o usuário autorizado acesse a

respectiva função.

O principal método de ataque para esta vulnerabilidade é chamado de navegação forçada

(Forced browsing), na qual envolve técnicas de adivinhação de links (Guessing) e força bruta

(Brute force), para achar páginas desprotegidas.

É comum que aplicações utilizem códigos de controle de acesso por toda a aplicação, resultando

em um modelo complexo que dificulta a compreensão para desenvolvedores e especialistas em

segurança. Esta complexidade torna provável a ocorrência de erros e algumas páginas não

serão validadas, deixando a aplicação vulnerável.Veja abaixo alguns métodos para proteger a

aplicação:

1. Tendo o tempo para planejar a autorização criando uma matriz para mapear as regras

e as funções da aplicação é o passo primordial para alcançar a proteção contra acessos

não autorizados.

2. Aplicações web devem garantir controle de acesso em todas as URLs e funções de

negócio. Não é suficiente colocar o controle de acesso na camada de apresentação e

deixar a regra de negócio desprotegida. Também não é suficiente verificar uma vez o

usuário autorizado e não verificar novamente nos passos seguintes.

3. Garanta que a matriz do controle de acesso é parte do negócio, da arquitetura e do

design da aplicação

4. Garanta que todas URLs e funções de negócio são protegidas por um mecanismo de

controle de acesso efetivo que verifique as funções e direitos do usuário antes que

qualquer processamento ocorra.

5. Certifique-se que este processo é realizado em todos os passos do fluxo e não apenas

no passo inicial de um processo, pois pode haver vários passos a serem verificados.

https://www.owasp.org/index.php/Guide_to_Cryptography

http://www.owasp.org/index.php/Insecure_Storage

https://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL%27s

https://www.pcisecuritystandards.org/pdfs/pci_dss_portuguese.pdf

http://www.schneier.com/

http://msdn2.microsoft.com/en-us/library/aa376210.aspx


09/04/15 Pág: 37

6. Preste muita atenção em arquivos de includes/bibliotecas, especialmente se eles

possuem extensões executáveis como php. Sempre que possível, devem ser mantidos

fora da raiz web. Devem ser verificados se não estão sendo acessados diretamente, por

exemplo, verificando por uma constante que pode somente ser criada pelo requisitante

de uma biblioteca.

7. Não suponha que usuários não estarão atentos ao acessar URLs ou APIs escondidas

ou especiais. Sempre se assegure que ações com privilégios altos e administrativos

estarão protegidas.

8. Bloqueie acesso a todos os tipos de arquivos que a sua aplicação não deva executar.

Este filtro deve seguir a abordagem accept known good na qual apenas são permitidos

tipos de arquivos que a aplicação deva executar, como por exemplo .html .pdf, .php. Isto

irá bloquear qualquer tentativa de acesso a arquivos de log, arquivos XML, entre outros,

aos quais se espera nunca serem executados diretamente.

9. Configure uma política de segurança e habilite o Java Security Manager.

10. Mantenha o antivírus e as correções de segurança atualizadas para componentes como

processadores XML, processadores de texto, processadores de imagem, entre outros

que manipulam arquivos fornecidos por usuários.

5.11.1. EXEMPLOS





CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path),

CWE-285 (Missingor Inconsistent Access Control)


http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml

OWASP:

http://www.owasp.org/index.php/Forced_browsing

OWASP Guide:

http://www.owasp.org/index.php/Guide_to_Authorization

5.12. COMO EVITAR CROSS-SITE REQUEST FORGERY (CSRF)

Um ataque CSRF força o navegador logado da vítima a enviar uma requisição para uma

aplicação web vulnerável, que realiza a ação desejada em nome da vítima.

1. A prevenção de um CSRF geralmente requer a inclusão de um token imprevisível em

cada requisição HTTP. Tais tokens devem, no mínimo, ser únicos por sessão de usuário.

2. A opção preferida consiste em incluir um token único em um campo oculto. Isso faz com

que o valor seja enviado no corpo da requisição HTTP, evitando-se a sua inserção na

URL, que é mais propensa a exposição.




http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml

http://www.owasp.org/index.php/Forced_browsing

http://www.owasp.org/index.php/Guide_to_Authorization


09/04/15 Pág: 38

3. O token único pode ser incluído na própria URL, ou em parâmetros da URL. Contudo,

tal posicionamento corre um risco maior já que a URL será exposta ao atacante,

comprometendo assim o token secreto.

4. Exigir que o usuário autentique novamente, ou provar que são realmente um usuário

(por exemplo, através de CAPTCHA) também pode proteger contra CSRF.

5. Não use requisições GET (URLs) para dados sensíveis ou para realizar transações de

valores. Use somente métodos POST quando processar dados sensíveis do usuário.

Entretanto, a URL pode conter token randômico à medida que este cria uma URL única,

que torna o CSRF quase impossível de se realizar.

6. Verifique o Content-Type para proteger chamadas para funções AJAX e web services.

7. Mesmo o cabeçalho HTTP Referer podendo ser spoofado, verificar o Referer é uma boa

prática para detectar tentativas de hacking.

5.12.1. EXEMPLOS




CWE: CWE-352 (Cross-Site Request Forgery)

WASC Threat Classification: No direct mapping, but the following is a close match:


OWASP CSRF:

http://www.owasp.org/index.php/Cross-Site_Request_Forgery

OWASP Testing Guide:

https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005)

OWASP CSRF Guard and PHP CSRF Guard:

http://www.owasp.org/index.php/CSRF_Guard

http://www.owasp.org/index.php/PHP_CSRF_Guard

RSnake, "What is CSRF?":

http://ha.ckers.org/blog/20061030/what-is-csrf/

Microsoft, ViewStateUserKey details:

http://msdn2.microsoft.com/enus/library/ms972969.aspx#securitybarriers_topic2


OWASP – CSRF

https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Request_Forgery

5.13. REDIRECIONAMENTOS E ENCAMINHAMENTOS INVÁLIDOS

Evitar tais falhas é extremamente importante já que elas são o alvo favorito de phishers tentando

obter a confiança do usuário.Uso seguro de redirecionamentos e encaminhamentos pode ser feito

de várias formas:

1. Simplesmente evitar usá-los;




http://www.owasp.org/index.php/Cross-Site_Request_Forgery



http://www.owasp.org/index.php/CSRF_Guard

http://www.owasp.org/index.php/PHP_CSRF_Guard

http://ha.ckers.org/blog/20061030/what-is-csrf/

http://msdn2.microsoft.com/enus/library/ms972969.aspx%23securitybarriers_topic2

https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Request_Forgery


09/04/15 Pág: 39

2. Se forem usados, não envolva parâmetros de entrada do usuário no cálculo do destino.

Normalmente, isto pode ser feito;

3. Se os parâmetros de destino não podem ser evitados, tenha certeza que o valor

fornecido é válido, e autorizado para o usuário;

4. Recomenda-se que qualquer parâmetro de destino seja um valor mapeado, e não a URL

real ou parte dela, e que o código do lado do servidor traduza este mapeamento para a

URL de destino. Aplicações podem usar ESAPI para substituir o método sendRedirect()

para certificarem-se de que todos os destinos do redirecionamento são seguros.

5.13.1. EXEMPLOS

https://cwe.mitre.org/data/definitions/601.html


Open Redirect

https://www.owasp.org/index.php/Open_redirect

WASC Threat Classification: URL Redirector Abuse:

http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse

5.14. EVITANDO O BUFFER OVERFLOWS/OVERRUNS

Os itens a seguir devem ser observados quanto ao desenvolvimento de aplicações que irão lidar

com a leitura de dados e transferi-los para buffers de memória:

1. Use tratamento de buffers e funções de string seguras sempre que necessitar transferir

dados aos mesmos;

2. Ative qualquer defesa do sistema operacional para a pilha de execução, como a

prevenção de parâmetros da pilha de execução no Solaris, Data Execution Prevention

(DEP) no Windows e PaX para Linux;

3. Utilizar técnicas de endereço randômico (ASLR) para reduzir a possibilidade de

execução depois de um estouro de buffer;

4. Se C++ estiver sendo utilizado, sempre que possível substituir qualquer função de string

de baixo nível em C, por classes de string atualizadas em C++;

5. Verificar os limites do buffer caso as chamadas à função sejam realizadas em ciclos e

verificar se não há nenhum risco de ocorrer gravação de dados além do espaço

reservado;

6. Liberar a memória alocada de modo apropriado após concluir a sub-rotina

(função/método) e em todos pontos de saída;

7. Verificar o conteúdo, formato e tamanho da entrada de dados.

8. Ao fazer cópias de posições de memória, verificar se o destino é capaz de conter toda a

origem.

5.14.1. REFERENCIA

https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API


https://www.owasp.org/index.php/Open_redirect

http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse


09/04/15 Pág: 40

CWE-122 (Heap-based Buffer Overflow):


CWE-121 (Stack-based Buffer Overflow):


WASC - Buffer Overflow :

http://projects.webappsec.org/w/page/13246916/Buffer%20Overflow

OWASP Buffer Overflow:

https://www.owasp.org/index.php/Buffer_Overflow

OWASP - Testing Guide

https://www.owasp.org/index.php/Testing_for_Heap_Overflow

https://www.owasp.org/index.php/Testing_for_Stack_Overflow


OWASP - Code for Buffer Overruns and Overflows:

https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Overruns_and_Overflows

5.15. TRATAMENTO DE DADOS CONTRA INTEGER AND ARITHMETIC OVERFLOWS

Os itens a seguir devem ser observados no desenvolvimento de aplicativos que lidam com as

operações aritméticas e manipulação de números inteiros:

1. Validar os resultados que vão decidir sobre a alocação de memória para garantir que o

resultado está no intervalo, antes de realizar as alterações de memória;

2. Evitar utilizar tipos inteiros para os limites de matriz que definem o tamanho da memória

de dados;

3. Validar todas as operações que resultarão na identificação dos índices a serem

utilizados, para garantir que eles estão dentro da faixa esperada;

5.15.1. EXEMPLOS

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2192




CWE-190: Integer Overflow or Wraparound


OWASP - Integer overflow:

https://www.owasp.org/index.php/Integer_overflow

WASC Threat Classification – Integer Overflows:

http://projects.webappsec.org/w/page/13246946/Integer%20Overflows

Standard for Binary Floating-Point Arithmetic:

http://grouper.ieee.org/groups/754/



http://projects.webappsec.org/w/page/13246916/Buffer%20Overflow

https://www.owasp.org/index.php/Buffer_Overflow

https://www.owasp.org/index.php/Testing_for_Heap_Overflow

https://www.owasp.org/index.php/Testing_for_Stack_Overflow

https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Overruns_and_Overflows





https://www.owasp.org/index.php/Integer_overflow

http://projects.webappsec.org/w/page/13246946/Integer%20Overflows

http://grouper.ieee.org/groups/754/


09/04/15 Pág: 41

5.16. FORMAT SPRING NÃO CONTROLADA

Os itens a seguir devem ser observados no desenvolvimento de aplicações que irão lidar com a

formatação de sequências de entrada do usuário:

1. Definir a formatação de strings estáticas, sempre que possível, não confiando na entrada

do usuário;

2. Se a entrada do usuário é necessária, validar e restringir o tipo de dados inseridos,

considerando todos os caracteres de escape ou quaisquer outros símbolos indesejados

como inválidos;

3. Revisar dados de internacionalização provenientes de arquivos externos ou informações

de log sendo capturadas para entradas inválidas;

5.16.1. EXEMPLOS

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9157


CWE-134 - Uncontrolled Format String


OWASP Testing for Format String:

https://www.owasp.org/index.php/Testing_for_Format_String

OWASP Format string attack:

https://www.owasp.org/index.php/Format_string_attack

5.17. CONDIÇÕES DE CONCORRÊNCIA

Os itens a seguir devem ser observados quanto ao desenvolvimento de aplicativos que lidam

com recursos globais ou multithreading (multi-processamento), que podem acabar causando

condições de concorrência. Uma race condition ocorre quando um par de chamadas de rotina

em uma aplicação não executam em modo sequencial, sobrepujando as regras de negócio. É

um evento dentro do software que pode se tornar uma vulnerabilidade de segurança se as

chamadas não são executadas na ordem correta.

1. Evitar o máximo possível usar os recursos globais ou arquivos que também estão em

uso por outros aplicativos que você não tem controle;

2. Sempre bloquear ou impedir que outros acessem o recurso global no momento em que

sua aplicação irá lidar com ela;

3. Evitar criar arquivos temporários em pastas graváveis e impor o uso de nomes aleatórios

para a criação de tais arquivos;

4. Utilizar mecanismos de bloqueio para evitar requisições simultâneas para a aplicação

ou utilizar um mecanismo de sincronização para evitar condições de concorrência;

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9157


https://www.owasp.org/index.php/Testing_for_Format_String

https://www.owasp.org/index.php/Format_string_attack


09/04/15 Pág: 42

5. Implementar de alguma forma um mecanismo de bloqueio no código que altera ou lê

dados persistentes.

6. Criar checagens de sanidade no recurso bloqueado. Se não houver mecanismos de

bloqueio, usar flags para impor seu próprio esquema de bloqueio quando os recursos

estão sendo usados por outras threads em execução.

7. Garantir que o bloqueio ocorre antes da execução, ao invés de depois dela.


CWE-362- Concurrent Execution using Shared Resource with Improper Synchronization


CWE-364 – Signal Handler Race Condition


CWE-368 – Context Switching Race Condition


CWE-366 – Race Condition within a Thread


OWASP Testing Guide – Race Condititions:

https://www.owasp.org/index.php/Testing_for_Race_Conditions_%28OWASP-AT-010%29


OWASP Reviewing Code for Race Conditions:

https://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions

5.18. COMUNICAÇÕES INSEGURAS

A criptografia, geralmente TLS/SSL, deve ser usada em todas as conexões autenticadas,

especialmente páginas web com acesso via internet, mas também conexões com o backend. Os

itens a seguir devem ser observados quanto ao desenvolvimento de aplicativos que devem

enviar informações sobre a rede:

1. Evitar o uso de protocolos sem criptografia (SMTP, FTP, POP3, IMAP, SNMP e HTTP)

para enviar dados através da rede;

2. Usar métodos conhecidos de criptografia como SSL e TLS para a transmissão de

informações confidenciais, evitando criar seu próprio código de criptografia;

3. Utilizar um mecanismo de autenticação forte para a identificação de clientes e

servidores, para garantir a identidade de ambas as partes de ambos os lados. Se estiver

usando protocolos conhecidos como SSL ou IPSec, o protocolo em si já fornece os

meios para realizar essa autenticação, utilizar certificados;

4. Filtrar os parâmetros que contenham informações sensíveis, provenientes do “HTTP

referer”, nos links para sites externos;

5. Utilizar um padrão único de implementação TLS configurado de modo apropriado;





https://www.owasp.org/index.php/Testing_for_Race_Conditions_%28OWASP-AT-010%29

https://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions


09/04/15 Pág: 43

6. Quando ocorrer alguma falha nas conexões TLS, o sistema não deve fornecer uma

conexão insegura;

7. Os certificados TLS devem ser válidos, possuírem o nome de domínio correto, não

estarem expirados e serem instalados com certificados intermediários, quando

necessário;

8. Quando utilizar TLS/SSL, o faça para toda a sessão. Proteger somente as credenciais

de logon é insuficiente porque dados e informações da sessão também devem estar

criptografados. Garanta esse controle implementando o HSTS (HTTP Strict Transport

Security).

9. Assegure que as comunicações entre os elementos da infra-estrutura, como servidores

de web e sistemas de banco de dados, estão propriamente protegidas pelo uso de

camadas de transporte de segurança ou de criptografia de nível de protocolo para

credenciais e informações de valor intrínseco.

5.18.1. EXEMPLOS



http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html


CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of

hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step)

OWASP Testing Guide, Testing for SSL / TLS,

https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transp

ort_Layer_Protection_(OTG-CRYPST-001)

OWASP Guide:

http://www.owasp.org/index.php/Guide_to_Cryptography

Found stone - SSL Digger

http://www.mcafee.com/br/downloads/free-tools/ssldigger.aspx

https://tools.ietf.org/html/rfc6797



http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html

https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)

https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)



http://www.mcafee.com/br/downloads/free-tools/ssldigger.aspx

baseline fábrica de software e desenvolvimento

Documents