Este tutorial explica a codificação segura, como evitar vulnerabilidades relacionadas à segurança e fornece diretrizes de codificação e lista de verificação para práticas de codificação segura:

Para ter a segurança incorporada no software e implementar as Diretrizes de Codificação Segura e as Melhores Práticas, toda a organização, juntamente com a equipe identificada para trabalhar no Desenvolvimento de Aplicativos pretendido, precisa considerar certos aspectos.

Aqui, discutiremos os aspectos que ajudam a desenvolver um software seguro.

Secure Coding Guidelines

É tão simples como que, se um desenvolvedor não sabe o que se entende por “Segurança para o software” e como um hacker pode hackear seu software, assumir o controle dele e tentar explorar, então é simplesmente impossível codificar um software seguro. Assim, o desenvolvedor deve primeiro entender o significado da codificação segura.

O que você vai aprender:[ocultar]

O que é codificação segura?

A codificação segura é projetar e desenvolver software,evitando as fraquezasque levam a vulnerabilidades relacionadas à segurança, aderindo aos padrões de segurança especificados e às melhores práticas do setor.

A primeira pergunta que surge na mente de todos é: “Quanta segurança é necessária para o nosso Software” ouQuando podemos dizer que o nosso software está seguro? eQuais são esses padrões de segurança?

Fraudes e ameaças à segurança estão aumentando dia a dia e estamos vendo novas variedades e formas de hacking, mesmo no chamado software mais seguro.

Recentemente, ouvimos o programa Aaadhar da UIDAI sendo adulterado por dados pessoais. Portanto, é realmente difícil saber quanta segurança é necessária para o software e quais são os padrões de segurança, a menos que entendamos as ameaças envolvidas no software e as priorizemos com base nos riscos para o negócio.

Pode ser possivelmente difícil fornecer 100% de proteção de segurança para o software, mas se a Equipe do Programa analisar osRiscos e Valores Mobiliáriosenvolvidos em seu software, ou seja, ameaças potenciais e se a equipe puder cuidar da mitigação desses riscos, então seria bom do ponto de segurança do aplicativo.

Assim, a primeira tarefa para a equipe é identificar e analisar os riscos e valores mobiliários que estão envolvidos em sua aplicação e entender as possíveis opções de mitigação e adotar a melhor opção de acordo.

Assim, uma vez identificadas, as dez principais vulnerabilidades classificam quase todos os ataques que um programa provavelmente enfrentará. Isso ajudará a entender as ameaças e priorizará os esforços de segurança e desenvolvimento mais para a prevenção do que para a mitigação.

Por exemplo, Embora estejamos planejando desenvolver um aplicativo relacionado à saúde, que lida e armazene os dados de saúde do indivíduo e suas informações pessoais, o principal risco de segurança para o aplicativo é roubar os dados pessoais de saúde.

Mitigação de Riscos

Para mitigar o risco,

  • A implementação de segurança para acesso a dados por um usuário não autorizado precisa ser tratada com autenticação e autorização adequadas (implementações de política de senha forte, autenticação de 2 fatores).
  • É preciso tomar cuidado para garantir que não haja vazamento de dados durante a transmissão de dados de uma fonte para outra fonte, implementando canais seguros (HTTPS) de transmissão de dados e implementando criptografia de dados durante o trânsito.
  • Adulterar ou roubar dados em repouso também é outra possibilidade. Portanto, o armazenamento de dados pessoais de saúde (usando criptografia) é muito essencial.

Antes de ir para o ‘Secure Coding Standard’, é sempre melhor para toda a equipe do programa ter uma ‘Sessão de Conscientização de Segurança’ e discutir e debater sobre,

  • A exigência de segurança para o seu produto específico.
  • Possíveis benefícios que um hacker teria ao hackear seu sistema.
  • Possíveis formas e meios de comprometimento de segurança de sua aplicação.
  • Práticas de segurança comuns seguidas em um setor e domínio semelhantes.
  • Compreensão de problemas de segurança típicos de seus respectivos programas.

Também ajuda a equipe a lidar melhor, se eles puderem entender asfontes das vulnerabilidadesque seu software pode enfrentar e as razões pelas quais o software é construído com segurança ruim / inadequada.

Razões para a implementação inadequada da segurança

Em geral, a seguir estão alguns motivos para a implementação de segurança inadequada no aplicativo.

  • É dada prioridade para a Liberação Funcional do que para os aspectos de Segurança.
  • Ignorância ou nenhuma consciência sobre segurança de software e hackers.
  • Não há clareza suficiente sobre o Programa ou sobre o Design de Software em si.
  • A complexidade do Programa.
  • Não há dados suficientes, informações sobre o sistema ao vivo onde ele será implantado.
  • Nenhuma consideração de Segurança nas fases SDLC.
  • Conhecimento e compreensão insuficientes das especificidades da linguagem utilizada no software.
  • Não há conhecimento suficiente para a equipe e os desenvolvedores sobre as Diretrizes de Codificação de Segurança.

Sabemos que não é que todos os Desenvolvedores e Testadores estejam cientes da segurança de um aplicativo e possam não ter uma compreensão profunda das vulnerabilidades e explorações de segurança, especialmente para o aplicativo em que eles estariam trabalhando. Geralmente, eles estarão familiarizados com, ‘Como codificar funcionalmente’, mas nem todos eles sabem ‘Como codificar com segurança’.

Por isso, o aspecto muito importante para a organização adotar Práticas de Codificação Segura em seu software é primeiro “Treinar Pessoas”. Portanto, treinar sua equipe sobre Aspectos de Codificação Segura, Melhores Práticas de Codificação de Segurança e o uso correto da Ferramenta é muito importante.

O Princípio de Design mais importante da Segurança de Software é “Implementar a Segurança por Design e Padrão”.

Diretrizes de codificação segura

Para alcançar a segurança, é muito essencial ter um ‘padrão de codificação segura’ identificado para um programa no início do desenvolvimento do aplicativo, e isso ajuda a equipe a cuidar dos padrões seguros para o software e ajuda a protegê-lo dos ataques.

É essencial garantir que toda a equipe sejaobrigada a aderir a este padrão, independentemente da linguagem de codificação e das ferramentas que eles estão usando no programa.

Dado abaixo estão alguns exemplos que precisam ser implementados por padrão no design de código seguro:

  • O acesso deve ser restrito apenas a usuários autenticados e a autenticação precisa ser implementada em todas as camadas.
  • Os canais de comunicação precisam ser criptografados para proteger os tokens de autenticação.
  • Todas as chaves, senhas e certificados precisam ser armazenados e protegidos corretamente.
  • A criptografia de arquivos, a criptografia de banco de dados e a criptografia de elementos de dados precisam ser implementadas.

Seleção de idioma para codificação segura

A seleção de idioma para codificação pode não depender de codificação segura. Não há nada específico como uma linguagem segura ou não segura para codificação para construir um software seguro.

É exatamente como usamos uma linguagem de programação para construir o software e quanto conhecimento aprofundado o desenvolvedor tem sobre a linguagem de codificação na implementação de aspectos de segurança.

No entanto, esclarece-se que, emboraos Padrões de Codificação Segura sejam independentes da seleção da linguagem, as Práticas Recomendadas de Código Seguro são dependentes da linguagem, da Plataforma e da Implementação.

Assim, para ter um Código Seguro, é essencial que o Desenvolvedor tenha um conhecimento aprofundado da linguagem que está sendo utilizada no programa, para que as melhores práticas de segurança possam ser implementadas facilmente.

Exemplo:

  • A probabilidade de vulnerabilidade de estouro de buffer difere de linguagem para linguagem, mas C, C++ e Assembly são considerados mais suscetíveis devido aos seus recursos de gerenciamento de memória desatualizados. Várias funções C lib padrão, como strcpy() e memcpy(), são vulneráveis a ataques de estouro de buffer. O uso incorreto dessas funções, copiando um buffer de origem que é muito grande para caber no buffer de destino, resulta em estouro de buffer.
  • O problema comum em aplicativos Web baseados em Java são os possíveis vazamentos de recursos que podem ocorrer devido a recursos abertos do sistema, como um arquivo, soquete e conexões de banco de dados.

O próximo aspecto da segurança é sobre as ferramentas aserem usadasno Programa de Aplicação para otimizar a segurança, o uso de ferramentas comoAmbientes de Desenvolvimento Integradosserá mais benéfico, pois eles fornecem muitosAlertasaos usuários e chamam a atenção para esses alertas para tentar melhorar a qualidade do software.

  • A integração de bibliotecas/plugins comerciais ou de código aberto, como Eclipse, Spring Tool Suite, RAD com IDE, ajuda os desenvolvedores a escrever código seguro, detectando e identificando código potencialmente vulnerável e fornece alertas sobre descobertas relacionadas à execução de arquivos maliciosos, vazamento de informações e tratamento inadequado de erros.

Também é essencial usar osAnalisadores Estáticos e Dinâmicospara melhorar os aspectos de segurança do software. Geralmente, os analisadores estáticos são otimizados para tipos específicos de erro, de modo que acabam encontrando um grande número de falsos positivos ao identificar erros específicos. Às vezes, há possibilidades de que eles percam os erros reais também.

Por isso, recomenda-se o uso devários analisadores estáticospara obter uma melhor cobertura de diferentes tipos de erros e evitar muitos falsos positivos. Às vezes, também é recomendado realizartestes manuaisparaeliminar falsos positivos.

Regras e recomendações de codificação segura

Será bom para o Programa definir um conjunto de «Regras e Recomendações de Codificação Segura» em relação às quais o código-fonte possa ser avaliado quanto à sua conformidade, de modo a que os testadores possam realizar os «Ensaios de Conformidade de Conformidade» para cada uma destas normas de codificação segura.

Por conseguinte, o código de segurança pode ser certificado como conforme ou não conforme utilizando essas regras em relação ao valor de referência estabelecido.

Algumas das regras mencionadas abaixo podem ser usadas para verificar se há violações de segurança:

  • Os arquivos precisam ser fechados quando não forem mais necessários.
  • Sempre que passar uma estrutura através de um limite, o vazamento de informações precisa ser evitado.
  • Os objetos devem ser declarados com durações de armazenamento apropriadas.

Portanto, os casos de teste para verificar essas regras precisam ser projetados e realizados para verificar a conformidade com a conformidade. Também é identificado que a maioria das vulnerabilidades é causada por erros de programação comuns típicos.

Assim, o Desenvolvedor precisa entender o “Método Inseguro de codificação”, enquanto também aprende as melhores práticas de Codificação Segura. É ideal reunir os erros de programação mais comuns que contribuem para as vulnerabilidades de segurança de seu aplicativo para que eles possam ser atendidos durante a codificação.

Esses erros típicos de programação são contribuídos principalmente por estouros de buffer, scripts entre sites e falhas de injeção.

Algumas das vulnerabilidades típicas de programação incluem:

  • Injeção de SQL (neutralização inadequada de elementos especiais usados em um comando SQL).
  • Estouro de inteiros.
  • Estouro de buffer (cópia de buffer sem verificar o tamanho da entrada).
  • Cadeia de caracteres de formato não controlada.
  • Falta de autenticação e autorização (autorização incorreta).
  • Exposição de dados confidenciais.
  • Tratamento inadequado de erros.

Alguns desses erros podem levar a falhas no sistema, acesso imprevisto ao sistema e o controle do software sendo perdido para os hackers.

Erros comuns de programação a serem evitados

Alguns erros comuns de programação que precisam ser evitados estão listados abaixo:

  • Neutralização inadequada de elementos especiais usados em um comando SQL (‘SQL Injection’).
  • Cópia do buffer sem verificar o tamanho da entrada (‘Estouro de buffer clássico’).
  • Falta de autenticação para a função crítica.
  • Autorização ausente ou incorreta.
  • Uso de credenciais codificadas.
  • Falta criptografia de dados confidenciais.
  • Upload irrestrito de arquivo com tipo perigoso.
  • Confiança em entradas não confiáveis em uma decisão de segurança.
  • Execução com privilégios desnecessários.
  • Falsificação de Solicitação entre Sites (CSRF).
  • Download de código sem verificação de integridade.
  • Cálculo incorreto do tamanho do buffer.
  • Restrição imprópria de tentativas excessivas de autenticação.
  • Redirecionamento de URL para Site Não Confiável (‘Abrir Redirect’).
  • Cadeia de caracteres de formato não controlada.
  • Uso de um hash unidirecional sem sal.

Lista de verificação para práticas de código seguras

Por último, mas não menos importante, depois de considerar todos os pontos acima dos aspectos de Desenvolvimento de Software Seguro, os Desenvolvedores precisam seguir aLista de Verificação estabelecida para as Práticas de Código Seguro paragarantir que as coisas não sejam perdidas. Dado abaixo são alguns, mas não uma lista exaustiva.

Validação de entrada:

  • Não confie na entrada, considere a validação centralizada da entrada.
  • Não confie na validação do lado do cliente.
  • Tenha cuidado com problemas de canonização.
  • Contrinja, rejeite e higienize a entrada. Valide para tipo, comprimento, formato e intervalo.

Autenticação:

  • Particione o site por área anônima, identificada e autenticada.
  • Use senhas fortes.
  • Suporte a períodos de expiração de senha e desativação de conta.
  • Não armazene credenciais (use hashes unidirecionais com sal).
  • Criptografe canais de comunicação para proteger tokens de autenticação.
  • Passe cookies de autenticação de formulários somente por meio de conexões HTTPS.

Autorização:

  • Use contas com menos privilégios.
  • Considere a granularidade da autorização.
  • Impor a separação de privilégios.
  • Restrinja o acesso do usuário aos recursos no nível do sistema.
  • Use o protocolo OAuth 2.0 para autenticação e autorização.
  • Validação de API de Transporte.
  • Métodos permitidos da lista branca.
  • Proteja ações privilegiadas e coleções de recursos confidenciais.
  • Proteja-se contra falsificação de recursos entre sites (CSRF).

Gerenciamento de Sessão:

  • Crie um identificador de sessão no servidor.
  • Encerre a sessão com o Logoff.
  • Gere uma nova sessão na reautenticação.
  • Defina o atributo ‘secure’ para cookies transmitidos por TLS.

Criptografia:

  • Use criptografia enquanto “Dados em trânsito, Dados em armazenamento, Dados em movimento, Integridade da mensagem”.
  • Não desenvolva o seu próprio. Use recursos de plataforma testados e comprovados.
  • Mantenha os dados não criptografados próximos ao algoritmo.
  • Use o algoritmo e o tamanho da chave corretos.
  • Evite o gerenciamento de chaves (use DPAPI).
  • Alterne as chaves periodicamente.
  • Armazene chaves em um local restrito.

Registro em log e auditoria:

  • Identifique comportamentos mal-intencionados.
  • Saiba como é um bom tráfego.
  • Audite e registre a atividade em todas as camadas do aplicativo.
  • Acesso seguro a arquivos de log.
  • Faça backup e analise regularmente os arquivos de log.

Codificação de saída:

  • Carryout ‘Validação de Entrada (XML, JSON….).
  • Use a consulta parametrizada.
  • Execute a ‘Validação de esquema’.
  • Realizar Codificação (XML, JSON..).
  • Enviar cabeçalhos de segurança.

Referência: ‘OWASP Secure Coding Practices Checklist(Em suma, SCP Checklist)’

Resumo tabular da lista de verificação de codificação segura

A tabela abaixo resume as ‘Coisas a lembrar para código seguro’ de um aplicativo.

# Que?
1 Para entender claramente, “O que é Código Seguro”?
2 Para entender as “Fontes das Vulnerabilidades” comuns.
3 Conduzir a ‘Sessão de Conscientização de Segurança’ para a equipe.
4 Identificar e analisar ‘Riscos e Valores Mobiliários’ envolvidos na aplicação e métodos para ‘Mitigar’.
5 “Treinar a equipe” em padrões de codificação segura, melhores práticas e diretrizes.
6 Para definir ‘Secure Coding Standard’
7 Para garantir que toda a equipe seja obrigada a aderir ao padrão de codificação segura.
8 Usar a “Linguagem Fácil de Implementar” e ter um “conhecimento aprofundado” dela.
9 Para usar ferramentas IDE (Integrated Development Environment)
10 Usar ‘Analisadores estáticos e dinâmicos’ e ‘múltiplos analisadores estáticos’ para eliminar ‘falsos positivos’
11 Para realizar “Testes manuais” sempre que necessário para identificar o erro, perca.
12 Para definir um conjunto de ‘Regras e Recomendações de Codificação Segura’
13 Para realizar “Testes de Conformidade de Conformidade” para as regras estabelecidas.
14 Para entender ‘Método inseguro de codificação’ e reunir ‘Erros comuns de programação’.
15 Seguir rigorosamente a ‘Lista de Verificação SCP’

Conclusão

Esperamos que este tutorial seja o seu melhor guia para garantir a segurança do software.

As diretrizes de codificação para o desenvolvimento seguro de software foram listadas aqui em termos simples com exemplos para sua fácil compreensão do conceito.

Boa leitura!!

Artigo Original