Desenvolvimento Seguro: OWASP

Prévia do material em texto

Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
2 
 
Tecnologia da Informação 
TEORIA 
Desenvolvimento seguro: OWASP 
 
 
SUMÁRIO 
 
1. DESENVOLVIMENTO SEGURO: OWASP...................................................................... 4 
1.1 OWASP TOP 10 ............................................................................................................... 4 
1.2 Melhores práticas de programação segura ...................................................................... 15 
1.2.1 Validação de Dados de Entrada ....................................................................................... 15 
1.2.2 Codificação de Dados de Saída ......................................................................................... 16 
1.2.3 Autenticação e Gerenciamento de Credenciais................................................................ 17 
1.2.4 Gerenciamento de sessões ............................................................................................... 20 
1.2.5 Controle de acessos .......................................................................................................... 22 
1.2.6 Práticas de Criptografia ................................................................................................... 24 
1.2.7 Tratamento de Erros e Log ............................................................................................. 24 
1.2.8 Proteção de Dados ........................................................................................................... 26 
1.2.9 Segurança nas comunicações ........................................................................................... 27 
1.2.10 Configuração do Sistema.............................................................................................. 28 
1.2.11 Segurança em Banco de Dados .................................................................................... 29 
1.2.12 Gerenciamento de Arquivos ........................................................................................ 30 
1.2.13 Gerenciamento de Memória ........................................................................................ 31 
1.2.14 Práticas Gerais de Codificação ..................................................................................... 32 
2. ESQUEMAS DE AULA ..................................................................................................... 37 
3. REFERÊNCIAS .................................................................................................................. 43 
 
 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
3 
A nossa aula é bem esquematizada, então para facilitar o seu acesso aos esquemas, você 
pode usar o seguinte índice: 
Esquema 1 – OWASP TOP 10. ................................................................................................. 11 
Esquema 2 – Validação dos Dados de Entrada. .................................................................................. 16 
Esquema 3 – Codificação de Dados de Saída. .................................................................................... 17 
Esquema 4 – Autenticação e Gerenciamento de Credenciais. ...................................................................... 19 
Esquema 5 – Gerenciamento de sessões. ........................................................................................... 21 
Esquema 6 – Controle de Acessos. ................................................................................................. 23 
Esquema 7 – Práticas de criptografia. ............................................................................................ 24 
Esquema 8 – Tratamento de Erros e Log. ........................................................................................ 25 
Esquema 9 – Proteção de Dados. ................................................................................................. 26 
Esquema 10 – Segurança nas comunicações. ...................................................................................... 27 
Esquema 11 – Configuração do Sistema. ......................................................................................... 29 
Esquema 12 – Segurança em bancos de dados. .................................................................................... 30 
Esquema 13 – Gerenciamento de Arquivos. ....................................................................................... 31 
Esquema 14 – Gerenciamento de Memória. ...................................................................................... 32 
Esquema 15 – Práticas Gerais de Codificação. ................................................................................... 33 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
4 
 
1. DESENVOLVIMENTO SEGURO: OWASP 
 
O Open Web Application Security Project (OWASP) é uma fundação sem fins 
lucrativos que trabalha para melhorar a segurança de softwares. Por meio de projetos de 
software de código aberto liderados pela comunidade, capítulos locais em todo o mundo, 
dezenas de milhares de membros e conferências educacionais e de treinamento líderes, a 
OWASP Foundation é a fonte para desenvolvedores e tecnólogos protegerem a web. 
 
1.1 OWASP TOP 10 
O OWASP TOP 10 é, sem dúvidas, uma das principais publicações da OWASP. Trata-se 
de uma listagem, atualizada frequentemente, que relaciona as vulnerabilidades mais críticas, 
comuns e perigosas em relação ao desenvolvimento de software web. 
O OWASP TOP 10 é um documento de conscientização padrão para desenvolvedores e 
segurança de aplicativos da web. Ele representa um amplo consenso sobre os riscos de 
segurança mais críticos para aplicativos da web. 
As empresas devem adotar este documento e iniciar o processo de garantir que suas 
aplicações web minimizem esses riscos. Usar o OWASP TOP 10 talvez seja o primeiro 
passo mais eficaz para mudar a cultura de desenvolvimento de software em sua organização 
para uma que produza um código mais seguro. 
 
DICA DO PROFESSOR!!! 
Muito do que consta nos documentos OWASP são listas de recomendações. Vou reproduzir 
algumas aqui, mas ressalto que é totalmente inviável fixar tudo. A minha sugestão é ter 
uma noção geral e “passar o olho” nos pontos mais detalhados. Por exemplo, vale conhecer 
bem quais os 10 riscos, mas não adianta tentar decorar todas as formas de prevenção. 
 
Vamos abordar os 10 riscos do maior para o menor: 
 A01:2021 – Quebra de Controle de Acesso (Broken Access Control): o controle 
de acesso impõe a política de modo que os usuários não possam agir fora de suas 
permissões pretendidas. As falhas normalmente levam à divulgação, modificação 
ou destruição de informações não autorizadas de todos os dados ou ao 
desempenho de uma função comercial fora dos limites do usuário. 
Como prevenir: 
o Exceto para recursos públicos, negar por padrão. 
o Implemente mecanismos de controle de acesso uma vez e reutilize-os em todo 
o aplicativo, incluindo a minimização do uso de Cross-Origin Resource Sharing 
(CORS). 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
5 
o Os controles de acesso ao modelo devem impor a propriedade do registro em 
vez de aceitar que o usuário possa criar, ler, atualizar ou excluir qualquer 
registro. 
o Os requisitos de limite de negócios de aplicativos exclusivos devem ser 
impostos por modelos de domínio. 
o Desative a lista de diretórios do servidor da web e certifique-se de que os•Evitar funções reconhecidamente vulneráveis;
•Liberar a memória alocada de modo apropriado.
Gerenciamento de Memória
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
33 
 Proteger as variáveis compartilhadas e os recursos contra acessos concorrentes 
inapropriados; 
 Instanciar explicitamente todas as variáveis e dados persistentes durante a 
declaração, ou antes da primeira utilização; 
 Quando a aplicação tiver que ser executada com privilégios elevados, aumentar os 
privilégios o mais tarde possível e revogá-los logo que seja possível; 
 Evitar erros de cálculo decorrentes da falta de entendimento da representação 
interna da linguagem de programação usada e de como é realizada a interação com 
os aspectos de cálculo numérico; 
 Não transferir, diretamente, dados fornecidos pelo usuário para qualquer 
função de execução dinâmica sem realizar o tratamento dos dados de modo 
adequado; 
 Restringir a geração e a alteração de código por parte dos usuários; 
 Revisar todas as aplicações secundárias, códigos e bibliotecas de terceiros para 
determinar a necessidade do negócio e validar as funcionalidades de segurança, uma 
vez que estas podem introduzir novas vulnerabilidades; 
 Implementar atualizações de modo seguro. Se a aplicação precisar realizar 
atualizações automáticas, utilizar mecanismos de assinatura digital para garantir a 
integridade do código e garantir que os clientes façam a verificação da assinatura 
após descarregarem. 
 
Esquema 15 – Práticas Gerais de Codificação. 
 
• Código testado, gerenciado e aprovado;
• Utilizar APIs para operações do sistema operacional;
• Utilizar mecanismos de verificação de integridade.
• Tratar condições de concorrência;
• Proteger variáveis compartilhadas.
• Instanciar explicitamente as variáveis;
• Tratar dados fornecidos pelo usuário;
• Revisar aplicações, códigos e bibliotecas de terceiros;
• Implementar atualizações de modo seguro.
Práticas Gerais de Codificação
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
34 
4- (FGV - 2017 - ALERJ - Especialista Legislativo - Tecnologia da Informação) 
A implementação de mecanismos de segurança é necessária para manter a 
confidencialidade, a integridade e a disponibilidade dos recursos de informação em sistemas 
de software. Sobre mecanismos de segurança para mitigar as ocorrências de 
vulnerabilidades em aplicações web, analise as afirmativas a seguir: 
I. As rotinas de validação de dados de entrada devem ser centralizadas nos componentes 
que rodam no navegador por meio do uso intensivo de JavaScript. 
II. Utilizar apenas pedidos POST para transmitir credenciais de autenticação. 
III. Ativar o cache do navegador para as páginas que contenham informações sensíveis. 
Está correto o que se afirma em: 
a) somente I; 
b) somente II; 
c) somente III; 
d) somente I e II; 
e) I, II e III. 
Resolução: 
I. Incorreto: O correto seria efetuar toda a validação dos dados em um sistema confiável. 
Por exemplo, centralizar todo o processo no servidor. 
II. Correto: Deve-se utilizar apenas requisições POST para transmitir credenciais de 
autenticação. 
III. Incorreto: O correto seria proteger contra acesso não autorizado todas as cópias 
temporárias ou registradas em cache que contenham dados sensíveis e estejam 
armazenadas no servidor. 
Gabarito: Letra B. 
 
5- (FCC - 2017 - TRE-PR - Técnico Judiciário - Programação de Sistemas) 
Considere os cuidados abaixo. 
I. Não aceite novos identificadores de sessão pré-configurados ou inválidos na URL ou em 
requisições. Isto é chamado de ataque de sessão fixada. Use somente mecanismos padrão 
para gerência de sessão. Não escreva ou use gerenciadores secundários de sessão em 
qualquer situação. 
II. Mantenha no código os cookies personalizados com propósito de autenticação de 
gerência de sessão, como funções ‘lembrar do meu usuário’. 
III. Use períodos de expiração de prazo que automaticamente geram logout em sessões 
inativas, bem como o conteúdo das informações que estão sendo protegidas. 
IV. Assegure-se que todas as páginas tenham um link de logout. O logout não deve destruir 
as sessões nem cookies de sessão. 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
35 
V. Use somente funções de proteção secundárias eficientes (perguntas e respostas, 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. 
São cuidados que corretamente evitam problemas de quebra de autenticação e 
gerenciamento de sessão em aplicações web, o que se afirma APENAS em 
a) I, II e III. 
b) I e IV. 
c) II, III e V. 
d) III e IV. 
e) I, III e V. 
Resolução: 
Vamos analisar cada um dos itens: 
I. Correto: O certo é gerar um novo identificador de sessão quando houver uma nova 
autenticação e não usar novos identificadores pré-configurados ou inválidos. Além disso, 
não permitir logins persistentes (sem prazo de expiração). 
II. Incorreto: O correto seria 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 
(session hijacking). 
III. Correto: O correto é estabelecer um tempo de expiração da sessão que seja o mais 
curto possível, baseado no balanceamento dos riscos e requisitos funcionais do negócio. 
IV. Incorreto: A funcionalidade de saída (logout) deve encerrar completamente a sessão 
ou conexão associada 
V. Correto: Esquemas de pergunta/resposta (pré-definidas) usadas para a redefinição da 
senha devem evitar ataques que lancem respostas aleatórias. 
Gabarito: Letra E. 
 
6- (PR-4 UFRJ - 2018 - UFRJ - Analista de Tecnologia da Informação) Assinale, 
dentre as alternativas a seguir, a que se refere corretamente à Configuração do Sistema para 
desenvolvimento seguro de software. 
a) Utilizar conexões TLS para todo conteúdo que requer acesso autenticado ou manutenção 
da confidencialidade das informações sensíveis. 
b) Não expor informações sensíveis nas respostas de erros, inclusive detalhes de sistema, 
identificadores de sessão ou informação da conta do usuário. 
c) Implementar um sistema de controle de mudanças para gerenciar e registrar as alterações 
no código, tanto do desenvolvimento, quanto dos sistemas em produção. 
d) Todos os números aleatórios, nomes de arquivos aleatórios, GUIDs aleatórios e strings 
aleatórias devem ser geradas usando um módulo criptográfico com gerador de números 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
36 
aleatórios aprovado somente se os valores aleatórios gerados forem impossíveis de serem 
deduzidos. 
e) Limitar o número de transações que um único usuário ou dispositivo pode executar em 
um determinado período de tempo. As transações por período de tempo devem estar acima 
da necessidade real do negócio, mas abaixo o suficiente para impedir ataques automatizados. 
Resolução: 
Vamos analisar onde se encaixa cada um dos itens em relação aos grupos de melhores 
práticas. 
a) Incorreto: Segurança nas Comunicações. 
b) Incorreto: Tratamento de Erros e Log. 
c) Correto: Configuração do Sistema. 
d) Incorreto: Práticas de Criptografia. 
e) Incorreto: Controle de Acessos. 
Gabarito: Letra C. 
 
 
7- (CESPE - 2016 - FUNPRESP-JUD - Analista - Tecnologia da Informação) 
Julgue o próximo item, relativo a desenvolvimento e qualidade de software. 
No que se refere a softwares, uma programação segura deve dispor de mecanismos que, em 
quaisquercircunstâncias, rejeitem a entrada de dados que contenham caracteres 
considerados potencialmente perigosos. 
Resolução: 
Não deve se rejeitar os dados em qualquer circunstância, mas sim implementados controles. 
Se qualquer caractere potencialmente perigoso precisa ser permitido na entrada de dados 
da aplicação, certificar-se de que foram implementados controles adicionais como 
codificação dos dados de saída, APIs especificas que fornecem tarefas seguras e trilhas de 
auditoria no uso dos dados pela aplicação. 
Gabarito: Errado. 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
37 
 
2. ESQUEMAS DE AULA 
 
 
OWASP TOP 10 
 
 
Validação dos Dados de Entrada 
 
 
Codificação de Dados de Saída 
 
 
 
A01:2021 – Quebra de Controle de Acesso (Broken Access Control): 
A02:2021 – Falhas Criptográficas (Cryptographic Failures): 
A03:2021 – Injeção (Injection): 
A04:2021 – Desing Inseguro (Insecure Desing): 
A05:2021 – Configuração Incorreta de Segurança (Security Misconfiguration): 
A06:2021 – Componentes Vulneráveis e Desatualizados (Vulnerable and Outdated Components): 
A07:2021 – Falhas de Identificação e Autenticação (Identification and Authentication Failures): 
A08:2021 – Falhas de Integridade de Dados e Software (Software and Data Integrity Failures): 
A09:2021 – Falhas em Monitoramento e Segurança de Logs (Security Logging and Monitoring 
Failures):
A10:2021 – Falsificação de Solicitação do Lado do Servidor (SSRF - Server-Side Request Forgery): 
• Validar em sistema confiável;
Classificar as fontes de dados como sendo confiáveis ou não;
• Validar os dados das fontes não confiáveis;
• Especificar o conjunto de caracteres apropriado;
• Em falha de validação rejeitar os dados fornecidos;
• Validar todos os dados provenientes dos clientes;
• Validar dados provenientes de relacionamentos.
• Validar tipos de dados esperados;
• Validar intervalo de dados;
• Validar o tamanho dos dados;
• Para caracteres potencialmente perigosos implemente controles adicionais.
Validação dos Dados de Entrada
•Efetuar codificação de dados em sistema confiável.
•Utilizar rotina padrão e testada;
•Realizar a codificação baseada em contexto;
•Tratar todos os dados de fontes não confiáveis.
Codificação de Dados de Saída
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
38 
Autenticação e Gerenciamento de Credenciais 
 
 
Gerenciamento de sessões 
 
•Requerer autenticação para recursos não públicos;
•Utilizar serviços de autenticação padronizados e testados.
•Utilizar implementação centralizada para autenticação.
•Separar a lógica de autenticação do recurso.
•Executar procedimentos em caso de falha.
•Assegurar funções administrativas e de gerenciamento.
•Senhas armazenadas em one-way salted hashes;
•Geração de hash em sistema confiável.
•Validar dados de autenticação somente ao final de todas as entradas;
•Mensagens de falha não devem indicar a parte incorreta;
•Utilizar apenas POST para transmitir credenciais;
•Trafegar senhas por conexões protegidas;
•Exigir requisitos de complexidade de senha;
•Exigir requisitos de comprimento de senha;
•A entrada da senha deve ser ocultada na tela do usuário;
•Desativar a conta após um número pré-definido de tentativas;
•Processos de redefinição devem exigir controles similares aos de criação.
•Esquemas de pergunta/resposta devem evitar ataques de respostas 
aleatórias;
•O tempo de validade das senhas e links temporários deve ser curto;
•Notificar o usuário quando a senha for reiniciada;
•Prevenir a reutilização de senhas;
•Desativar a funcionalidade de lembrar a senha;
•Modificar senhas e IDs definidos pelos fornecedores;
•Utilizar autenticação de múltiplos fatores para contas sensíveis.
•Verificar código de terceiros.
Autenticação e Gerenciamento de Credenciais
•Utilizar controles de sessão baseados em servidor ou framework.
•Criar identificadores com base em sistema confiável.
•Usar algoritmos conhecidos, padronizados e bem testados;
•Definir domínio e caminho para cookies.
•O logout deve encerrar completamente a sessão ou conexão;
•O logout deve estar disponível em todas as páginas com autenticação;
•O tempo de expiração da sessão deve ser o mais curto possível;
•Não permitir logins persistentes;
•Encerrar sessões antigas.
•Gerar novo identificador para novas sessões.
•Não permitir conexões simultâneas.
•Não expor os identificadores de sessão em URLs, mensagens de erro ou logs;
•Proteger dados do lado servidor.
•Gerar novo identificador de sessão e desativar antigo periodicamente;
•Utilizar mecanismos complementares ao gerenciamento de sessões para operações 
altamente sensíveis ou críticas.
•Configurar cookies: atributo "secure" e "HttpOnly".
Gerenciamento de Sessões
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
39 
Controles de Acesso 
 
 
Práticas de Criptografia 
 
 
Tratamento de Erros e Log 
 
 
• Usar apenas objetos confiáveis.
• Único componente para verificação de autorização de acesso;
• Negar todos os acessos caso perca acesso à configuração de 
segurança;
• Garantir controle de autorização em todas as requisições.
• Isolar da aplicação código com lógica privilegiada;
• Restringir acesso a: arquivos e outros recursos, URLs, funções 
protegidas, referências diretas a objetos, serviços, dados de 
aplicações, atributos e dados de usuário, configurações de segurança.
• Regras da apresentação devem coincidir com as do lado servidor;
• Limitar o número de transações;
• Implementar a auditoria das contas;
• Desativar contas não utilizadas; 
• Criar uma Política de Controle de Acesso.
Controle de Acessos
•Usar sistema confiável para funções de criptografia.
•A senha mestre deve ser protegida;
•Usar gerador de números aleatórios somente se os valores aleatórios gerados 
forem impossíveis de serem deduzidos;
•Estabelecer política e processo para o gerenciamento das chaves.
Práticas de Criptografia
•Não expor informações sensíveis nas repostas de erros;
•Não mostrar informações de depuração (debug);
•Mensagens de erro genéricas e páginas de erro personalizadas;
•Liberar memória de modo apropriado em condições de erro;
•Garantir que os logs armazenam eventos importantes;
•Restringir o acesso aos logs apenas para pessoal autorizado;
•Não armazenar informações sensíveis nos registros de logs.
•Registrar em log: falhas de validação, tentativas de autenticação, falhas de 
controle de acesso, eventos suspeitos, tetntativas de conexão, exceções lançadas, 
falhas em módulos de criptografia.
•Usar hash para verificar integridade do log.
Tratamento de Erros e Log
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
40 
Proteção de Dados 
 
 
Segurança nas comunicações 
 
 
Configurações do Sistema 
 
 
 
 
 
 
•Implementar política de privilégio mínimo;
•Proteger contra acesso não autorizado cópias temporárias ou em cache.
•Criptografar informações sensíveis;
•Proteger o código-fonte presente no servidor;
•Não armazenar informações confidenciais em texto claro;
•Não incluir informações sensíveis nos parâmetros HTTP GET.
•Desativar auto completar e cache de informações sensíveis.
Proteção de Dados
• Utilizar criptografia na transmissão de informações sensíveis.
• Os certificados TLS devem ser válidos;
• Utilizar conexões TLS para conteúdo sensível;
• Utilizar padrão TLS único;
• Especificar a codificação dos caracteres.
• Filtrar parâmetros que contenham informações sensíveis.
Segurança nas comunicações
•Servidores, frameworks e componentes devem estar na última versão 
aprovada,com atualizações mais recentes.
•Desativar a listagem de diretórios;
•Restringir, para o mínimo possível, os privilégios.
•Remover código-teste e funcionalidades desnecessárias em produção;
•Prevenir divulgação da estrutura de diretórios.
•Definir quais métodos HTTP a aplicação irá suportar;
•Remover informações desnecessárias dos cabeçalhos HTTP;
•Implementar sistema de gestão de ativos;
•Isolar ambiente de desenvolvimento e produção;
•Implementar um sistema de controle de mudanças.
Configuração do Sistema
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
41 
Segurança em Banco de Dados 
 
 
Gerenciamento de Arquivos 
 
 
Gerenciamento de Memória 
 
 
 
 
•Consultas parametrizadas fortemente tipadas;
•Validação de entrada e codificação de saída;
•Variáveis fortemente tipadas.
•Realizar escaping de meta caracteres.
•Aplicação com menor nível possível de privilégios;
•Encerrar a conexão assim que possível;
•Utilizar senhas robustas ou implementar autenticação de múltiplos 
fatores.
•Remover senhas padrão de contas administrativas;
•Desativar contas padrão;
•Diferentes credenciais para cada tipo de necessidade.
Segurança em Banco de Dados
•Não repassar dados fornecidos por usuários.
•Autenticação antes de carregar arquivos;
•Limitar tipos de arquivos enviados;
•Validar tipos esperados dos arquivos.
•Não salvar arquivos no diretório da aplicação;
•Desativar privilégios de execução nos diretórios;
•Não passar caminhos de arquivos em requisições;
•Não enviar caminho absoluto do arquivo;
•Arquivos da aplicação e recursos em modo somente leitura;
•Verificar arquivos submetidos (vírus e malwares).
Gerenciamento de Arquivos
•Controle de entrada/saída para dados não confiáveis;
•Verificar se o buffer é tão grande quanto o especificado.
•Verificar limites do buffer;
•Truncar strings de entrada para tamanho razoável;
•Liberar recursos explicitamente;
•Evitar funções reconhecidamente vulneráveis;
•Liberar a memória alocada de modo apropriado.
Gerenciamento de Memória
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
42 
Práticas Gerais de Codificação 
 
 
 
• Código testado, gerenciado e aprovado;
• Utilizar APIs para operações do sistema operacional;
• Utilizar mecanismos de verificação de integridade.
• Tratar condições de concorrência;
• Proteger variáveis compartilhadas.
• Instanciar explicitamente as variáveis;
• Tratar dados fornecidos pelo usuário;
• Revisar aplicações, códigos e bibliotecas de terceiros;
• Implementar atualizações de modo seguro.
Práticas Gerais de Codificação
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
43 
 
3. REFERÊNCIAS 
 
OWASP. Melhores Práticas de Codificação Segura OWASP Guia de Referência 
Rápida. Disponível em: . Acesso em: 21 mar. 2022. 
OWASP. OWASP Top 10:2021. Disponível em: . 
Acesso em: 21 mar. 2022. 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62metadados do arquivo (por exemplo, o .git) e os arquivos de backup não estejam 
presentes nas raízes da web (web roots). 
o Registrar falhas de controle de acesso e alertar os administradores quando 
apropriado (por exemplo, falhas repetidas). 
o Limite de taxa o acesso da API e do controlador para minimizar os danos do 
conjunto de ferramentas de ataque automatizado. 
o Os identificadores de sessão com estado devem ser invalidados no servidor após 
o logout. Os tokens JWT sem estado devem ter vida curta, para que a janela de 
oportunidade para um invasor seja minimizada. Para JWTs de longa duração, 
é altamente recomendável seguir os padrões OAuth para revogar o acesso. 
 
 A02:2021 – Falhas Criptográficas (Cryptographic Failures): a primeira coisa é 
determinar as necessidades de proteção dos dados em trânsito e armazenados. 
Além disso, é importante verificar se algum dado está sendo transmitido de forma 
não criptografada, com uso de algoritmo antigo ou fraco, com chave fraca ou 
qualquer elemento do processo de criptografia obsoleto. 
Como prevenir: 
o Classifique os dados processados, armazenados ou transmitidos por um 
aplicativo. Identifique quais dados são confidenciais de acordo com as leis de 
privacidade, requisitos regulamentares ou necessidades de negócios. 
o Não armazene dados confidenciais desnecessariamente. Descarte-o o mais 
rápido possível ou use tokenização compatível com PCI DSS ou mesmo 
truncamento. Os dados não retidos não podem ser roubados. 
o Certifique-se de criptografar todos os dados confidenciais armazenados. 
o Certifique-se de que algoritmos, protocolos e senhas de padrão forte e 
atualizados estejam em vigor; use o gerenciamento de senhas adequado. 
o Criptografe todos os dados em trânsito com protocolos seguros, como TLS com 
cifras de sigilo de encaminhamento (FS), priorização de cifras pelo servidor e 
parâmetros seguros. Aplique a criptografia usando diretivas como HTTP Strict 
Transport Security (HSTS). 
o Desative o armazenamento em cache para respostas que contenham dados 
confidenciais. 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
6 
o Aplique os controles de segurança necessários de acordo com a classificação de 
dados. 
o Não use protocolos legados, como FTP e SMTP, para transportar dados 
confidenciais. 
o Armazene senhas usando fortes funções de hash adaptáveis e saltadas com um 
fator de trabalho (fator de atraso), como Argon2, scrypt, bcrypt ou PBKDF2. 
o Os vetores de inicialização devem ser escolhidos de acordo com o modo de 
operação. Para muitos modos, isso significa usar um CSPRNG (gerador de 
números pseudo-aleatórios criptograficamente seguro). Para modos que 
requerem um nonce, o vetor de inicialização (IV) não precisa de um CSPRNG. 
Em todos os casos, o IV nunca deve ser usado duas vezes para uma chave fixa. 
o Sempre use criptografia autenticada em vez de apenas criptografia. 
o As chaves devem ser geradas de forma criptograficamente aleatória e 
armazenadas na memória como um array de bytes. Se uma senha for usada, ela 
deve ser convertida em uma chave por meio de uma função de derivação de chave 
de base de senha apropriada. 
o Certifique-se de que a aleatoriedade criptográfica seja usada quando apropriado 
e que não tenha sido usada uma semente de uma forma previsível ou com baixa 
entropia. A maioria das APIs modernas não exige que o desenvolvedor propague 
o CSPRNG para obter segurança. 
o Evite funções criptográficas e esquemas de preenchimento obsoletos, como 
MD5, SHA1, PKCS número 1 v1.5. 
o Verifique de forma independente a eficácia das configurações. 
 
 A03:2021 – Injeção (Injection): a aplicação é vulnerável pois não valida os 
dados fornecidos pelo usuário, permite consultas dinâmicas ou dados hostis 
em parâmetros de pesquisa. As injeções mais comuns são SQL, NoSQL, comando 
OS, Mapeamento Relacional de Objeto (ORM), LDAP e Linguagem de Expressão 
(EL) ou injeção de Biblioteca de Navegação de Gráfico de Objeto (OGNL). 
Como prevenir: 
o A opção preferida é usar uma API segura, que evita usar o interpretador 
inteiramente, fornece uma interface parametrizada ou migra para uma 
ferramenta de Mapeamento Relacional de Objeto (ORMs). 
o Use validação de entrada positiva ou "safelist" do lado do servidor. Esta não é 
uma defesa completa, pois muitos aplicativos requerem caracteres especiais, 
como áreas de texto ou APIs para aplicativos móveis. 
o Para quaisquer consultas dinâmicas residuais, escape os caracteres especiais 
usando a sintaxe de escape específica para esse interpretador.. 
o Use LIMIT e outros SQL de controle em consultas para evitar a divulgação em 
massa de registros no caso de injeção de SQL. 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
7 
 A04:2021 – Desing Inseguro (Insecure Desing): um design inseguro não pode 
ser corrigido por uma implementação perfeita, pois, por definição, os controles de 
segurança necessários nunca foram criados para a defesa contra ataques 
específicos. Um dos fatores que contribuem para um design inseguro é a falta de 
perfis de risco de negócios inerentes ao software ou sistema que está sendo 
desenvolvido e, portanto, a falha em determinar o nível de design de segurança 
necessário. 
Como prevenir: 
o Estabeleça e use um ciclo de vida de desenvolvimento seguro com profissionais 
de AppSec para ajudar a avaliar e projetar controles relacionados à segurança e 
privacidade. 
o Estabeleça e use bibliotecas de padrões de projeto seguros ou componentes de 
paved road prontos para usar. 
o Use Modelagem de Ameaças para autenticação crítica, controle de acesso, lógica 
de negócios e fluxos de chaves. 
o Integre a linguagem e os controles de segurança às histórias de usuários. 
o Integre verificações de plausibilidade em cada camada da sua aplicação (do front-
end ao back-end). 
o Escreva testes de unidade e integração para validar se todos os fluxos críticos 
são resistentes ao modelo de ameaça. Compile casos de uso de sucesso e casos de 
uso indevido para cada camada da sua aplicação. 
o Separe as camadas de nível no sistema e nas camadas de rede, dependendo das 
necessidades de exposição e proteção. 
o Separe os tenants de maneira robusta por design em todas as camadas. 
o Limite o consumo de recursos por usuário ou serviço. 
 
 A05:2021 – Configuração Incorreta de Segurança (Security Misconfiguration): 
a aplicação é vulnerável pois falta configuração correta, há ativação de recursos 
desnecessários, uso de contas padrão, desabilitação de recursos de segurança, 
diretivas de segurança não configuradas ou mesmo pelo software não está 
atualizado. Sem um processo de configuração de segurança de aplicações que seja 
integrado e repetível, os sistemas correm um risco maior. 
Como prevenir: 
o Um processo de proteção repetível torna mais rápido e fácil implantar outro 
ambiente que esteja devidamente bloqueado. Os ambientes de desenvolvimento, 
controle de qualidade e produção devem ser todos configurados de forma 
idêntica, com credenciais diferentes usadas em cada ambiente. Este processo 
deve ser automatizado para minimizar o esforço necessário para configurar um 
novo ambiente seguro. 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
8 
o Uma plataforma mínima sem recursos, componentes, documentação e outros 
desnecessários. Remova ou não instale recursos e estruturas não utilizados. 
o Uma tarefa para revisar e atualizar as configurações apropriadas para todas as 
notas de segurança, atualizações e patches como parte do processo de 
gerenciamento de patch (consulte A06: 2021-Componentes Vulneráveis e 
Desatualizados). Reviseas permissões de armazenamento em nuvem (por 
exemplo, S3 bucket permissions). 
o Uma arquitetura de aplicação segmentada fornece separação eficaz e segura 
entre componentes ou tenants, com segmentação, conteinerização ou grupos de 
segurança em nuvem (ACLs). 
o Envio de diretivas de segurança para clientes, por exemplo, Security Headers. 
o Um processo automatizado para verificar a eficácia das configurações em todos 
os ambientes. 
 
 A06:2021 – Componentes Vulneráveis e Desatualizados (Vulnerable and 
Outdated Components): a aplicação é vulnerável pois não se sabe as versões dos 
componentes que se usa ou o software está sem suporte e desatualizado. 
Como prevenir: 
o Remova dependências não utilizadas, recursos, componentes, arquivos e 
documentação desnecessários. 
o Atualizar continuamente um inventário com as versões dos componentes do 
lado do cliente e do lado do servidor (por exemplo, estruturas, bibliotecas) e suas 
dependências usando ferramentas como versions, OWASP Dependency Check, 
retire.js, etc. Monitore continuamente fontes como Common Vulnerability and 
Exposures (CVE) e National Vulnerability Database (NVD) para 
vulnerabilidades nos componentes. Use ferramentas de análise de composição 
de software para automatizar o processo. Inscreva-se para receber alertas de e-
mail sobre vulnerabilidades de segurança relacionadas aos componentes que 
você usa. 
o Obtenha componentes apenas de fontes oficiais por meio de links seguros. 
Prefira pacotes assinados para reduzir a chance de incluir um componente 
malicioso modificado (consulte A08: 2021-Software e Falhas de Integridade de 
Dados). 
o Monitore bibliotecas e componentes sem manutenção ou que não criem patches 
de segurança para versões anteriores. Se o patch não for possível, considere 
implantar um patch virtual para monitorar, detectar ou proteger contra o 
problema descoberto. 
 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
9 
 A07:2021 – Falhas de Identificação e Autenticação (Identification and 
Authentication Failures): a confirmação da identidade do usuário, 
autenticação e gerenciamento de sessão é fundamental para proteger contra 
ataques relacionados à autenticação. Caso contrário, facilita-se os ataques 
automatizados, de força bruta e por senha padrão. 
Como prevenir: 
o Sempre que possível, implemente a autenticação multifator para evitar ataques 
automatizados de preenchimento de credenciais, força bruta e reutilização de 
credenciais roubadas. 
o Não envie ou implante com credenciais padrão, principalmente para usuários 
administradores. 
o Implemente verificações de senhas fracas, como testar senhas novas ou alteradas 
na lista das 10.000 piores senhas. 
o Alinhe as políticas de comprimento, complexidade e rotação de senha com as 
diretrizes do Instituto Nacional de Padrões e Tecnologia (NIST) 800-63b na 
seção 5.1.1 para Segredos Memorizados ou outras políticas de senha modernas 
baseadas em evidências. 
o Garanta que os caminhos de registro, recuperação de credenciais e API sejam 
protegidos contra ataques de enumeração de conta usando as mesmas 
mensagens para todos os resultados. 
o Limite ou retarde cada vez mais as tentativas de login com falha, mas tome 
cuidado para não criar um cenário de negação de serviço. Registre todas as falhas 
e alerte os administradores quando forem detectados preenchimento de 
credenciais, força bruta ou outros ataques. 
o Use um gerenciador de sessão integrado, seguro e do lado do servidor que gera 
um novo ID de sessão aleatório com alta entropia após o login. O identificador 
de sessão não deve estar no URL, ser armazenado com segurança e invalidado 
após o logout, inatividade e tempos limites absolutos. 
 
 A08:2021 – Falhas de Integridade de Dados e Software (Software and Data 
Integrity Failures): as falhas de integridade de software e dados estão relacionadas 
a código e infraestrutura que não protegem contra violações de integridade. 
Um exemplo disso é quando um aplicativo depende de plugins, bibliotecas ou 
módulos de fontes não confiáveis, repositórios e redes de entrega de conteúdo 
(CDNs). 
Como prevenir: 
o Use assinaturas digitais ou mecanismos semelhantes para verificar se o software 
ou os dados são da fonte esperada e não foram alterados. 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
10 
o Garanta que bibliotecas e dependências, como npm ou Maven, estejam 
consumindo repositórios confiáveis. Se você tiver um perfil de risco mais alto, 
considere hospedar um repositório interno em boas condições que seja 
verificado. 
o Certifique-se de que uma ferramenta de segurança da cadeia de suprimentos de 
software, como OWASP Dependency Check ou OWASP CycloneDX, seja 
usada para verificar se os componentes não contêm vulnerabilidades conhecidas 
o Certifique-se de que haja um processo de revisão para alterações de código e 
configuração para minimizar a chance de que código ou configuração mal-
intencionados possam ser introduzidos em seu pipeline de software. 
o Certifique-se de que seu pipeline de CI/CD tenha segregação, configuração e 
controle de acesso adequados para garantir a integridade do código que flui 
pelos processos de compilação e implantação. 
o Certifique-se de que os dados serializados não assinados ou não criptografados 
não sejam enviados para clientes não confiáveis sem alguma forma de verificação 
de integridade ou assinatura digital para detectar adulteração ou repetição dos 
dados serializados 
 
 A09:2021 – Falhas em Monitoramento e Segurança de Logs (Security Logging 
and Monitoring Failures): sem registro e monitoramento, as violações não 
podem ser detectadas. 
Como prevenir: 
o Garanta que todas as falhas de login, controle de acesso e validação de entrada 
do lado do servidor possam ser registradas com contexto de usuário suficiente 
para identificar contas suspeitas ou maliciosas e mantidas por tempo suficiente 
para permitir análises forenses atrasadas. 
o Certifique-se de que os logs sejam gerados em um formato que as soluções de 
gerenciamento de log possam consumir facilmente. 
o Certifique-se de que os dados de log sejam codificados corretamente para evitar 
injeções ou ataques nos sistemas de log ou monitoramento. 
o Garanta que as transações de alto valor tenham uma trilha de auditoria com 
controles de integridade para evitar adulteração ou exclusão, como tabelas de 
banco de dados somente anexadas ou similares. 
o As equipes de DevSecOps devem estabelecer monitoramento e alertas eficazes 
para que atividades suspeitas sejam detectadas e respondidas rapidamente. 
o Estabeleça ou adote um plano de resposta e recuperação de incidentes, como o 
Instituto Nacional de Padrões e Tecnologia (NIST) 800-61r2 ou posterior. 
 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
11 
 A10:2021 – Falsificação de Solicitação do Lado do Servidor (SSRF - Server-
Side Request Forgery): as falhas do SSRF ocorrem sempre que um aplicativo da 
Web está buscando um recurso remoto sem validar a URL fornecida pelo 
usuário. Ele permite que um invasor force o aplicativo a enviar uma solicitação 
criada para um destino inesperado, mesmo quando protegido por um firewall, VPN 
ou outro tipo de lista de controle de acesso à rede (ACL). 
Como prevenir: 
o Os desenvolvedores podem impedir o SSRF implementando alguns ou todos os 
seguintes controles de defesa em profundidade: 
Da camada de rede 
o Segmente a funcionalidade de acesso remoto a recursos em redes separadas para 
reduzir o impacto do SSRF 
o Aplique políticas de firewall “negar por padrão” ou regras de controle de acesso 
à rede para bloqueartodo o tráfego de intranet, exceto o essencial. 
 
Da camada de aplicação: 
o Higienize e valide todos os dados de entrada fornecidos pelo cliente 
o Aplique o esquema de URL, a porta e o destino com uma lista de permissões 
positiva 
o Não envie respostas brutas aos clientes 
o Desabilitar redirecionamentos HTTP 
o Esteja ciente da consistência do URL para evitar ataques como religação de 
DNS e condições de corrida "tempo de verificação, tempo de uso" (TOCTOU) 
Em resumo, 
 
Esquema 1 – OWASP TOP 10. 
A01:2021 – Quebra de Controle de Acesso (Broken Access Control): 
A02:2021 – Falhas Criptográficas (Cryptographic Failures): 
A03:2021 – Injeção (Injection): 
A04:2021 – Desing Inseguro (Insecure Desing): 
A05:2021 – Configuração Incorreta de Segurança (Security Misconfiguration): 
A06:2021 – Componentes Vulneráveis e Desatualizados (Vulnerable and Outdated Components): 
A07:2021 – Falhas de Identificação e Autenticação (Identification and Authentication Failures): 
A08:2021 – Falhas de Integridade de Dados e Software (Software and Data Integrity Failures): 
A09:2021 – Falhas em Monitoramento e Segurança de Logs (Security Logging and Monitoring 
Failures):
A10:2021 – Falsificação de Solicitação do Lado do Servidor (SSRF - Server-Side Request Forgery): 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
12 
1- (CESPE / CEBRASPE - 2021 - SEFAZ-CE - Auditor Fiscal de Tecnologia da 
Informação da Receita Estadual) A respeito de autenticação de dois fatores e OWASP 
Top 10, julgue o item a seguir. 
A inadequada configuração de segurança, um dos riscos da OWASP Top 10, pode ocorrer 
em qualquer nível de serviço de uma aplicação; em razão disso, o uso de scanners e testes 
automatizados é ineficaz na tarefa de detectar falhas de configuração. 
Resolução: 
Se a configuração está inadequada, o uso de scanners e testes automatizados será eficaz 
justamente para tentar descobrir as inadequações. 
Gabarito: Errado. 
 
2- (CESPE / CEBRASPE - 2021 - SEFAZ-AL - Auditor Fiscal de Finanças e 
Controle de Arrecadação da Fazenda Estadual) A respeito de MPS/BR, OWASP e 
criptografia, julgue o próximo item. 
De acordo com a OWASP TOP 10 2021, para o risco design inseguro, são medidas de 
prevenção para o desenvolvimento seguro o uso da modelagem de ameaças para 
autenticações críticas, controle de acesso e lógica de negócios. 
Resolução: 
As medidas de prevenção do design inseguro incluem: 
 Estabeleça e use um ciclo de vida de desenvolvimento seguro com profissionais de 
AppSec para ajudar a avaliar e projetar controles relacionados à segurança e 
privacidade. 
 Estabeleça e use bibliotecas de padrões de projeto seguros ou componentes de paved 
road prontos para usar. 
 Use Modelagem de Ameaças para autenticação crítica, controle de acesso, lógica de 
negócios e fluxos de chaves. 
 Integre a linguagem e os controles de segurança às histórias de usuários. 
 Integre verificações de plausibilidade em cada camada da sua aplicação (do front-
end ao back-end). 
 Escreva testes de unidade e integração para validar se todos os fluxos críticos são 
resistentes ao modelo de ameaça. Compile casos de uso de sucesso e casos de uso 
indevido para cada camada da sua aplicação. 
 Separe as camadas de nível no sistema e nas camadas de rede, dependendo das 
necessidades de exposição e proteção. 
 Separe os tenants de maneira robusta por design em todas as camadas. 
 Limite o consumo de recursos por usuário ou serviço. 
Gabarito: Certo. 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
13 
3- (CESPE / CEBRASPE - 2021 - SERPRO - Analista - Especialização: 
Desenvolvimento de Sistemas) No que se refere a autenticação e riscos de segurança, 
julgue o item subsequente. 
Quanto aos riscos de segurança derivados da exposição de dados sensíveis contidos na lista 
OWASP Top 10, é recomendável que o tráfego de dados confidenciais seja criptografado e 
que o seu armazenamento interno seja feito sem criptografia, de modo a viabilizar as funções 
de auditoria dos sistemas. 
Resolução: 
A recomendação para prevenir a exposição de dados confidenciais é justamente não os 
armazenar desnecessariamente. 
São recomendações para prevenir falhas criptográficas: 
 Classifique os dados processados, armazenados ou transmitidos por um aplicativo. 
Identifique quais dados são confidenciais de acordo com as leis de privacidade, 
requisitos regulamentares ou necessidades de negócios. 
 Não armazene dados confidenciais desnecessariamente. Descarte-o o mais 
rápido possível ou use tokenização compatível com PCI DSS ou mesmo 
truncamento. Os dados não retidos não podem ser roubados. 
 Certifique-se de criptografar todos os dados confidenciais armazenados. 
 Certifique-se de que algoritmos, protocolos e senhas de padrão forte e atualizados 
estejam em vigor; use o gerenciamento de senhas adequado. 
 Criptografe todos os dados em trânsito com protocolos seguros, como TLS com 
cifras de sigilo de encaminhamento (FS), priorização de cifras pelo servidor e 
parâmetros seguros. Aplique a criptografia usando diretivas como HTTP Strict 
Transport Security (HSTS). 
 Desative o armazenamento em cache para respostas que contenham dados 
confidenciais. 
 Aplique os controles de segurança necessários de acordo com a classificação de 
dados. 
 Não use protocolos legados, como FTP e SMTP, para transportar dados 
confidenciais. 
 Armazene senhas usando fortes funções de hash adaptáveis e saltadas com um fator 
de trabalho (fator de atraso), como Argon2, scrypt, bcrypt ou PBKDF2. 
 Os vetores de inicialização devem ser escolhidos de acordo com o modo de operação. 
Para muitos modos, isso significa usar um CSPRNG (gerador de números pseudo-
aleatórios criptograficamente seguro). Para modos que requerem um nonce, o vetor 
de inicialização (IV) não precisa de um CSPRNG. Em todos os casos, o IV nunca 
deve ser usado duas vezes para uma chave fixa. 
 Sempre use criptografia autenticada em vez de apenas criptografia. 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
14 
 As chaves devem ser geradas de forma criptograficamente aleatória e armazenadas 
na memória como um array de bytes. Se uma senha for usada, ela deve ser convertida 
em uma chave por meio de uma função de derivação de chave de base de senha 
apropriada. 
 Certifique-se de que a aleatoriedade criptográfica seja usada quando apropriado e 
que não tenha sido usada uma semente de uma forma previsível ou com baixa 
entropia. A maioria das APIs modernas não exige que o desenvolvedor propague o 
CSPRNG para obter segurança. 
 Evite funções criptográficas e esquemas de preenchimento obsoletos, como MD5, 
SHA1, PKCS número 1 v1.5. 
 Verifique de forma independente a eficácia das configurações. 
Gabarito: Errado. 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
15 
1.2 Melhores práticas de programação segura 
Uma das principais publicações da OWASP é o documento de Melhores Práticas de 
Programação Segura OWASP – Guia de Referência Básica. Este documento apresenta 
recomendações em formas de listas de verificações, que podem ser integradas no ciclo de 
desenvolvimento de aplicações, permitindo reduzir as vulnerabilidades mais comuns em 
aplicações web. 
 
DICA DO PROFESSOR!!! 
O Guia de Referência Básica é um documento curto (21 páginas), contudo é uma lista de 
recomendações. Por isso, é totalmente inviável fixar tudo. Vou reproduzir aqui essas 
recomendações, mas ressalto que o mais produtivo a se fazeré a leitura de “vez em quando” 
dessas recomendações. 
 
1.2.1 Validação de Dados de Entrada 
A lista de verificação é: 
 Efetuar toda a validação dos dados em um sistema confiável. Por exemplo, 
centralizar todo o processo no servidor; 
 Identificar todas as fontes de dados e classificá-las como sendo confiáveis ou não. 
Em seguida, validar os dados provenientes de fontes nas quais não se possa 
confiar; 
 A rotina de validação de dados de entrada deve ser centralizada na aplicação; 
 Especificar o conjunto de caracteres apropriado, como UTF-8, para todas as 
fontes de entrada de dados; 
 Codificar os dados para um conjunto de caracteres comuns antes da validação; 
 Quando há falha de validação, a aplicação deve rejeitar os dados fornecidos; 
 Determinar se o sistema suporta conjuntos de caracteres estendidos UTF-8, 
em caso afirmativo, validar após efetuar a descodificação UTF-8; 
 Validar todos os dados provenientes dos clientes antes do processamento, 
incluindo todos os parâmetros, campos de formulário, conteúdos das URLs e 
cabeçalhos HTTP; 
 Verificar se os valores de cabeçalho, tanto das requisições, como das respostas, 
contêm apenas caracteres ASCII; 
 Validar dados provenientes de redirecionamentos; 
 Validar tipos de dados esperados; 
 Validar intervalo de dados; 
 Validar o tamanho dos dados; 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
16 
 Validar, sempre que possível, todos os dados de entrada através de um método 
baseado em “listas brancas" que utilizem uma lista de caracteres ou expressões 
regulares para definirem os caracteres permitidos; 
 Se qualquer caractere potencialmente perigoso precisa ser permitido na entrada 
de dados da aplicação, certificar-se de que foram implementados controles 
adicionais como codificação dos dados de saída, APIs especificas que fornecem 
tarefas seguras e trilhas de auditoria no uso dos dados pela aplicação. 
 Se a rotina de validação padrão não abordar as seguintes entradas, então elas devem 
ser verificadas: 
o Verificar bytes nulos 
o Verificar se há caracteres de nova linha 
o Verificar se há caracteres “ponto-ponto barra” (../ ou ..\) que alteram 
caminhos. 
Em resumo: 
 
Esquema 2 – Validação dos Dados de Entrada. 
 
1.2.2 Codificação de Dados de Saída 
A lista de verificação é: 
 Efetuar toda a codificação dos dados em um sistema confiável; 
 Utilizar uma rotina padrão, testada, para cada tipo de codificação de saída; 
 Realizar a codificação, baseada em contexto, de todos os dados enviados para o 
cliente que têm origem em um ambiente fora dos limites de confiança da aplicação; 
 Codificar todos os caracteres, a menos que sejam conhecidos por serem seguros 
para o interpretador de destino; 
 Realizar o tratamento (sanitização), baseado em contexto, de todos os dados 
provenientes de fontes não confiáveis usados para construir consultas SQL, XML, 
e LDAP; 
 Tratar todos os dados provenientes de fontes que não sejam confiáveis que gerem 
comandos para o sistema operacional. 
• Validar em sistema confiável;
Classificar as fontes de dados como sendo confiáveis ou não;
• Validar os dados das fontes não confiáveis;
• Especificar o conjunto de caracteres apropriado;
• Em falha de validação rejeitar os dados fornecidos;
• Validar todos os dados provenientes dos clientes;
• Validar dados provenientes de relacionamentos.
• Validar tipos de dados esperados;
• Validar intervalo de dados;
• Validar o tamanho dos dados;
• Para caracteres potencialmente perigosos implemente controles adicionais.
Validação dos Dados de Entrada
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
17 
Em resumo: 
 
Esquema 3 – Codificação de Dados de Saída. 
 
1.2.3 Autenticação e Gerenciamento de Credenciais 
A lista de verificação é: 
 Requerer autenticação para todas as páginas e recursos, exceto para aqueles 
que são intencionalmente públicos; 
 Os controles de autenticação devem ser executados em um sistema confiável; 
 Sempre que possível, estabelecer e utilizar serviços de autenticação padronizados 
e testados; 
 Utilizar uma implementação centralizada para realizar os procedimentos de 
autenticação, disponibilizando bibliotecas que invoquem os serviços externos de 
autenticação; 
 Separar a lógica de autenticação do recurso que está a ser requisitado e usar 
redirecionadores dos controladores de autenticação centralizados; 
 Quando ocorrerem situações excepcionais nos controles de autenticação, executar 
procedimentos em caso de falha com o propósito de manter o sistema seguro; 
 Todas as funções administrativas e de gerenciamento de contas devem ser tão 
seguras quanto o mecanismo de autenticação principal; 
 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. Não utilizar o algoritmo de hash MD5, sempre que esse puder ser 
evitado; 
 A geração dos resumos (hash) das senhas deve ser executada em um sistema 
confiável; 
 Validar os dados de autenticação somente no final de todas as entradas de dados, 
especialmente para as implementações de autenticação sequencial; 
 As mensagens de falha na autenticação não devem indicar qual parte dos dados 
de autenticação está incorreta; 
•Efetuar codificação de dados em sistema confiável.
•Utilizar rotina padrão e testada;
•Realizar a codificação baseada em contexto;
•Tratar todos os dados de fontes não confiáveis.
Codificação de Dados de Saída
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
18 
 Utilizar autenticação para conexão a sistemas externos que envolvam tráfego de 
informação sensível ou acesso a funções; 
 As credenciais de autenticação para acessar serviços externos à aplicação devem ser 
cifradas e armazenadas em um local protegido de um sistema confiável; 
 Utilizar apenas requisições POST para transmitir credenciais de autenticação; 
 Somente trafegar senhas (não temporárias) através de uma conexão protegida 
(SSL/TLS) ou no formato de dado cifrado, como no caso de envio de e-mail cifrado. 
Senhas temporárias enviadas por e-mail podem ser um caso de exceção aceitável; 
 Exigir que os requisitos de complexidade de senha estabelecidos pela política ou 
regulamento sejam cumpridos. 
 Exigir que os requisitos de comprimento de senha estabelecidos pela política ou 
regulamento sejam cumpridos. O uso de oito caracteres é o mais comum, porém usar 
16 é mais recomendado. 
 A entrada da senha deve ser ocultada na tela do usuário. Em HTML, utilizar o 
campo do tipo "password"; 
 Desativar a conta após um número pré-definido de tentativas inválidas de 
autenticação; 
 Os processos de redefinição de senhas e operações de mudanças devem exigir os 
mesmos níveis de controle previstos para a criação de contas e autenticação; 
 Esquemas de pergunta/resposta (pré-definidas) usadas para a redefinição da 
senha devem evitar ataques que lancem respostas aleatórias; 
 Se optar por usar redefinição de senha baseada em e-mail, envie um e-mail somente 
para o endereço pré-definido contendo um link ou senha de acesso temporário que 
permitam ao usuário redefinir a senha; 
 O tempo de validade das senhas e dos links temporários deve ser curto; 
 Exigir a mudança de senhas temporárias na próxima vez que o usuário realizar a 
autenticação no sistema; 
 Notificar o usuário quando a senha for reiniciada; 
 Prevenir a reutilização de senhas; 
 As senhas devem ter,pelo menos, um dia de duração antes de poderem ser 
alteradas, a fim de evitar ataques de reutilização de senhas; 
 Garantir que a troca de senhas está em conformidade com os requisitos 
estabelecidos na política ou regulamento. 
 Desativar a funcionalidade de lembrar a senha nos campos de senha do 
navegador; 
 A data/hora da última utilização (bem ou mal sucedida) de uma conta de usuário 
deve ser comunicada no próximo acesso ao sistema; 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
19 
 Realizar monitoramento para identificar ataques contra várias contas de usuários, 
utilizando a mesma senha; 
 Modificar todas as senhas que, por padrão, são definidas pelos fornecedores, 
bem como os identificadores de usuários (IDs) ou desativar as contas associadas; 
 Exigir nova autenticação dos usuários antes da realização de operações críticas; 
 Utilizar autenticação de múltiplos fatores (utilizando simultaneamente token, 
senha, biometria etc.) para contas altamente sensíveis ou de alto valor transacional; 
 Caso utilize código de terceiros para realizar a autenticação, inspecione-o 
cuidadosamente para garantir que o mesmo não é afetado por qualquer código 
malicioso. 
 
 
Esquema 4 – Autenticação e Gerenciamento de Credenciais. 
 
•Requerer autenticação para recursos não públicos;
•Utilizar serviços de autenticação padronizados e testados.
•Utilizar implementação centralizada para autenticação.
•Separar a lógica de autenticação do recurso.
•Executar procedimentos em caso de falha.
•Assegurar funções administrativas e de gerenciamento.
•Senhas armazenadas em one-way salted hashes;
•Geração de hash em sistema confiável.
•Validar dados de autenticação somente ao final de todas as entradas;
•Mensagens de falha não devem indicar a parte incorreta;
•Utilizar apenas POST para transmitir credenciais;
•Trafegar senhas por conexões protegidas;
•Exigir requisitos de complexidade de senha;
•Exigir requisitos de comprimento de senha;
•A entrada da senha deve ser ocultada na tela do usuário;
•Desativar a conta após um número pré-definido de tentativas;
•Processos de redefinição devem exigir controles similares aos de criação.
•Esquemas de pergunta/resposta devem evitar ataques de respostas 
aleatórias;
•O tempo de validade das senhas e links temporários deve ser curto;
•Notificar o usuário quando a senha for reiniciada;
•Prevenir a reutilização de senhas;
•Desativar a funcionalidade de lembrar a senha;
•Modificar senhas e IDs definidos pelos fornecedores;
•Utilizar autenticação de múltiplos fatores para contas sensíveis.
•Verificar código de terceiros.
Autenticação e Gerenciamento de Credenciais
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
20 
1.2.4 Gerenciamento de sessões 
A lista de verificação é: 
 Utilizar controles de gerenciamento de sessão baseados no servidor ou em 
framework. A aplicação deve reconhecer apenas esses identificadores de sessão 
como válidos; 
 A criação dos identificadores de sessão deve ser sempre realizada em um sistema 
confiável; 
 O controle de gestão de sessão deve usar algoritmos conhecidos, padronizados e 
bem testados que garantam a aleatoriedade dos identificadores de sessão; 
 Definir o domínio e o caminho para os cookies que contenham identificadores de 
sessão autenticados, para um valor devidamente restrito ao site; 
 A funcionalidade de saída (logout) deve encerrar completamente a sessão ou 
conexão associada; 
 A funcionalidade de saída (logout) deve estar disponível em todas as páginas que 
requerem autenticação; 
 Estabelecer um tempo de expiração da sessão que seja o mais curto possível, 
baseado no balanceamento dos riscos e requisitos funcionais do negócio. Na maioria 
dos casos não deve ser maior do que algumas horas; 
 Não permitir logins persistentes (sem prazo de expiração) e realizar o 
encerramento da sessão periodicamente, mesmo quando ela estiver ativa. Isso deve 
ser feito, especialmente, em aplicações que suportam várias conexões de rede ou que 
se conectam a sistemas críticos. O tempo de encerramento deve estar de acordo com 
os requisitos do negócio e o usuário deve receber notificações suficientes para 
atenuar os impactos negativos dessa medida; 
 Se uma sessão estava estabelecida antes do login ela deve ser encerrada para que 
uma nova seja estabelecida após o login; 
 Gerar um novo identificador de sessão quando houver uma nova autenticação; 
 Não permitir conexões simultâneas com o mesmo identificador de usuário; 
 Não expor os identificadores de sessão em URLs, mensagens de erro ou logs. 
Os identificadores de sessão devem apenas ser encontrados no cabeçalho do cookie 
HTTP. Por exemplo, não trafegar os identificadores de sessão sob a forma de 
parâmetros GET; 
 Proteger os dados de sessão do lado servidor contra acessos não autorizados por 
outros usuários do servidor, através da implementação de controles de acesso 
apropriados no servidor; 
 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 (session 
hijacking), quando o identificador de sessão original for comprometido; 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
21 
 Gerar um novo identificador de sessão caso a segurança da conexão mude de 
HTTP para HTTPS, como pode ocorrer durante a autenticação. Internamente à 
aplicação, é recomendável utilizar HTTPS de forma constante em vez de alternar 
entre HTTP e HTTPS; 
 Utilizar mecanismos complementares ao mecanismo padrão de gerenciamento 
de sessões para operações sensíveis do lado servidor – como no caso de operações 
de gerenciamento de contas – usado para prevenir ataques do tipo Cross Site 
Request Forgery (CSRF); 
 Utilizar mecanismos complementares ao gerenciamento de sessões para 
operações altamente sensíveis ou críticas, utilizando tokens aleatórios ou 
parâmetros em cada requisição em vez de basear-se apenas na sessão; 
 Configurar o atributo "secure" para cookies transmitidos através de uma 
conexão TLS; 
 Configurar os cookies com o atributo “HttpOnly”, a menos que seja explicitamente 
necessário ler ou definir os valores dos mesmos através de scripts do lado cliente da 
aplicação. 
 
Esquema 5 – Gerenciamento de sessões. 
 
• Utilizar controles de sessão baseados em servidor ou framework.
• Criar identificadores com base em sistema confiável.
• Usar algoritmos conhecidos, padronizados e bem testados;
• Definir domínio e caminho para cookies.
• O logout deve encerrar completamente a sessão ou conexão;
• O logout deve estar disponível em todas as páginas com autenticação;
• O tempo de expiração da sessão deve ser o mais curto possível;
• Não permitir logins persistentes;
• Encerrar sessões antigas.
• Gerar novo identificador para novas sessões.
• Não permitir conexões simultâneas.
• Não expor os identificadores de sessão em URLs, mensagens de erro 
ou logs;
• Proteger dados do lado servidor.
• Gerar novo identificador de sessão e desativar antigo periodicamente;
• Utilizar mecanismos complementares ao gerenciamento de sessões para 
operações altamente sensíveis ou críticas.
• Configurar cookies: atributo "secure" e "HttpOnly".
Gerenciamento de Sessões
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
22 
1.2.5 Controle de acessos 
A lista de verificação é: 
 Utilizar apenas objetos do sistema que sejam confiáveis, como ocorre com os 
objetos de sessão do servidor, para realizar a tomada de decisão sobre a autorização 
de acesso; Utilizar um único componente em toda a aplicação Web para realizar o processo 
de verificação de autorização de acesso. Isto inclui bibliotecas que invocam os 
serviços externos de autorização; 
 Quando ocorrer alguma falha no controle de acesso, ela deve ocorrer de modo 
seguro; 
 Negar todos os acessos, caso a aplicação não consiga ter acesso às informações 
contidas na configuração de segurança; 
 Garantir o controle de autorização em todas as requisições, inclusive em scripts 
do lado servidor, "includes" e requisições provenientes de tecnologias do lado 
cliente, como AJAX e Flash; 
 Isolar do código da aplicação os trechos de código que contêm lógica privilegiada; 
 Restringir o acesso aos arquivos e outros recursos, incluindo aqueles que estão 
fora do controle direto da aplicação, somente aos usuários autorizados; 
 Restringir o acesso às URLs protegidas somente aos usuários autorizados; 
 Restringir o acesso às funções protegidas somente aos usuários autorizados; 
 Restringir o acesso às referências diretas aos objetos somente aos usuários 
autorizados; 
 Restringir o acesso aos serviços somente aos usuários autorizados; 
 Restringir o acesso aos dados da aplicação somente aos usuários autorizados; 
 Restringir o acesso aos atributos e dados dos usuários, bem como informações 
das políticas usadas pelos mecanismos de controle de acesso; 
 Restringir o acesso às configurações de segurança relevantes apenas aos 
usuários autorizados; 
 As regras de controle de acesso representadas pela camada de apresentação 
devem coincidir com as regras presentes no lado servidor; 
 Se o estado dos dados deve ser armazenado no lado cliente, utilizar mecanismos de 
criptografia e verificação de integridade no lado servidor para detectar possíveis 
adulterações; 
 Garantir que os fluxos lógicos da aplicação obedecem às regras de negócio; 
 
 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
23 
 Limitar o número de transações que um único usuário ou dispositivo pode 
executar em determinado período de tempo. As transações por período de tempo 
devem estar acima das necessidades reais do negócio, mas abaixo o suficiente para 
impedirem ataques automatizados; 
 Utilizar o campo “referer” do cabeçalho somente como forma de verificação 
suplementar. O mesmo não deve ser usado sozinho como forma de validação de 
autorização porque ele pode ter o valor adulterado; 
 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; 
 Implementar a auditoria das contas de usuário e assegurar a desativação de 
contas não utilizadas; 
 A aplicação deve dar suporte à desativação de contas e ao encerramento das sessões 
quando terminar a autorização do usuário; 
 As contas de serviço ou contas de suporte a conexões provenientes ou destinadas a 
serviços externos devem possuir o menor privilégio possível; 
 Criar uma Política de Controle de Acesso para documentar as regras de negócio 
da aplicação, tipos de dados e critérios ou processos de autorização 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. 
 
 
Esquema 6 – Controle de Acessos. 
 
• Usar apenas objetos confiáveis.
• Único componente para verificação de autorização de acesso;
• Negar todos os acessos caso perca acesso à configuração de 
segurança;
• Garantir controle de autorização em todas as requisições.
• Isolar da aplicação código com lógica privilegiada;
• Restringir acesso a: arquivos e outros recursos, URLs, funções 
protegidas, referências diretas a objetos, serviços, dados de 
aplicações, atributos e dados de usuário, configurações de segurança.
• Regras da apresentação devem coincidir com as do lado servidor;
• Limitar o número de transações;
• Implementar a auditoria das contas;
• Desativar contas não utilizadas; 
• Criar uma Política de Controle de Acesso.
Controle de Acessos
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
24 
1.2.6 Práticas de Criptografia 
A lista de verificação é: 
 Todas as funções de criptografia utilizadas para proteger dados sensíveis dos 
usuários da aplicação, devem ser implantadas em um sistema confiável (neste caso 
o servidor); 
 A senha mestre deve ser protegida contra acessos não autorizados; 
 Quando ocorrer alguma falha nos módulos de criptografia, permitir que as mesmas 
ocorram de modo seguro; 
 Todos os números, nomes de arquivos, GUIDs e strings aleatórias devem ser 
gerados usando um módulo criptográfico com gerador de números aleatórios, 
somente se os valores aleatórios gerados forem impossíveis de serem deduzidos; 
 Estabelecer e utilizar uma política e processo que defina como é realizado o 
gerenciamento das chaves criptográficas. 
 
Esquema 7 – Práticas de criptografia. 
 
1.2.7 Tratamento de Erros e Log 
A lista de verificação é: 
 Não expor informações sensíveis nas repostas de erros, inclusive detalhes de 
sistema, identificadores de sessão ou informação da conta do usuário; 
 Usar mecanismos de tratamento de erros que não mostrem informações de 
depuração (debug) ou informações da pilha de exceção; 
 Usar mensagens de erro genéricas e páginas de erro personalizadas; 
 A aplicação deve tratar os erros sem se basear nas configurações do servidor; 
 A memória alocada deve ser liberada de modo apropriado quando ocorrerem 
condições de erro; 
 O tratamento de erros lógicos associado com os controles de segurança deve, por 
padrão, negar o acesso; 
 Todos os controles de log devem ser implementados em um sistema confiável, por 
exemplo, centralizar todo o processo no servidor; 
•Usar sistema confiável para funções de criptografia.
•A senha mestre deve ser protegida;
•Usar gerador de números aleatórios somente se os valores aleatórios gerados 
forem impossíveis de serem deduzidos;
•Estabelecer política e processo para o gerenciamento das chaves.
Práticas de Criptografia
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
25 
 Os controles de log devem dar suporte tanto para os casos de sucesso como os de 
falha relacionados com os eventos de segurança; 
 Garantir que os logs armazenam eventos importantes; 
 Garantir que as entradas de log que incluam dados nos quais não se confia não 
sejam executadas como código-fonte na interface de visualização de logs; 
 Restringir o acesso aos logs apenas para pessoal autorizado; 
 Utilizar uma rotina centralizada para realizar todas as operações de log; 
 Não armazenar informações sensíveis nos registros de logs, como detalhes 
desnecessários do sistema, identificadores de sessão e senhas; 
 Garantir o uso de algum mecanismo que conduza (ou facilite) o processo de análise 
de logs; 
 Registrar em log todas as falhas de validação de entrada de dados; 
 Registrar em log todas as tentativas de autenticação, especialmente as que 
falharam por algum motivo; 
 Registrar em log todas as falhas de controle de acesso; 
 Registrar em log todos os eventos suspeitos de adulteração, inclusive alterações 
inesperadas no estado dos dados; 
 Registrar em log as tentativas de conexão com tokens de sessão inválidos ou 
expirados; 
 Registrar em log todas as exceções lançadas pelo sistema; 
 Registrar em log todas as funções administrativas, inclusive as mudanças 
realizadas nas configurações de segurança; 
 Registrar em log todasas falhas de conexão TLS com o backend; 
 Registrar em log todas as falhas que ocorreram nos módulos de criptografia; 
 Utilizar uma função de hash criptográfica para validar a integridade dos registros 
de log. 
 
Esquema 8 – Tratamento de Erros e Log. 
•Não expor informações sensíveis nas repostas de erros;
•Não mostrar informações de depuração (debug);
•Mensagens de erro genéricas e páginas de erro personalizadas;
•Liberar memória de modo apropriado em condições de erro;
•Garantir que os logs armazenam eventos importantes;
•Restringir o acesso aos logs apenas para pessoal autorizado;
•Não armazenar informações sensíveis nos registros de logs.
•Registrar em log: falhas de validação, tentativas de autenticação, falhas de 
controle de acesso, eventos suspeitos, tetntativas de conexão, exceções lançadas, 
falhas em módulos de criptografia.
•Usar hash para verificar integridade do log.
Tratamento de Erros e Log
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
26 
1.2.8 Proteção de Dados 
A lista de verificação é: 
 Implementar uma política de privilégio mínimo, restringindo os usuários apenas 
às funcionalidades, dados e informações do sistema que são necessárias para 
executarem suas tarefas; 
 Proteger contra acesso não autorizado todas as cópias temporárias ou 
registradas em cache que contenham dados sensíveis e estejam armazenadas no 
servidor e excluir esses arquivos logo que não forem mais necessários; 
 Criptografar informações altamente sensíveis quando armazenadas – como dados 
de verificação de autenticação – mesmo que estejam no lado servidor, usando sempre 
algoritmos conhecidos, padronizados e bem testados; 
 Proteger o código-fonte presente no servidor para que não sejam acessados por 
algum usuário; 
 Não armazenar senhas, strings de conexão ou outras informações confidenciais em 
texto claro/legível ou em qualquer forma criptograficamente insegura no lado 
cliente; 
 Remover comentários do código de produção que podem ser acessados pelos 
usuários e podem revelar detalhes internos do sistema ou outras informações 
sensíveis; 
 Remover aplicações desnecessárias e documentação do sistema que possam revelar 
informações importantes para os atacantes; 
 Não incluir informações sensíveis nos parâmetros de requisição HTTP GET; 
 Desativar a funcionalidade de auto completar nos formulários que contenham 
informações sensíveis, inclusive no formulário de autenticação; 
 Desativar a cache realizada no lado cliente das páginas que contenham 
informações sensíveis; 
 A aplicação deve dar suporte à remoção de dados sensíveis quando estes não forem 
mais necessários; 
 Implementar mecanismos de controle de acesso apropriados para dados sensíveis 
armazenados no servidor. 
 
Esquema 9 – Proteção de Dados. 
•Implementar política de privilégio mínimo;
•Proteger contra acesso não autorizado cópias temporárias ou em cache.
•Criptografar informações sensíveis;
•Proteger o código-fonte presente no servidor;
•Não armazenar informações confidenciais em texto claro;
•Não incluir informações sensíveis nos parâmetros HTTP GET.
•Desativar auto completar e cache de informações sensíveis.
Proteção de Dados
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
27 
1.2.9 Segurança nas comunicações 
A lista de verificação é: 
 Utilizar criptografia na transmissão de todas as informações sensíveis. Isto 
deve incluir TLS para proteger a conexão e deve ser complementado com 
criptografia de arquivos que contém dados sensíveis ou conexões que não usam o 
protocolo HTTP; 
 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; 
 Quando ocorrer alguma falha nas conexões TLS, o sistema não deve fornecer uma 
conexão insegura; 
 Utilizar conexões TLS para todo o conteúdo que requerer acesso autenticado ou 
que contenha informação sensível; 
 Utilizar TLS para conexões com sistemas externos que envolvam funções ou 
informações sensíveis; 
 Utilizar um padrão único de implementação TLS configurado de modo 
apropriado; 
 Especificar a codificação dos caracteres para todas as conexões; 
 Filtrar os parâmetros que contenham informações sensíveis, provenientes do 
“HTTP referer”, nos links para sites externos. 
 
 
Esquema 10 – Segurança nas comunicações. 
 
• Utilizar criptografia na transmissão de informações sensíveis.
• Os certificados TLS devem ser válidos;
• Utilizar conexões TLS para conteúdo sensível;
• Utilizar padrão TLS único;
• Especificar a codificação dos caracteres.
• Filtrar parâmetros que contenham informações sensíveis.
Segurança nas comunicações
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
28 
1.2.10 Configuração do Sistema 
A lista de verificação é: 
 Garantir que os servidores, frameworks e componentes do sistema estão executando 
a última versão aprovada; 
 Garantir que os servidores, frameworks e componentes do sistema possuem as 
atualizações mais recentes aplicadas para a versão em uso; 
 Desativar a listagem de diretórios; 
 Restringir, para o mínimo possível, os privilégios do servidor Web, dos processos 
e das contas de serviços; 
 Quando ocorrerem exceções no sistema, garantir que as falhas ocorram de modo 
seguro; 
 Remover todas as funcionalidades e arquivos desnecessários; 
 Remover código de teste ou qualquer funcionalidade desnecessária para o 
ambiente de produção, antes de instalar o sistema no servidor de produção; 
 Prevenir a divulgação da estrutura de diretórios impedindo que robôs de busca 
façam indexação de arquivos sensíveis, através da configuração do arquivo 
“robots.txt”; 
 Definir quais métodos HTTP, GET ou POST, a aplicação irá suportar e se serão 
tratados de modo diferenciado nas diversas páginas da aplicação; 
 Desativar 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; 
 Se o servidor processa tanto requisições HTTP 1.0 como HTTP 1.1, certificar-se 
de que ambos são configurados de modo semelhante ou assegure que qualquer 
diferença existente seja compreendida; 
 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; 
 O armazenamento da configuração de segurança para a aplicação deve ser capaz de 
ser produzida de forma legível para dar suporte à auditoria; 
 Implementar um sistema de gestão de ativos para manter o registro dos 
componentes e programas; 
 Isolar o ambiente de desenvolvimento da rede de produção e conceder acesso 
somente para grupos de desenvolvimento e testes; 
 Implementar um sistema de controle de mudanças para gerenciar e registrar as 
alterações no código, tanto de desenvolvimento, como dos sistemas em produção. 
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
29 
 
Esquema 11 – Configuração do Sistema. 
 
1.2.11 Segurança em Banco de Dados 
A lista de verificação é: 
 Usar consultas parametrizadas fortemente tipadas; 
 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; 
 Certificar-se de que as variáveis são fortemente tipadas; 
 Realizar a codificação (escaping)de meta caracteres em instruções SQL8; 
 A aplicação deve usar o menor nível possível de privilégios ao acessar o banco de 
dados; 
 Usar credenciais seguras para acessar o banco de dados; 
 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; 
 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; 
 Encerrar a conexão assim que possível; 
 Remover ou modificar senhas padrão de contas administrativas. Utilizar senhas 
robustas ou implementar autenticação de múltiplos fatores. Desativar qualquer 
funcionalidade desnecessária no banco de dados, como “stored procedures” ou 
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); 
 Eliminar o conteúdo desnecessário incluído por padrão pelo fornecedor como 
esquemas e bancos de dados de exemplo; 
•Servidores, frameworks e componentes devem estar na última versão 
aprovada, com atualizações mais recentes.
•Desativar a listagem de diretórios;
•Restringir, para o mínimo possível, os privilégios.
•Remover código-teste e funcionalidades desnecessárias em produção;
•Prevenir divulgação da estrutura de diretórios.
•Definir quais métodos HTTP a aplicação irá suportar;
•Remover informações desnecessárias dos cabeçalhos HTTP;
•Implementar sistema de gestão de ativos;
•Isolar ambiente de desenvolvimento e produção;
•Implementar um sistema de controle de mudanças.
Configuração do Sistema
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
30 
 Desativar todas as contas criadas por padrão e que não sejam necessárias para 
suportar os requisitos de negócio; 
 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. 
 
Esquema 12 – Segurança em bancos de dados. 
 
1.2.12 Gerenciamento de Arquivos 
A lista de verificação é: 
 Não repassar dados fornecidos pelos usuários diretamente a uma função de 
inclusão dinâmica; 
 Solicitar autenticação antes de permitir que seja feito o carregamento de arquivos; 
 Limitar os tipos de arquivos que podem ser enviados para aceitar somente os 
necessários ao propósito do negócio; 
 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; 
 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; 
 Prevenir ou restringir o carregamento de qualquer arquivo que possa ser 
interpretado ou executado pelo servidor Web; 
 Desativar privilégios de execução nos diretórios de armazenamento de arquivos; 
 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”; 
•Consultas parametrizadas fortemente tipadas;
•Validação de entrada e codificação de saída;
•Variáveis fortemente tipadas.
•Realizar escaping de meta caracteres.
•Aplicação com menor nível possível de privilégios;
•Encerrar a conexão assim que possível;
•Utilizar senhas robustas ou implementar autenticação de múltiplos 
fatores.
•Remover senhas padrão de contas administrativas;
•Desativar contas padrão;
•Diferentes credenciais para cada tipo de necessidade.
Segurança em Banco de Dados
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
31 
 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; 
 Não transmitir, sem nenhum tipo de tratamento, os dados informados pelo usuário 
a redirecionamentos dinâmicos. Se isso for necessário, o redirecionamento deverá 
aceitar apenas URLs relativas e validadas; 
 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; 
 Nunca enviar o caminho absoluto do arquivo para o lado cliente de uma aplicação 
ou para o usuário; 
 Certificar-se de que os arquivos da aplicação e os recursos estão definidos somente 
com o atributo de leitura; 
 Verificar os arquivos que os usuários submeterem através do mecanismo de 
carregamento em busca de vírus e malwares. 
 
Esquema 13 – Gerenciamento de Arquivos. 
 
1.2.13 Gerenciamento de Memória 
A lista de verificação é: 
 Utilizar controle de entrada/saída para os dados que não sejam confiáveis; 
 Verificar se o buffer é tão grande quanto o especificado; 
 Ao usar funções que aceitem determinado número de bytes para realizar cópias, 
como strncpy(), esteja ciente de que se o tamanho do buffer de destino for igual ao 
tamanho do buffer de origem, ele não pode encerrar a sequência de caracteres com 
valor nulo (null); 
•Não repassar dados fornecidos por usuários.
•Autenticação antes de carregar arquivos;
•Limitar tipos de arquivos enviados;
•Validar tipos esperados dos arquivos.
•Não salvar arquivos no diretório da aplicação;
•Desativar privilégios de execução nos diretórios;
•Não passar caminhos de arquivos em requisições;
•Não enviar caminho absoluto do arquivo;
•Arquivos da aplicação e recursos em modo somente leitura;
•Verificar arquivos submetidos (vírus e malwares).
Gerenciamento de Arquivos
Licensed to Aender de Almeida Miranda - aender@ufsj.edu.br - 042.687.596-62
 ____________________________________ 
 
TI TOTAL para Área Fiscal e Controle 
Professor Ramon Souza 
32 
 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; 
 Truncar todas as strings de entrada para um tamanho razoável antes de passá-
las para as funções de cópia e concatenação; 
 Na liberação de recursos alocados para objetos de conexão, identificadores de 
arquivo etc., não contar com o “garbage collector” e realizar a tarefa 
explicitamente; 
 Usar pilhas não executáveis, quando disponíveis; 
 Evitar o uso de funções reconhecidamente vulneráveis como printf(), strcat(), 
strcpy() etc.; 
 Liberar a memória alocada de modo apropriado após concluir a sub-rotina 
(função/método) e em todos pontos de saída. 
 
 
Esquema 14 – Gerenciamento de Memória. 
 
1.2.14 Práticas Gerais de Codificação 
A lista de verificação é: 
 Para tarefas comuns, utilizar sempre código testado, gerenciado e aprovado ao 
invés de criar código novo e não gerenciado; 
 Utilizar APIs que executem tarefas específicas para realizar operações do sistema 
operacional. Não permitir que a aplicação execute comandos diretamente no 
sistema operacional, especialmente através da utilização de “shells” de comando 
iniciadas pela aplicação; 
 Utilizar mecanismos de verificação de integridade por “checksum” ou “hash” 
para verificar a integridade do código interpretado, bibliotecas, arquivos executáveis 
e arquivos de configuração; 
 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 (race conditions); 
•Controle de entrada/saída para dados não confiáveis;
•Verificar se o buffer é tão grande quanto o especificado.
•Verificar limites do buffer;
•Truncar strings de entrada para tamanho razoável;
•Liberar recursos explicitamente;