Como as tecnologias de desenvolvimento rápido podem se tornar uma fonte de vulnerabilidades desagradáveis

A segurança com exemplos da vida real é sempre mais interessante.

Como testador de penetração, adoro quando projetos baseados em estruturas de desenvolvimento Rapid são lançados, como Ruby-on-Rails, Django, AdonisJs, Express e assim por diante. Eles permitem que você construa um sistema muito rapidamente devido ao fato de que os modelos de negócios saltam imediatamente para todos os níveis, incluindo o navegador do cliente. Tais estruturas de modelo (modelos de objetos de negócios no banco de dados) e ViewModel (contrato para interagir com clientes) são frequentemente combinadas para evitar a mudança desnecessária de Model para ViewModel e vice-versa, os serviços REST são gerados automaticamente. Do ponto de vista do desenvolvimento, você pode simplesmente desenvolver um modelo de negócios no servidor e usá-lo imediatamente no cliente, o que sem dúvida aumenta a velocidade do desenvolvimento.

Mais uma vez, não estou dizendo que as estruturas mencionadas acima são ruins ou que há algo errado com elas; elas têm os meios e as ferramentas de proteção adequada; é só que os desenvolvedores cometem mais erros com elas. Isso também foi visto em um projeto do ASP.NET MVC, no qual os desenvolvedores criaram as mesmas vulnerabilidades, expondo Models em vez de ViewModels ...

Vulnerabilidade: devido à fraca validação dos campos dos modelos recebidos do cliente, é possível injetar campos que não são fornecidos pela funcionalidade, mas estão no modelo de negócios. Por exemplo, existe um método que permite alterar apenas o nome de usuário e retorna um objeto de perfil de usuário. E se eu copiar o objeto retornado, alterar todas as propriedades nele e enviá-lo novamente para a entrada? Pode acontecer que você possa alterar qualquer propriedade do objeto (senha, função), ignorando o fluxo de trabalho padrão.

Dos vários projetos que testamos em termos de segurança, darei exemplos reais. Todas essas áreas problemáticas foram corrigidas e qualquer informação extra nas capturas de tela está oculta.

Sistema 1

Nesse sistema, apenas o nome do usuário pode ser alterado no perfil. Substituindo outro email, consegui alterar o login do usuário. Além disso, convites para outros usuários deixaram esse sabão.



Sistema 2

Neste exemplo, um usuário simples conseguiu alterar a função para o administrador adicionando o campo de funções e, por url / admin, basta abrir o painel de administração do sistema com todas as transações, usuários, relatórios e assim por diante.



Sistema 3

Nesse sistema, foi possível renovar uma assinatura gratuita por tempo indeterminado. É claro que a abordagem padrão exigia que houvesse pagamento.



Parece que o método de entrada pegaria apenas a cor selecionada de acordo com a marca da área de trabalho e retornaria o objeto de toda a área de trabalho, incluindo um dump completo do objeto StripeCustomer, que refletia o pagamento. Foi possível inserir não apenas um campo, mas um enorme subobjeto StripeCustomer e, como resultado, pagar uma vez ou de outro usuário para capturar esse objeto e duplicá-lo em todos os seus espaços de trabalho.



Sistema 4

E finalmente Esse sistema tinha o mesmo problema: era possível alterar a senha e a senha ignorando o fluxo de trabalho inventado. A falta de proteção contra o CSRF e o armazenamento de cookies de autenticação por um longo período aumentaram o risco dessa vulnerabilidade para o céu. Um usuário mal-intencionado pode colocar um script em um recurso popular solicitando alterar a senha do usuário atual deste sistema, e todos os usuários que abrirem esse recurso perderão o acesso ao sistema.



Ocultar no código do servidor nos metadados desse campo, possibilitou não retornar esse campo ao cliente na resposta, mas esse campo foi processado sem problemas nos dados de entrada.



A mensagem:

1. Nunca confie nos dados recebidos dos usuários, eles podem fazer qualquer coisa com eles
2. Cuidado com sistemas que não possuem uma camada separada do ViewModel-s e trabalhe diretamente com os modelos básicos
3. Explore com mais detalhes as proteções que sua estrutura oferece.

As informações acima são fornecidas apenas para fins educacionais e educacionais, não é necessário executar seus sistemas.

Denis Koloshko, Testador de penetração, CISSP