Pergunta de segurança: Como proteger as coleções de hibernato que voltam do cliente para o servidor?

Question

Eu tenho um pojo simples chamado "Parent", que contém uma coleção de objeto "Child".

No Hibernate/JPA, é simplesmente uma associação individual, os filhos não conhecem seus pais: esses objetos infantis podem ter um tipo diferente de pai, para que seja mais fácil conhecer os pais (pense no filho que representa tags e pais podem ser diferentes tipos de objetos que têm tags).

Agora, envio meu objeto pai para a visualização do cliente do meu site para permitir que o usuário o modifique.

Para isso, eu uso o Hibernate/GWT/Gilead.

Meu usuário acaricia algumas alterações e clique no botão Salvar (AJAX), que envia meu objeto pai para o servidor. Os campos dos meus pais foram modificados, mas mais importantes, alguns objetos infantis foram adicionados ou excluídos na coleção.

Resumo, quando o objeto pai volta ao servidor, agora ele tem em sua coleção: - novos objetos "filho" onde o ID é nulo e precisa ser persistente - objetos "filho" modificados, onde o ID não é nulo e precisa ser mesclado - Objetos "filho" potencialmente invadidos onde o ID não é nulo, mas não são originalmente de propriedade dos pais - objetos filhos ausentes (excluídos): Precisa ser excluído

Como você salva o objeto pai (e sua coleção)? Você carrega a coleção pai do banco de dados para comparar cada objeto da coleção modificada para ver se não há item hackeado? Você limpa a coleção antiga (para remover órfãos) e adicionar nova criança (mas há alguma criança que não foi modificada)?

obrigado

PS: Desculpe pelo meu inglês, espero que você entenda o conceito;)

Answer 1

A melhor solução que encontrei é gerenciar um DTO, criado manualmente. O DTO envia apenas dados necessários para o cliente. Para cada campos que quero definir no modo ReadOnly, calcule uma assinatura com base em uma chave secreta que envio ao cliente com meu DTO.

Quando meu DTO volta ao servidor, verifico a assinatura para ter certeza de que meus campos de leitura não foram alterados (recalcule a assinatura com os campos de volta e compare -o com a assinatura voltando com o DTO)

Isso me permite especificar apenas campos de leitura e verifique se meus objetos não foram invadidos.

Answer 2

Algo em sua pilha precisa fornecer a lógica de que você está falando e, dadas as suas circunstâncias, provavelmente é você. Você precisará obter o estado atual do objeto, lendo sua fonte de dados para poder fazer a comparação. Lembre-se de que, se várias ações legítimas puderem atualizar seu objeto pai e sua coleção simultaneamente, você precisará cuidar muito de definir o grão de transação e a natureza segura por threads do seu código.

Este não é um problema simples, de forma alguma e pode haver recursos de estrutura que possam ajudar, mas ainda estou para encontrar algo que resolveu isso para qualquer implementação do mundo real que encontrei, especialmente onde tenho lógica que tentou distinguir entre dados legítimos e "hackeados".

Você pode considerar alterar sua arquitetura para que os pais e os filhos sejam persistidos em ações separadas. Pode não ser apropriado no seu caso, mas você pode ter um grão mais fino de transação, dividindo as ações de persistência e fornecendo segurança orientada para a criança, o que torna o seu problema de invadir um pouco mais gerenciável.

Boa sorte. Eu recomendo que você desenhe um fluxograma detalhado da sua lógica antes de fazer muita codificação.