Quais são os problemas de segurança online?
10 vulnerabilidades de segurança da web mais comuns
Para muitas empresas, só depois da ocorrência de uma violação de segurança é que as melhores práticas de segurança na web se tornam uma prioridade. Durante meus anos de trabalho como profissional de segurança de TI, tenho visto repetidamente como o mundo dos problemas de segurança de desenvolvimento da web pode ser obscuro para muitos de meus colegas programadores.
Uma abordagem eficaz para ameaças à segurança da web deve, por definição, ser proativa e defensiva. Com esse objetivo, esta postagem tem como objetivo despertar uma mentalidade de segurança, com sorte injetar no leitor uma dose saudável de paranóia.
Em particular, este guia concentra-se em 10 armadilhas de segurança da Web comuns e significativas que você deve conhecer, incluindo recomendações sobre como elas podem ser mitigadas. O foco está nas 10 principais vulnerabilidades da Web identificadas pelo Open Web Application Security Project (OWASP), uma organização internacional sem fins lucrativos cujo objetivo é melhorar a segurança de software em todo o mundo.
Um exemplo de algumas vulnerabilidades comuns da web que ninguém quer enfrentar.
Um pequeno manual de segurança cibernética antes de começarmos - autenticação e autorização
Ao falar com outros programadores e profissionais de TI, frequentemente encontro confusão em relação à distinção entre autorização e autenticação. E, claro, o fato de a abreviatura auth ser frequentemente usada para ambos ajuda a agravar essa confusão comum. Essa confusão é tão comum que talvez esse problema deva ser incluído neste post como “Zero vulnerabilidade comum na Web”.
Portanto, antes de prosseguirmos, vamos esclarecer a distinção entre esses dois termos:
Autenticação: Verificar se uma pessoa é (ou pelo menos parece ser) um usuário específico, uma vez que forneceu corretamente suas credenciais de segurança (senha, respostas a perguntas de segurança, leitura de impressão digital, etc.).
Autorização: Confirmação de que um determinado usuário tem acesso a um recurso específico ou tem permissão para executar uma ação específica.
Dito de outra forma, autenticação é saber quem é uma entidade, enquanto autorização é saber o que uma determinada entidade pode fazer. Com isso em mente, vamos examinar os 10 principais problemas de segurança da Internet.
Erro comum de segurança da Web nº 1: falhas de injeção
As falhas de injeção resultam de uma falha clássica em filtrar entradas não confiáveis. Isso pode acontecer quando você passa dados não filtrados para o servidor SQL (injeção SQL), para o navegador (XSS - falaremos sobre isso mais tarde), para o servidor LDAP (injeção LDAP) ou em qualquer outro lugar. O problema aqui é que o invasor pode injetar comandos nessas entidades, resultando na perda de dados e sequestrando os navegadores dos clientes.
Tudo o que seu aplicativo recebe de fontes não confiáveis deve ser filtrado, de preferência de acordo com uma lista de permissões. Você quase nunca deve usar uma lista negra, pois acertar é muito difícil e geralmente fácil de contornar. Os produtos de software antivírus normalmente fornecem exemplos estelares de listas negras com falha. A correspondência de padrões não funciona.
Prevenção: a boa notícia é que a proteção contra injeção é “simplesmente” uma questão de filtrar sua entrada de maneira adequada e pensar se ela é confiável. Mas a má notícia é que todas as informações precisam ser filtradas de maneira adequada, a menos que sejam inquestionavelmente confiáveis (mas o ditado “nunca diga nunca” vem à mente aqui).
Em um sistema com 1.000 entradas, por exemplo, filtrar com sucesso 999 delas não é suficiente, pois isso ainda deixa um campo que pode servir como a cura de Aquiles para derrubar seu sistema. E você pode pensar que colocar um resultado de consulta SQL em outra consulta é uma boa ideia, já que o banco de dados é confiável, mas se o perímetro não for, a entrada virá indiretamente de caras com malintent. Isso é chamado de injeção SQL de segunda ordem, caso você esteja interessado.
Como a filtragem é muito difícil de fazer da maneira certa (como a criptografia), o que geralmente aconselho é confiar nas funções de filtragem do seu framework: elas funcionam comprovadamente e são minuciosamente examinadas. Se você não usa estruturas, realmente precisa pensar muito se não usá-las realmente faz sentido no contexto de segurança do servidor. 99% das vezes não.
Erro comum de segurança da web nº 2: autenticação interrompida
Esta é uma coleção de vários problemas que podem ocorrer durante a autenticação interrompida, mas nem todos têm a mesma causa raiz.
Supondo que alguém ainda queira lançar seu próprio código de autenticação em 2014 (o que você está pensando ??), desaconselho. É extremamente difícil acertar e há uma infinidade de armadilhas possíveis, apenas para mencionar alguns:
O URL pode conter o id da sessão e vazá-lo no cabeçalho do referenciador para outra pessoa.
As senhas podem não ser criptografadas no armazenamento ou trânsito.
Os ids de sessão podem ser previsíveis, portanto, obter acesso é trivial.
A fixação da sessão pode ser possível.
O sequestro de sessão pode ser possível, tempos limites não implementados corretamente ou usando HTTP (sem segurança SSL), etc ...
Prevenção: A maneira mais direta de evitar essa vulnerabilidade de segurança da web é usar uma estrutura. Você pode ser capaz de implementar isso corretamente, mas o primeiro é muito mais fácil. Caso você queira criar seu próprio código, seja extremamente paranóico e aprenda quais são as armadilhas. Há muito poucos.
Erro comum de segurança da Web nº 3: Cross-Site Scripting (XSS)
Esta é uma falha de sanitização de entrada bastante comum (essencialmente um caso especial de erro comum nº 1). Um invasor fornece tags JavaScript ao seu aplicativo da web na entrada. Quando essa entrada é retornada ao usuário sem limpeza, o navegador do usuário a executa. Pode ser tão simples quanto criar um link e persuadir um usuário a clicar nele, ou pode ser algo muito mais sinistro. No carregamento da página, o script é executado e, por exemplo, pode ser usado para postar seus cookies para o invasor.
Prevenção: Existe uma solução simples de segurança na web: não retorne tags HTML ao cliente. Isso tem o benefício adicional de defesa contra injeção de HTML, um ataque semelhante em que o invasor injeta conteúdo HTML simples (como imagens ou reprodutores flash invisíveis) - não de alto impacto, mas certamente irritante (“por favor, faça parar!”). Normalmente, a solução alternativa é simplesmente converter todas as entidades HTML, para que <script> seja retornado como & lt; script & gt ;. O outro método de sanitização frequentemente empregado é o uso de expressões regulares para remover as tags HTML usando expressões regulares em <e>, mas isso é perigoso, pois muitos navegadores interpretarão HTML severamente corrompido muito bem. Melhor converter todos os caracteres em suas contrapartes escapadas.
Erro comum de segurança da Web nº 4: referências inseguras de objetos diretos
Este é um caso clássico de confiar na entrada do usuário e pagar o preço por uma vulnerabilidade de segurança resultante. Uma referência direta de objeto significa que um objeto interno, como um arquivo ou chave de banco de dados, é exposto ao usuário. O problema com isso é que o invasor pode fornecer essa referência e, se a autorização não for imposta (ou for quebrada), o invasor pode acessar ou fazer coisas das quais deveria ser impedido.
Por exemplo, o código possui um módulo download.php que lê e permite que o usuário baixe arquivos, usando um parâmetro CGI para especificar o nome do arquivo (por exemplo, download.php? File = something.txt). Por engano ou preguiça, o desenvolvedor omitiu a autorização do código. O invasor agora pode usar isso para baixar quaisquer arquivos de sistema aos quais o usuário que está executando o PHP tenha acesso, como o próprio código do aplicativo ou outros dados deixados no servidor, como backups. Opa.
Outro exemplo de vulnerabilidade comum é uma função de redefinição de senha que depende da entrada do usuário para determinar a senha que estamos redefinindo. Depois de clicar no URL válido, um invasor pode simplesmente modificar o campo de nome de usuário no URL para dizer algo como “admin”.
Prevenção: execute a autorização do usuário de maneira adequada e consistente e coloque as opções na lista de permissões. No entanto, na maioria das vezes, todo o problema pode ser evitado armazenando dados internamente e não contando com eles sendo transmitidos do cliente por meio de parâmetros CGI. As variáveis de sessão na maioria das estruturas são adequadas para esse propósito.
Erro comum de segurança da Web nº 5: configuração incorreta de segurança
Na minha experiência, servidores e aplicativos da Web que foram configurados incorretamente são muito mais comuns do que aqueles que foram configurados corretamente. Talvez porque não faltem maneiras de errar. Alguns exemplos:
Executando o aplicativo com a depuração ativada na produção.
Ter a listagem de diretórios habilitada no servidor, o que vaza informações valiosas.
Executando software desatualizado (pense em plug-ins do WordPress, antigo PhpMyAdmin).
Ter serviços desnecessários em execução na máquina.
Sem alterar as chaves e senhas padrão. (Acontece com muito mais frequência do que você imagina!)
Revelar informações de tratamento de erros aos invasores, como rastreamentos de pilha.
Prevenção: Tenha um bom processo (de preferência automatizado) de “construção e implantação”, que pode executar testes na implantação. A solução de configuração incorreta de segurança do pobre homem são ganchos pós-commit, para evitar que o código saia com senhas padrão e / ou material de desenvolvimento embutido.
Erro comum de segurança da web nº 6: exposição de dados confidenciais
Esta vulnerabilidade de segurança da web é sobre criptografia e proteção de recursos. Os dados confidenciais devem ser criptografados o tempo todo, inclusive em trânsito e em repouso. Sem exceções. As informações do cartão de crédito e as senhas do usuário nunca devem viajar ou ser armazenadas sem criptografia, e as senhas devem sempre ser criptografadas. Obviamente, o algoritmo de criptografia / hashing não deve ser fraco - em caso de dúvida, os padrões de segurança da web recomendam AES (256 bits e superior) e RSA (2048 bits e superior).
E embora nem seja preciso dizer que os IDs de sessão e os dados confidenciais não devem viajar nas URLs e os cookies confidenciais devem ter o sinalizador de segurança ativado, isso é muito importante e não pode ser enfatizado demais.
No armazenamento: isso é mais difícil. Em primeiro lugar, você precisa diminuir sua exposição. Se você não precisa de dados confidenciais, destrua-os. Os dados que você não possui não podem ser roubados. Nunca armazene informações de cartão de crédito, pois você provavelmente não quer ter que lidar com a compatibilidade com PCI. Inscreva-se com um processador de pagamentos, como Stripe ou Braintree. Em segundo lugar, se você tiver dados confidenciais de que realmente precisa, armazene-os criptografados e certifique-se de que todas as senhas tenham hash. Para hashing, o uso de bcrypt é recomendado. Se você não usa bcrypt, aprenda sobre salgaduras e tabelas rainbow.
E correndo o risco de afirmar o óbvio, não armazene as chaves de criptografia ao lado dos dados protegidos. É como guardar sua bicicleta com uma fechadura que contém a chave. Proteja seus backups com criptografia e mantenha suas chaves muito privadas. E claro, não perca as chaves!
Erro comum de segurança da Web nº 7: falta de controle de acesso de nível de função
Isso é simplesmente uma falha de autorização. Isso significa que quando uma função é chamada no servidor, a autorização adequada não foi executada. Muitas vezes, os desenvolvedores confiam no fato de que o lado do servidor gerou a IU e pensam que a funcionalidade não fornecida pelo servidor não pode ser acessada pelo cliente. Não é tão simples assim, já que um invasor sempre pode forjar solicitações para a funcionalidade “oculta” e não será dissuadido pelo fato de que a IU não torna essa funcionalidade facilmente acessível. Imagine que há um painel / admin e o botão só está presente na IU se o usuário for realmente um administrador. Nada impede que um invasor descubra essa funcionalidade e a faça mau uso se a autorização estiver faltando.
Prevenção: no lado do servidor, a autorização deve sempre ser feita. Sim, sempre. Nenhuma exceção ou vulnerabilidade resultará em problemas sérios.
Erro comum de segurança da Web nº 8: falsificação de solicitação entre sites (CSRF)
Este é um bom exemplo de um confuso ataque de deputado em que o navegador é enganado por outra parte para fazer uso indevido de sua autoridade. Um site de terceiros, por exemplo, pode fazer com que o navegador do usuário abuse de sua autoridade para fazer algo pelo invasor.
No caso do CSRF, um site de terceiros emite solicitações ao site de destino (por exemplo, seu banco) usando seu navegador com seus cookies / sessão. Se você estiver logado em uma guia na página inicial do seu banco, por exemplo, e eles estiverem vulneráveis a esse ataque, outra guia pode fazer seu navegador usar indevidamente suas credenciais em nome do invasor, resultando no problema do deputado confuso. O representante é o navegador que usa indevidamente sua autoridade (cookies de sessão) para fazer algo que o invasor o instrui a fazer.
Considere este exemplo:
A atacante Alice quer aliviar a carteira de Todd, transferindo parte de seu dinheiro para ela. O banco de Todd é vulnerável ao CSRF. Para enviar dinheiro, Todd precisa acessar o
Depois que esse URL é aberto, uma página de sucesso é apresentada a Todd e a transferência é concluída. Alice também sabe que Todd freqüentemente visita um site sob seu controle em, onde ela coloca o seguinte snippet:
Ao visitar o site de Alice, o navegador de Todd pensa que Alice cria um link para uma imagem e emite automaticamente uma solicitação HTTP GET para buscar a imagem, mas isso na verdade instrui o banco de Todd a transferir $ 1.500 para Alice.
Aliás, além de demonstrar a vulnerabilidade CSRF, este exemplo também demonstra a alteração do estado do servidor com uma solicitação HTTP GET idempotente que é uma vulnerabilidade séria. As solicitações HTTP GET devem ser idempotentes (seguras), o que significa que não podem alterar o recurso acessado. Nunca, jamais, use métodos idempotentes para alterar o estado do servidor.
Prevenção: armazene um token secreto em um campo de formulário oculto que seja inacessível do site de terceiros. Obviamente, você sempre deve verificar esse campo oculto. Alguns sites também pedem sua senha ao modificar configurações confidenciais (como seu e-mail de lembrete de senha, por exemplo), embora eu suspeite que isso existe para evitar o uso indevido de suas sessões abandonadas (em um cibercafé, por exemplo).
Erro comum de segurança da Web nº 9: usar componentes com vulnerabilidades conhecidas
O título diz tudo. Eu novamente classificaria isso como mais um problema de manutenção / implantação. Antes de incorporar o novo código, faça alguma pesquisa, possivelmente alguma auditoria. Usar o código que você obteve de uma pessoa aleatória no GitHub ou em algum fórum pode ser muito conveniente, mas não é isento de riscos de vulnerabilidade de segurança da web séria.
Já vi muitos casos, por exemplo, em que sites foram possuídos (ou seja, onde um estranho ganha acesso administrativo a um sistema), não porque os programadores eram estúpidos, mas porque um software de terceiros permaneceu sem patch por anos em produção. Isso está acontecendo o tempo todo com plug-ins do WordPress, por exemplo. Se você acha que eles não encontrarão sua instalação oculta do phpmyadmin, deixe-me apresentá-lo ao dirbuster.
A lição aqui é que o desenvolvimento de software não termina quando o aplicativo é implantado. Deve haver documentação, testes e planos sobre como mantê-lo atualizado, especialmente se ele contiver componentes de terceiros ou de código aberto.
Comentários
Postar um comentário