Um olhar sobre o projeto Top 10 da OWASP: Protegendo seus aplicativos da Web

Autor: Roger Morrison
Data De Criação: 28 Setembro 2021
Data De Atualização: 10 Poderia 2024
Anonim
OWASP Top 10
Vídeo: OWASP Top 10

Contente


Fonte: Andrey Roussanov / Dreamstime.com

Leve embora:

De acordo com o Open Web Application Security Project (OWASP), essas são as maiores vulnerabilidades de aplicativos da web. Você está em risco?

Você tem que dar algum crédito aos hackers. Eles são persistentes, criativos e frequentemente bem-sucedidos. Imagine o que eles poderiam fazer se apenas direcionassem seus esforços para atividades positivas. Os hackers atacarão os serviços de rede da maneira que puderem. E que maneira melhor do que atacar diretamente o coração da internet: o aplicativo da web. Uma organização chamada Open Web Application Security Project (OWASP) compila regularmente vulnerabilidades comuns de aplicativos da web. Eles o chamam de OWASP Top 10 Project. A seguir, é apresentado um resumo dessas explorações.

A1: 2017 - Injeção

Você pode pensar que os computadores são inteligentes, mas eles praticamente fazem o que você manda. Se você der um comando a um computador, poderá contar com ele para tentar executá-lo se não houver nada que o contrate. E se alguém - alguém - digitar um comando em algum lugar que o computador reconheça, ele terá todos os motivos para executá-lo da melhor maneira possível. Portanto, os hackers tentam encontrar maneiras de injetar comandos sempre que possível. Como o site da OWASP coloca:


“Falhas de injeção, como SQL, NoSQL, OS e LDAP, ocorrem quando dados não confiáveis ​​são enviados a um intérprete como parte de um comando ou consulta.”

Como eles fazem isso? Eles selecionam os comandos nas instruções que você digita na tela. Três tipos de injeção são entrada não -anitizada, injeção cega de SQL e injeção baseada em erro.

O autor técnico Joseph Cox chama a injeção de SQL "a maneira mais fácil de invadir" e "a principal ameaça aos sites".

A2: 2017 - autenticação quebrada

Todos ouvimos histórias sobre senhas comprometidas. IDs de usuário e senhas são usados ​​para autenticação na maioria dos aplicativos. A autenticação interrompida ocorre quando um hacker intercepta o ID e a senha de um usuário ou o ID da sessão que é criado quando o usuário efetua login. Há várias maneiras de fazer isso.


OWASP lista métodos comuns para esse hack e oferece exemplos e maneiras de evitá-lo. Essas explorações aproveitam os pontos fracos, como conexões não criptografadas, senhas fracas e códigos de sessão que não expiram. Deixar o login do administrador padrão como admin / admin é um erro amador, mas acontece. E quem usaria a palavra "senha" como senha? Escolher uma senha difícil é uma escolha inteligente. As senhas não criptografadas, durante o login ou quando são armazenadas, estão causando problemas. (Para obter mais informações sobre senhas, consulte Simplesmente seguro: alterando os requisitos de senha com mais facilidade para os usuários.)

O uso da autenticação multifator é uma maneira de evitar essa vulnerabilidade. Os administradores também devem limitar as tentativas de logon com falha e garantir que o ID da sessão não esteja visível no URL.

Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida

Você não pode melhorar suas habilidades de programação quando ninguém se importa com a qualidade do software.

A3: 2017 - Exposição de dados confidenciais

Você vê isso o tempo todo nas notícias: outra brecha na segurança! Os números de cartão de crédito armazenados e outros dados confidenciais são mantidos em bancos de dados pelas empresas de serviços da web. Mas os hackers são inteligentes - e persistentes. De acordo com o EE Online, "Uma cifra fraca é definida como um algoritmo de criptografia / descriptografia que usa uma chave de tamanho insuficiente". As cifras fracas facilitam a quebra da criptografia. E eles podem ser usados ​​por hackers como backdoors no seu banco de dados. Com TLS não forçado ou criptografia fraca, seu site pode ser rebaixado de HTTPS para HTTP, permitindo que os bandidos entrem.

Os números de cartão de crédito descriptografados após a recuperação tornam-se alvos bem-vindos para ataques na web. O mesmo vale para quaisquer dados confidenciais armazenados em servidores da web. De acordo com o OWASP, criptografar todos os dados confidenciais, armazenados ou em trânsito, é uma maneira de impedir esse hack. A classificação adequada de informações confidenciais é essencial para combater esta vulnerabilidade.

A4: 2017 - Entidades externas XML (XXE)

Como o W3 Schools explica, o XML foi projetado para transportar dados. Significa eXtensible Markup Language. Os aplicativos da Web analisam dados XML armazenados em servidores da web. Entidade é um termo de programação que se refere a "qualquer objeto singular, identificável e separado". Uma entidade externa, então, seria um objeto que existe fora do servidor.

O problema com esta vulnerabilidade está na análise. John Wagnon, da F5, explica que um bandido pode inserir código malicioso para induzir seu aplicativo da Web a fazer algo que não deveria. "Se o analisador de XML não estiver configurado corretamente", diz ele, "ele executará esse comando e espalhará todos esses dados - e isso não é uma coisa boa". O XXE aproveita os analisadores de XML para processar dados ruins.

As dicas de prevenção da OWASP incluem:

  • Use formatos de dados menos complexos.
  • Corrija ou atualize processadores ou bibliotecas XML.
  • Desative o processamento de entidade externa XML.
  • Use a validação XML Schema Definition (XSD).

A5: 2017 - Controle de acesso quebrado

O acesso não é o mesmo que autenticação. Você pode fazer login em um site através da autenticação, mas só poderá acessar os serviços para os quais possui permissões. Os administradores têm permissões muito maiores que os usuários normais. A elevação do privilégio do usuário está no centro desse hack.

Uma vez autenticados, os usuários são restritos por meio de verificações de controle de acesso. Os hackers procuram maneiras de contornar essas verificações através da modificação do URL ou de algum outro meio. Para evitar esse ataque, Wagnon recomenda muitos testes manuais do seu controle de acesso atual. Quando usuários normais podem acessar recursos destinados apenas a usuários com mais privilégios, isso significa que você tem algum controle de acesso interrompido. A OWASP diz que você pode lidar com isso negando o acesso por padrão, reforçando a propriedade do registro e registrando e relatando falhas de acesso.

A6: 2017 - Configuração incorreta de segurança

Proteger seu servidor é a chave para proteger contra ataques maliciosos e mantê-lo online. Mas isso deve ser feito da maneira certa. A falta de itens ou a adição de recursos desnecessários pode tornar seu aplicativo vulnerável. O cenário 1 do OWASP é sobre um servidor de aplicativos que vem com aplicativos de amostra que não são removidos na produção. E nesse cenário, os aplicativos de amostra têm falhas conhecidas. O fortalecimento adequado do servidor detectaria essas coisas.

Para evitar configurações incorretas de segurança, você precisa bloquear o servidor. Há muitos bits e partes em qualquer servidor, e as instalações padrão geralmente vêm com muitos extras que você não precisa. Esses recursos padrão podem causar problemas. Como Wagnon diz: "Não use o que você não precisa". A OWASP recomenda "uma plataforma mínima sem recursos, componentes, documentação e amostras desnecessários". E você deve revisar e atualizar as configurações de segurança regularmente em seu servidor web. Para isso, você deve usar processos repetitivos de proteção.

A7: 2017 - Script entre sites (XSS)

Entramos dados em sites o tempo todo. O script entre sites (XSS) ocorre quando um invasor injeta seu próprio código em uma página da web para obter informações confidenciais do banco de dados do site. Uma página HTML que permite a entrada de scripts em campos como caixas de comentários se abre para todos os tipos de problemas. Um invasor pode injetar código entre para dar comandos ao servidor. A OWASP chama o XSS a segunda questão mais prevalecente no Top 10 da OWASP.

O problema aqui é a injeção de dados não confiáveis. Isso deve ser separado do conteúdo ativo do navegador. "Escapar" é a chave para a prevenção. Isso significa garantir que o código injetado não seja executado. Consulte a "Folha de dicas sobre prevenção de XSS (Cross Site Scripting)" para saber mais sobre como escapar de dados não confiáveis. (Para aprender sobre desenvolvimento web, confira 10 coisas que todo desenvolvedor web moderno deve saber.)

A8: 2017 - Desserialização insegura

Serialização é sobre a conversão de informações de estado de um objeto em formato binário ou. Essa é a conversa do programador para colocar alguma unidade de código em um fluxo de dados para que ele possa ser transmitido por uma rede e sair de alguma forma na mesma condição. A desserialização ocorre quando o objeto é transformado do fluxo de bytes novamente em objeto. A desserialização insegura interrompe esse processo.

É uma forma de violação de dados. Talvez a mesma estrutura de dados seja usada, mas o conteúdo seja alterado. Dados não confiáveis ​​de um invasor alteram o fluxo de bytes. Um exemplo do OWASP é um hacker alterando um objeto serializado PHP para obter privilégios de administrador. As respostas para esse hack incluem assinaturas digitais e monitoramento de desserialização.

A9: 2017 - Usando componentes com vulnerabilidades conhecidas

Este problema é bastante auto-explicativo. Software não suportado e desatualizado é particularmente vulnerável. Nesse caso, ignorância não é felicidade. Os gerentes de segurança de TI precisam ficar a par dos últimos boletins, patches e atualizações de segurança. A OWASP recomenda um inventário contínuo de versões de software e o monitoramento de bibliotecas e componentes de software. E eles resumem bem:

"Toda organização deve garantir que exista um plano em andamento para monitorar, fazer triagem e aplicar atualizações ou alterações de configuração durante toda a vida útil do aplicativo ou portfólio".

A10: 2017 - Registro e monitoramento insuficientes

De acordo com a OWASP, “A exploração de registro e monitoramento insuficientes é a base de quase todos os grandes incidentes.” Todo sistema de TI deve ter um sistema de eventos de registro. Seja um dispositivo de rede ou um servidor de dados, é necessário que haja um registro de quando as coisas dão errado. Se um login de usuário falhar, ele deverá estar nos logs. Se um programa não funcionar corretamente, seu sistema deve registrá-lo. Se algum componente de hardware parar de funcionar, ele deverá ser registrado.

Qualquer evento significativo deve ser registrado. Se você está se perguntando o que pode se qualificar, pode dar uma olhada na "Ficha de registro de ocorrências" da OWASP. Como os alarmes de rede, esses eventos podem ser registrados quando um determinado limite é atingido. Esses limites podem ser ajustados conforme necessário.

Mas logs e alarmes não significam nada se não forem monitorados. Isso pode ser feito através de automação proativa ou vigilância humana. Com o registro e o monitoramento adequados, a equipe de TI pode responder a problemas em tempo hábil.

Conclusão

Cobrimos bastante material aqui. Mas há muito mais a aprender. Para investigar mais, dê uma olhada nas fontes de onde conduzimos nossa pesquisa. Os vídeos de John Wagnon, na F5 DevCentral, são um ótimo recurso, pelo qual agradecemos. E a OWASP possui um documento PDF que cobre todas essas explorações. Este estudo pode dar muito trabalho, mas não esqueça que os hackers também trabalham horas extras.