Acesse também o material de estudo!
Introdução
Retomando os temas de Segurança da Informação, uma das áreas de Tecnologia da Informação (TI) mais importantes dos concursos da atualidade, vamos falar hoje sobre boas práticas de programação segura da Open Web Application Security Project (OWASP).
Muitos concurseiros queixam-se de que não há muitos materiais disponíveis da OWASP. Por causa disso, resolvemos gastar um tempinho no nosso Blog para fazer um resumo sobre as boas práticas de programação segura. Veja o que teremos pela frente:
- OWASP && Programação Segura
- Checklist de Práticas de Programação Segura
Embora o artigo não seja sobre desenvolvimento de sistemas, é importante que você já tenha conhecimento de programação. O tema de hoje é específico para quem está fazendo provas da área de TI.
Preparamos um artigo bem objetivo, a fim de que você consiga ter acesso ao conteúdo necessário em poucos minutos. Sendo assim, desejamos uma ótima leitura e vamos começar.
Tempo de leitura aproximada: 5 a 10 minutos
OWASP && Programação Segura
OWASP é a sigla para Open Web Application Security Project. Na prática, é uma organização internacional focada em segurança de aplicações para web.
Nenhum código é 100% seguro e infalível de problemas e erros. Porém, é importante que sejam adotadas uma série de medidas para proteger o código de potenciais ataques, o máximo possível. Essa é a linha da programação segura.
Com o intuito de padronizar e difundir o conhecimento, a OWASP elaborou um checklist de práticas de programação segura. Esse checklist foi dividido em 14 categorias:
Na próxima seção, vamos apresentar as categorias do checklist e falar sobre as principais práticas contidas em cada um deles. Prepare-se porque será bem direto e intenso.
Checklist de Práticas de Programação Segura
Seguem as principais recomendações de práticas de programação segura, de maneira resumida, presentes em cada categoria do checklist da OWASP:
Validação dos Dados de Entrada, Codificação de Dados de Saída e Autenticação e Gerenciamento de Credenciais na Programação Segura
| VALIDAÇÃO DOS DADOS DE ENTRADA |
|---|
| Especificar conjunto de caracteres UTF-8 para as entradas de dados. |
| A aplicação deve rejeitar os dados fornecidos em caso de falhas na validação. |
| Validar os dados provenientes dos clientes antes do processamento. |
| Validar dados provenientes de redirecionamentos. |
| Checar tipos, intervalo e tamanho de dados esperados. |
| Utilizar o método “listas brancas” (lista de caracteres permitidos ou expressões regulares) na validação. |
| CODIFICAÇÃO DE DADOS DE SAÍDA |
|---|
| Efetuar a codificação dos dados em um sistema confiável. |
| Utilizar uma rotina padrão e testada para cada codificação de saída. |
| Codificar todos os caracteres. |
| Realizar o tratamento dos dados provenientes de fontes não confiáveis. |
| AUTENTICAÇÃO E GERENCIAMENTO DE CREDENCIAIS |
|---|
| Senhas deverão ser armazenadas na base sob a forma de hash. |
| Validar os dados somente no final de todas as entradas. |
| Mensagens de falha não devem indicar qual dado está incorreto. |
| Utilizar requisições POST para transmitir credenciais de autenticação. |
| Trafegar senhas por meio de conexão SSL/TLS ou dado cifrado. |
| Requisitos de política de senhas devem ser cumpridos. |
| Entrada da senha deve ser ocultada na tela. |
| Desativar a conta após um número de tentativas inválidas de autenticação. |
| Redefinição de senhas por e-mail deve conter links temporários. |
| Exigir alteração de senhas temporárias no próximo login. |
| Notificar o usuário após reset da senha. |
| Utilizar autenticação de múltiplos fatores para contas sensíveis. |
Gerenciamento de Sessões, Controle de Acessos, Práticas de Criptografia e Tratamento de Erros e Log na Programação Segura
| GERENCIAMENTO DE SESSÕES |
|---|
| Funcionalidade de saída deve encerrar a sessão associada. |
| Tempo de expiração da sessão deve ser o mais curto possível. |
| Não permitir logins sem prazo de expiração. |
| Encerrar sessões abertas previamente em caso de novos logins. |
| Não permitir conexões simultâneas com o mesmo identificador. |
| Não expor identificadores em URLs, mensagens de erro e logs. |
| Utilizar mecanismos complementares para operações sensíveis. |
| CONTROLE DE ACESSOS |
|---|
| Garantir o controle de autorização em todas as requisições. |
| Restringir o acesso somente aos usuários autorizados. |
| Utilizar mecanismos de criptografia e verificação de integridade para detectar adulterações. |
| Limitar o número de transações que um usuário ou dispositivo pode executar em determinado tempo. |
| Revalidar periodicamente a autorização para sessões autenticadas por muito tempo. |
| Implementar a auditoria de contas, desativando as não utilizadas. |
| Desativar contas e encerrar sessões que não tenham mais autorização. |
| Contas de serviço devem possuir o menor privilégio possível. |
| Criar uma Política de Controle de Acesso. |
| PRÁTICAS DE CRIPTOGRAFIA |
|---|
| Proteger senha mestre contra acessos não autorizados. |
| Estabelecer política para gerenciamento de chaves criptográficas. |
| TRATAMENTO DE ERROS E LOG |
|---|
| Não expor informações sensíveis nas respostas de erros e nos registros de log. |
| Não mostrar informações de debug ou stack trace. |
| Usar mensagens de erro genéricas e páginas de erro personalizadas. |
| Logs devem suportar casos de sucesso ou falha de eventos, incluindo validação de dados, tentativas de autenticação, exceções etc. |
| Restringir o acesso aos logs apenas para pessoal autorizado. |
| Utilizar hash para validar a integridade do log. |
Proteção de Dados, Segurança nas Comunicações, Configurações do Sistema e Segurança em Banco de Dados na Programação Segura
| PROTEÇÃO DE DADOS |
|---|
| Implementar política de privilégio mínimo aos usuários. |
| Proteger cópias temporárias que contenham dados sensíveis. |
| Criptografar informações sensíveis quando armazenadas. |
| Remover documentação que possa revelar informações para atacantes. |
| Não incluir informações sensíveis nos parâmetros de requisições GET. |
| Remover dados sensíveis que não forem mais necessários. |
| SEGURANÇA NAS COMUNICAÇÕES |
|---|
| Utilizar criptografia para transmitir informações sensíveis. |
| Certificados TLS devem ser válidos. |
| Utilizar conexões TLS para informações sensíveis. |
| Especificar a codificação de caracteres nas conexões. |
| CONFIGURAÇÕES DO SISTEMA |
|---|
| Desativar a listagem dos diretórios. |
| Restringir os privilégios de arquivos e contas. |
| Remover funcionalidades e arquivos desnecessários. |
| Impedir que robôs de busca façam indexação de arquivos sensíveis. |
| Definir quais métodos a aplicação irá suportar e sua forma de tratamento. |
| Remover informações desnecessárias dos cabeçalhos de resposta. |
| Implementar um sistema de gestão de ativos. |
| Isolar os ambientes de desenvolvimento e produção. |
| Implementar um sistema de controle de mudanças. |
| SEGURANÇA EM BANCO DE DADOS |
|---|
| Usar consultas parametrizadas. |
| Usar credenciais seguras para acessar o banco de dados. |
| Não incluir strings de conexão na aplicação. |
| Usar stored procedures para abstrair o acesso aos dados. |
| Encerrar a conexão assim que possível. |
| Utilizar senhas robustas ou autenticação de múltiplos fatores. |
| Desativar contas e senhas criadas por padrão. |
| Conexão com diferentes credenciais para cada necessidade. |
Gerenciamento de Arquivos, Gerenciamento de Memória e Práticas Gerais de Codificação na Programação Segura
| GERENCIAMENTO DE ARQUIVOS |
|---|
| Solicitar autenticação antes do upload de arquivos. |
| Limitar os tipos de arquivos a serem enviados. |
| Não salvar os arquivos junto com a aplicação web. |
| Restringir a interpretação ou execução de arquivos. |
| Não enviar o caminho absoluto de um arquivo. |
| Verificar a presença de malwares antes do upload. |
| GERENCIAMENTO DE MEMÓRIA |
|---|
| Verificar se o buffer é suficiente. |
| Atentar para a gravação de dados além do espaço reservado. |
| Liberar recursos alocados para objetos e após concluir rotinas. |
| PRÁTICAS GERAIS DE CODIFICAÇÃO |
|---|
| Utilizar mecanismos de verificação de integridade. |
| Evitar acessos concorrentes, principalmente de objetos compartilhados. |
| Instanciar explicitamente objetos antes de seu uso. |
| Elevar privilégios, caso seja necessário, e revogá-los o mais breve possível. |
| Revisar a segurança em códigos de terceiros, para evitar vulnerabilidades. |
Conclusão
Apresentamos hoje um resumo de boas práticas de programação segura recomendadas pela OWASP. Não deixe de salvar essa publicação para consultas futuras, pois este material é bem raro e procurado no mundo dos concursos.
Além disso, é importante que você faça muitas questões. Alunos aprovados realizam centenas ou até milhares de exercícios para atingir seu objetivo. O acesso ao Sistema de Questões do Estratégia é feito pelo link: https://concursos.estrategia.com/.
Sugerimos também que você aprofunde o conteúdo de Segurança da Informação por meio dos materiais da plataforma. O Estratégia oferece diversos cursos em pdf, videoaulas e áudios para você ouvir onde quiser. Descubra tudo no link http://www.estrategiaconcursos.com.br/cursos/.
Bons estudos e até a próxima!
Cristiane Selem Ferreira Neves é Bacharel em Ciência da Computação e Mestre em Sistemas de Informação pela Universidade Federal do Rio de Janeiro (UFRJ), além de possuir a certificação Project Management Professional pelo Project Management Institute (PMI). Já foi aprovada nos seguintes concursos: ITERJ (2012), DATAPREV (2012), VALEC (2012), Rioprevidência (2012/2013), TJ-RJ (2022), TCE-RJ (2022) e CGE-SC (2022/2023). Atualmente exerce o cargo efetivo de Auditora de Controle Externo – Tecnologia da Informação e integra o corpo docente da Escola de Contas de Gestão do TCE-RJ, além de ser produtora de conteúdo dos Blogs do Estratégia Concursos, OAB e Carreiras Jurídicas.
Concursos Abertos
Quer Saber Tudo de Concursos Previstos?
Confira Nossos Artigos
Concursos 2024
Créditos:
Estratégia Concursos
Acesse também o material de estudo!
