Trazemos à sua atenção os 10 principais controles proativos para desenvolvedores de software - 10 aspectos de segurança nos quais os desenvolvedores de software devem se concentrar. Este artigo contém uma lista de técnicas de segurança necessárias para serem implementadas no desenvolvimento de cada novo projeto.
Softwares inadequadamente protegidos comprometem a segurança de instalações críticas de infraestrutura, como assistência médica, defesa, energia ou finanças. Nossa infra-estrutura digital global está se tornando mais complexa, o número de relacionamentos entre seus componentes está aumentando e, portanto, a importância da segurança de aplicativos está crescendo exponencialmente. Ameaças de segurança relativamente simples não podem mais ser ignoradas.
OWASP
O Projeto de Segurança de Aplicativo da Web Aberto (OWASP) é um projeto de segurança de aplicativo da web de código aberto. A comunidade da OWASP inclui empresas, organizações educacionais e indivíduos de todo o mundo. A OWASP está trabalhando em artigos, tutoriais, documentação, ferramentas e tecnologias acessíveis ao público.
O projeto OWASP é referenciado por muitos padrões, ferramentas e organizações, incluindo MITRE, PCI DSS, DISA, FTC e muitos outros.
O projeto Defesa Proativa: Os 10 principais requisitos da OWASP é semelhante ao projeto da
Top 10 da
OWASP , mas se concentra em métodos e recomendações para proteção contra ameaças, e não nas ameaças em si. Cada método e recomendação neste documento está associado a uma ou mais ameaças da lista dos 10 melhores da OWASP.
Metas e objetivos
O objetivo do projeto Proactive Defense: OWASP Top 10 Requirements é chamar a atenção para a segurança de aplicativos, abordando os aspectos mais importantes de segurança da informação que os desenvolvedores de software devem considerar. Incentivamos as organizações a aproveitar as recomendações proativas de defesa da OWASP e ensinamos aos desenvolvedores como prestar atenção à segurança dos aplicativos, dando importância aos erros que ocorreram em outras organizações. Esperamos que as recomendações da OWASP sejam úteis para você ao criar aplicativos seguros.
Público-alvo
O documento é destinado principalmente a desenvolvedores. No entanto, será útil para gerentes de desenvolvimento, gerentes de produto, especialistas em garantia de qualidade, gerentes de projeto e outros participantes no processo de criação de software.
Os 10 principais requisitos de defesa proativa
C1: Definição de requisitos de segurança
Os requisitos de segurança descrevem as funções que devem ser implementadas para fornecer determinadas configurações de segurança do software. Eles são baseados em padrões do setor, leis aplicáveis e dados de vulnerabilidade. Os requisitos definem funções que precisam ser desenvolvidas ou desenvolvidas para solucionar problemas específicos de segurança ou eliminar possíveis ameaças.
O Padrão de Certificação de Segurança de Aplicativos OWASP (ASVS) é um catálogo de requisitos de segurança e opções de verificação disponíveis. OWASP ASVS pode fornecer requisitos avançados de segurança para equipes de desenvolvimento.
Os requisitos de segurança são classificados com base em funções comuns de segurança de nível superior. Por exemplo, o ASVS contém as seguintes categorias: autenticação, controle de acesso, tratamento e registro de erros e serviços da web. Para cada categoria, há uma lista de parâmetros que devem ser verificados.
O processo de aplicação bem-sucedida dos requisitos de segurança inclui quatro estágios: pesquisa e seleção, documentação, implementação, confirmação da implementação correta de novas funções de segurança e funcionalidade do aplicativo.
C2: Usando estruturas e bibliotecas seguras
Bibliotecas e estruturas seguras com recursos de segurança integrados ajudam os desenvolvedores a evitar vulnerabilidades durante as fases de desenvolvimento e implementação. Os desenvolvedores que constroem um aplicativo do zero podem não ter conhecimento, tempo ou dinheiro suficientes para implementar ou manter a segurança do aplicativo. O uso de estruturas seguras pode aumentar o nível de segurança do aplicativo.
Quando você inclui bibliotecas ou estruturas de terceiros em seu software, as seguintes recomendações devem ser consideradas:
- Use bibliotecas e estruturas de fontes confiáveis, ativamente desenvolvidas e amplamente usadas em aplicativos;
- compilar e manter atualizado o catálogo de todas as bibliotecas de terceiros;
- mantenha bibliotecas e componentes atualizados. Use ferramentas como OWASP e Retire.JS Dependency Checks para determinar dependências em projetos e também verifique vulnerabilidades conhecidas e publicadas no código de terceiros;
- Use o encapsulamento da biblioteca e apenas a funcionalidade necessária para o seu software para reduzir a probabilidade de ataques.
C3: Fornecendo acesso seguro aos bancos de dados
Esta seção é dedicada a fornecer acesso seguro a todos os data warehouses, incluindo bancos de dados relacionais e NoSQL.
Uma das ameaças mais graves à segurança dos aplicativos é a injeção de SQL. Esse tipo de ataque é fácil de implementar: o código SQL pode ser injetado se a entrada não confiável for adicionada dinamicamente às consultas SQL, o que geralmente acontece anexando-as à linha principal. A exploração desta vulnerabilidade pode levar ao roubo, exclusão ou alteração de bancos de dados. O aplicativo também pode ser usado para executar comandos mal-intencionados em um sistema que contém seu banco de dados, o que permitirá que um invasor se posicione na rede.
Para evitar injeções de SQL, você deve evitar a interpretação de entradas não verificadas como parte dos comandos SQL. A melhor solução seria usar o método "parametrização de consulta". Este método deve ser aplicado às construções SQL e OQL, bem como aos procedimentos armazenados.
Exemplos de parametrização de consulta para ASP, ColdFusion, C #, Delphi, .NET, Go, Java, Perl, PHP, PL / SQL, PostgreSQL, Python, R, Ruby e Scheme podem ser encontrados em
http://bobby-tables.com e no
memorando OWASP para parametrização de consulta .
C4: codificação e blindagem de dados
Codificação e escape são métodos de proteção contra injeção de código. Codificação, também chamada de "codificação de saída", é a conversão de caracteres especiais em combinações equivalentes que não são perigosas para o intérprete. Por exemplo, o caractere <é convertido em uma combinação <quando é adicionado a uma página HTML. O escape consiste em adicionar caracteres especiais na frente de caracteres ou seqüências de caracteres para impedir que sejam interpretados incorretamente, por exemplo, adicionar o caractere \ antes "(aspas duplas) permite interpretá-los como parte do texto e não como um terminador de linha.
A codificação é melhor aplicada imediatamente antes de passar os dados para o intérprete. Se você aplicar esse método muito cedo no processamento da solicitação, a codificação ou a proteção poderão afetar o uso do conteúdo em outras partes do programa. Por exemplo, se o conteúdo HTML for escapado antes de ser salvo no banco de dados e a interface escapar automaticamente desses dados novamente, o conteúdo não será exibido corretamente devido ao escape duplo.
Codificação ou escape podem ser usados para impedir outras formas de incorporação no conteúdo. Por exemplo, você pode neutralizar alguns metacaracteres especiais ao inserir dados para comandos do sistema. Isso é chamado de "escape de comandos do SO", "escape de shell" etc. Essa proteção pode ser usada para impedir a “injeção de comando”.
Existem outras formas de escape que podem ser usadas para evitar injeções, por exemplo, escape de atributos XML que protegem contra várias formas de incorporação de caminhos XML e XML e escape de nomes LDAP exclusivos para evitar várias injeções LDAP.
C5: Verificação obrigatória de todas as entradas
A validação dos dados de entrada faz parte de uma técnica de programação que garante que apenas os dados formatados corretamente entrem nos componentes do programa.
Norma sintática e semântica
O aplicativo deve verificar os dados quanto à conformidade com a norma sintática e semântica (nessa ordem) antes de usá-los (incluindo a exibição para o usuário).
A norma sintática significa que os dados correspondem à apresentação esperada. Por exemplo, em um aplicativo, um usuário pode especificar um "identificador" de quatro dígitos para executar determinadas operações. Um invasor pode inserir dados que lhe permitam injetar código SQL; portanto, o aplicativo deve verificar se os dados inseridos são exatamente números e exatamente na quantidade de quatro caracteres (além de usar a parametrização de consulta apropriada).
A norma semântica significa o uso de apenas dados de entrada que não vão além de uma certa funcionalidade e contexto. Por exemplo, ao especificar um período, a data de início deve preceder a data de término.
Listas brancas e negras
Existem duas abordagens principais para verificar a sintaxe de entrada - verificação de lista negra e lista de permissões.
O primeiro método foi desenvolvido para procurar conteúdo "potencialmente prejudicial" nos dados. Por exemplo, um aplicativo da Web pode bloquear a entrada que contém a palavra SCRIPT para impedir a criação de scripts entre sites. No entanto, essa medida de proteção pode ser contornada usando letras minúsculas ou uma combinação de letras minúsculas e maiúsculas para a tag de script.
O segundo método visa confirmar a conformidade dos dados com os requisitos de um conjunto de regras "testadas". Por exemplo, uma lista de permissões de estados dos EUA procuraria um código de duas letras em uma lista de estados existentes nos EUA.
Ao criar software seguro, a lista de permissões é recomendada no mínimo. As listas negras podem conter erros, podem ser contornadas de várias maneiras e, por si só, podem ser perigosas. Embora seja possível ignorar as restrições das listas negras, elas podem ser úteis na detecção de ataques óbvios. Assim, as listas brancas ajudam a limitar a possibilidade de um ataque, verificando se os dados são consistentes com as normas sintáticas e semânticas, enquanto as listas negras ajudam a detectar e impedir ataques óbvios.
Verificações do cliente e do servidor
Para garantir a segurança, a verificação de entrada sempre deve ser feita no lado do servidor. As verificações do lado do cliente podem ser úteis em termos de funcionalidade e segurança, mas geralmente são facilmente contornadas. Portanto, a validação do lado do servidor é preferível por segurança. Por exemplo, a verificação do JavaScript pode avisar o usuário que o campo deve conter apenas números, mas o aplicativo no lado do servidor deve confirmar que os dados de entrada são números em um intervalo aceitável de valores.
C6: Implementar identificação digital
A identificação digital é uma representação exclusiva do usuário (ou de qualquer outro objeto) nas transações online. Autenticação é o processo de confirmação de que uma pessoa ou entidade é quem é. O gerenciamento de sessões é o processo pelo qual o servidor monitora o estado de autenticação do usuário para que ele possa continuar usando o sistema sem nova autenticação. Edição especial
NIST 800-63B : Guia de identificação digital (autenticação e gerenciamento do ciclo de vida) fornece diretrizes detalhadas para a implementação de requisitos de identificação digital, autenticação e gerenciamento de sessões.
C7: Controle de acesso obrigatório
O controle de acesso (ou autorização) consiste em permitir ou proibir solicitações específicas de usuários, programas ou processos e também envolve a emissão e revogação de tais privilégios.
Note-se que a autorização (confirmação do direito de acesso a funções ou recursos especiais) não é igual à autenticação (verificação de identidade).
O controle de acesso geralmente afeta muitos aspectos do software, dependendo da complexidade do sistema de controle de acesso. Por exemplo, o gerenciamento ou o armazenamento em cache de metadados de controle de acesso para fins de escalabilidade geralmente são componentes adicionais de um sistema de controle de acesso que precisam ser criados ou mantidos. Existem várias abordagens diferentes para o controle de acesso:
- controle de acesso seletivo (DAC) - envolve restringir o acesso a objetos (por exemplo, arquivos ou elementos de dados) com base no identificador, bem como o princípio do "conhecimento necessário" dos sujeitos (por exemplo, usuários ou processos) e / ou grupos aos quais os objetos pertencem;
- Controle de acesso obrigatório (MAC) - envolve a restrição do acesso aos recursos do sistema com base na criticidade dos dados (definidos por rótulos) contidos nesses recursos e na autoridade formal (ou seja, acesso) dos usuários para acessar informações de importância especificada;
- Modelo de controle de acesso baseado em função (RBAC) - envolve o controle de acesso a recursos com base em funções que definem ações permitidas com recursos, e não com base em identificadores de assunto;
- controle de acesso baseado em atributo (ABAC) - envolve permitir ou negar solicitações de usuário com base em atributos de usuário e atributos de objeto, bem como elementos ambientais que podem ser definidos globalmente e serem mais relevantes para as políticas aplicáveis.
C8: Proteção de dados onipresente
Dados confidenciais, como senhas, números de cartão de crédito, registros médicos, dados pessoais e segredos comerciais, exigem proteção adicional, especialmente se estiverem sujeitos à lei de privacidade de dados, como o Regulamento Geral de Proteção de Dados da UE (GDPR) ou a lei de proteção dados financeiros, como o PCI DSS (Payment Card Data Security Standard).
Os invasores podem roubar dados de aplicativos e serviços da Web de várias maneiras diferentes. Por exemplo, um invasor pode se conectar a uma rede sem fio compartilhada e exibir ou roubar dados confidenciais de outros usuários se eles forem transmitidos por uma conexão insegura à Internet. Um invasor também pode usar a injeção de SQL para roubar senhas e outras credenciais dos aplicativos e colocá-las em domínio público.
Classificação dos dados
Você precisa classificar os dados em seu sistema e determinar o nível de criticidade de cada bloco de dados. Cada categoria de dados pode ser associada às regras de proteção definidas para cada nível de criticidade. Por exemplo, informações públicas de marketing que não são confidenciais podem ser atribuídas a dados publicamente disponíveis que podem ser publicados em um site disponível publicamente. Os números de cartão de crédito podem ser atribuídos aos dados pessoais de usuários que precisam de criptografia ao armazená-los ou transferi-los.
Criptografia de transmissão
Ao transferir dados confidenciais através de qualquer rede, a proteção de conexão de ponta a ponta (ou criptografia) deve ser aplicada. O TLS é de longe o protocolo criptográfico mais utilizado e suportado que fornece conexões seguras. É usado em muitas áreas (aplicativos da web, serviços da web, aplicativos móveis) para transmissão segura de dados em uma rede. Para garantir a segurança das conexões TLS, você deve configurá-las corretamente.
O principal benefício do protocolo TLS é a proteção de dados de aplicativos da web contra acesso não autorizado e alterações durante a transferência entre clientes (navegadores da web) e o servidor de aplicativos da web, bem como entre o servidor de aplicativos da web e o servidor interno ou outro não-navegador , componentes da organização.
Criptografia de Dados
A primeira regra para gerenciar dados confidenciais é evitar o armazenamento de dados confidenciais sempre que possível. Se você precisar salvar dados confidenciais, verifique se eles têm proteção criptográfica contra acesso e alterações não autorizados.
A criptografia é uma das áreas mais avançadas de segurança da informação; seu entendimento requer amplo conhecimento e experiência. É difícil escolher uma solução única, pois existem muitas abordagens diferentes para criptografia, e cada uma delas tem suas vantagens e desvantagens, que os arquitetos e desenvolvedores da web devem entender claramente. Além disso, pesquisas criptográficas sérias geralmente são baseadas em matemática e teoria dos números, o que cria um alto limiar de entrada.
C9: implementar log e monitoramento de eventos de segurança
A maioria dos desenvolvedores já usa o log para depuração e diagnóstico. Também é importante registrar eventos de segurança (dados relacionados à segurança) enquanto o aplicativo está em execução. O monitoramento é uma análise ao vivo dos logs de aplicativos e segurança usando várias ferramentas de automação. As mesmas ferramentas e modelos podem ser aplicados a operações, depuração e segurança em andamento.
Benefícios do log de eventos de segurança
Os logs de eventos de segurança podem ser usados para:
- fornecer dados ao sistema de detecção de ataques;
- análise e investigação de incidentes;
- conformidade com os requisitos regulamentares.
Implementando o log de eventos de segurança
A seguir, são apresentadas recomendações para a implementação do log de eventos de segurança.
- Use formulários e métodos padrão para registrar eventos no sistema e entre os sistemas da sua organização. Um exemplo de plataforma de log de eventos padrão é o Apache Logging Services, que fornece compatibilidade de log entre aplicativos Java, PHP, .NET e C ++.
- Não registre muitos ou poucos dados. Por exemplo, certifique-se de registrar carimbos de data e hora e credenciais, como o endereço IP de origem e o ID do usuário, mas nunca registre dados pessoais ou confidenciais.
- Preste atenção especial à sincronização de horário entre os nós para garantir a consistência do registro de data e hora.
Registro para detectar e neutralizar ataques
Use o log para determinar a atividade que indica o comportamento malicioso do usuário. Atividade potencialmente perigosa a ser registrada:
- Os dados de entrada estão fora do intervalo numérico esperado;
- os dados de entrada modificam os componentes que devem permanecer inalterados (lista de seleção, caixas de seleção, outros componentes com entrada limitada);
- solicitações que violam regras de controle de acesso do lado do servidor;
- Uma lista mais detalhada de marcadores de ataque pode ser encontrada aqui .
Quando um aplicativo detecta essa atividade, ele deve pelo menos registrar esse evento e marcá-lo como perigoso. Idealmente, o aplicativo deve neutralizar o ataque, por exemplo, cancelando a sessão do usuário e bloqueando sua conta. O mecanismo de contramedida permite que o programa responda a ataques detectáveis em tempo real.
C10: Tratamento obrigatório de todos os erros e exceções
O tratamento de exceções permite que um aplicativo responda a vários erros (por exemplo, uma falha de rede ou conexão a um banco de dados) de várias maneiras. O tratamento correto de exceções e erros é simplesmente necessário para garantir a confiabilidade e a segurança do seu código.
Erros e exceções são tratados em todos os níveis do aplicativo, incluindo lógica comercial crítica, recursos de segurança e estruturas.O tratamento de erros também é importante em termos de detecção de ataques. Alguns ataques a aplicativos podem causar erros que podem detectar um ataque no processo.Tratamento incorreto de erros
Pesquisadores da Universidade de Toronto descobriram que mesmo uma pequena supervisão ao processar erros ou ignorá-los pode levar a falhas críticas em sistemas distribuídos .A manipulação incorreta de erros pode causar várias vulnerabilidades.- . . , , , . (, ) . , , , .
- TLS. Apple «goto fail» , TLS- Apple.
- . . . .
- , try/catch . .
- Verifique se as mensagens de erro exibidas não contêm dados críticos, mas que contêm informações suficientes para responder adequadamente.
- Verifique se as exceções são registradas para que o suporte técnico, o controle de qualidade, a investigação de incidentes ou a equipe de resposta tenham dados suficientes para resolver o problema.
- Teste e verifique o código de tratamento de erros com cuidado.
Conclusão
Este documento deve ser considerado como um ponto de partida, e não como um conjunto exaustivo de métodos e práticas. Mais uma vez, queremos observar que os materiais apresentados visam familiarizá-lo com os conceitos básicos do desenvolvimento de software seguro.Ao criar um programa de segurança de aplicativos, é recomendável que você execute as seguintes etapas:
A versão completa da tradução e o original . Na tradução e adaptação participaram: JZDLin , Alexey Skachkov , Ivan Kochurkin e Taras Ivashchenko .
Este documento foi lançado sob a licença Creative Commons Attribution ShareAlike 3.0, traduzido e adaptado com a participação da filial russa do consórcio OWASP .