Este é o primeiro material de uma série de artigos sobre o Projeto OWASP Top 10, um projeto que começou como uma idéia para entusiastas e se tornou a fonte mais autorizada para classificar vetores e vulnerabilidades de ataques em aplicativos da Web.
Neste artigo, analisaremos brevemente todas as principais vulnerabilidades da lista das 10 principais da OWASP e também veremos por que é tão importante conhecer as vulnerabilidades típicas para desenvolver aplicativos seguros.
Cerca de 10 anos atrás, uma pessoa muito observadora formulou um novo mantra - o HTTP é um novo TCP. Obviamente, não no sentido em que a pessoa decidiu colocar HTTP no nível de transporte. De jeito nenhum! Apenas para comunicações modernas, o protocolo HTTP desempenha a mesma função que o TCP em seu nível - a grande maioria dos aplicativos modernos, incluindo os móveis, usa o HTTP como transporte. E com o advento do HTTP 2.0, essa situação se bronzeava e, no futuro próximo, aparentemente não mudaria. O protocolo se tornou o padrão de entrega de conteúdo de fato e o HTTP não pode mais ser visto como um protocolo da Web.
Pode parecer que o HTTP sempre existiu, e isso é quase verdade quando você considera que a primeira especificação oficial na RFC apareceu em 1997, embora o próprio protocolo tenha começado a ser usado muito antes.
Demorou um pouco de tempo para entender que, assim que o protocolo se tornar popular, todos começarão a usá-lo para entregar conteúdo, geralmente sem qualificações adequadas. E o resultado será centenas de milhares de sistemas vulneráveis em todo o mundo e perspectivas vagas para remediar a situação.
No caso de decisões de fornecedores específicos, você sempre pode recorrer aos materiais dele ou perguntar diretamente: "qual é a melhor maneira de agir?" - e obtenha uma resposta qualificada, porque no final apenas o fornecedor é responsável por seu produto. Quando se trata de usar padrões e ferramentas abertos para a criação de aplicativos, é necessária uma fonte imparcial de informações sobre as melhores práticas. Essa fonte pode ser entusiastas, ou talvez uma comunidade inteira de profissionais nesse campo.
Vespa voando
No campo da segurança de aplicativos da Web, o OWASP (Projeto de Segurança de Aplicativos da Web Abertos) se tornou uma comunidade. Obviamente, a OWASP é uma organização sem fins lucrativos não afiliada a nenhuma empresa de tecnologia. Essa situação permite que você forneça informações práticas imparciais sobre tecnologias de proteção de aplicativos da Web para organizações, instituições educacionais, serviços governamentais e até indivíduos interessados no problema.
Então, o que exatamente a OWASP está fazendo? Dentro de sua competência, a OWASP tem duas tarefas principais: produzir documentação e fornecer ferramentas, e absolutamente de graça.
Nesta série de artigos, analisaremos, talvez, o material mais popular OWASP TOP 10 Project. Este é um documento que lista os riscos mais significativos e críticos de aplicativos da web. A decisão de incluir vulnerabilidades nesta lista é baseada na opinião de especialistas em segurança da informação de todo o mundo (onde sem ela) e, em geral, o entendimento dessas vulnerabilidades é o primeiro passo para mudar a cultura do desenvolvimento de software.
Você precisa entender claramente que, em regra, todas essas vulnerabilidades não se baseiam nos erros de programadores específicos ou nas próprias vulnerabilidades dos protocolos, mas nos problemas de arquitetura do design de software.E para iniciantes, essa lista é estritamente necessária para estudar!
Dez feitiços mortais
A lista de vulnerabilidades é atualizada constantemente e, para 2017, é a seguinte:
• A1: 2017 - injeções, também conhecido como “injeção de código”
Estamos falando de todos os tipos de injeções: SQL, NoSQL, LDAP - qualquer coisa. A injeção de código se torna possível quando dados não verificados são enviados ao intérprete como parte de um comando ou solicitação. Essa solicitação "maliciosa" é executada com segurança e causa dano próprio. Em 90% dos casos, quando você ouve que um banco de dados privado foi acessado via web, esse é apenas o nosso A1.
• A2: 2017 - autenticação incorreta
As funções de aplicativo responsáveis pelo gerenciamento de autenticação e sessão são frequentemente usadas incorretamente, o que implica o comprometimento de senhas, chaves, tokens de sessão e até a capacidade de interceptar completamente uma sessão do usuário. Quando você se senta no wifi público e descobre subitamente que algumas ações estão sendo executadas em seu nome em recursos públicos da Web - este é o A2.
• A3: 2017 - Divulgação de informações confidenciais
Muitos aplicativos da Web e APIs podem armazenar e processar incorretamente informações confidenciais, como dados pessoais. Os invasores podem roubar ou alterar essas informações, que podem se tornar a base para sérias perdas financeiras ou de reputação. Informações sensíveis devem ser armazenadas adequadamente e também protegidas durante a transmissão pelos canais de comunicação.
• A4: 2017 - Implementação de entidades XML externas (XXE)
Muitos processadores XML antigos ou configurados incorretamente podem usar dados externos de links em arquivos XML. Esses dados externos podem conter código malicioso que permitirá a execução de praticamente qualquer código estranho na máquina de destino.
• A5: 2017 - Controle de acesso violado
A matriz de acesso, que era tão boa no papel, pode ser testada incorretamente em um sistema específico, para que usuários ilegítimos acessem facilmente áreas fechadas de sites ou tenham a oportunidade de alterar os direitos de recursos a seu critério.
• A6: Configuração incorreta da segurança de 2017 - erros na configuração
Aqui estamos falando de mais algumas coisas globais, como a falta de atualizações oportunas de software para servidores e aplicativos, a presença de informações importantes em mensagens de erro ou mesmo em cabeçalhos HTTP. O aplicativo pode ser quase perfeito, mas se o servidor da Web em que está sendo executado tiver problemas com a configuração básica, tudo será inútil.
• A7: 2017 - Crossite Scripting (XSS)
O XSS ocorre quando um aplicativo inclui dados não confiáveis sem verificação adequada. Por exemplo, o código do programa de um banner de publicidade pode conter um script para interceptar dados do usuário, a face do site ou até mesmo redirecionar de forma transparente para outros sites.
• A8: 2017 - Desserialização insegura
A desserialização insegura geralmente leva à execução remota de código. O ponto principal é que dados não confiáveis podem destruir a lógica do seu aplicativo assim que eles são desserializados. Uma vulnerabilidade bastante exótica à primeira vista, no entanto, ocupa seu lugar de honra na lista.
• A9: 2017 - Usando componentes com vulnerabilidades conhecidas
Bibliotecas, estruturas, sistemas operacionais e outros componentes de sistemas de informação precisam ser atualizados em tempo hábil. Caso contrário, uma vulnerabilidade conhecida em uma biblioteca pode comprometer um serviço grande que usa pelo menos uma função de uma biblioteca vulnerável.
• A10: 2017 - registro e monitoramento inadequados
Tudo é simples aqui - você construiu um sistema maravilhoso, mas esqueceu de apertar as ferramentas de monitoramento. Não se trata apenas de um sistema SIEM conectado, mas simplesmente do log banal dos principais eventos do servidor. Infelizmente, não é incomum quando os sistemas de hackers são notados seis meses após o próprio hacking, e eles aprendem sobre isso não pelos logs, mas por observadores externos.
Nos artigos a seguir, começaremos a analisar mais detalhadamente cada uma dessas vulnerabilidades. Vamos nos armar com as ferramentas necessárias e ver como essas vulnerabilidades são implementadas na prática.
Preparado por
Sergey Polunin .