Вопрос безопасности: как защитить коллекции Hibernate от клиента на сервер?

Question

У меня есть простое pojo с именем «Родитель», которое содержит коллекцию объекта «Ребенок».

В hibernate/jpa это просто ассоциация «один-ко-многим», дети не знают своего родителя: у этих дочерних объектов может быть другой тип родителя, поэтому легче не знать родителя (подумайте о ребенке, который представляет теги и родители могут быть разными типами объектов, которые имеют теги).

Теперь я отправляю объект родительского объекта на клиентский вид моего веб-сайта, чтобы разрешить пользователю его изменять.

Для этого я использую Hibernate/GWT/Gilead.

Мой пользователь внес некоторые изменения и нажмите кнопку сохранения (ajax), которая отправляет мой родительский объект на сервер. поля моего родителя были изменены, но более важны, некоторые дочерние объекты были добавлены или удалены в коллекции.

Для резюме, когда объект Родителя возвращается на сервер, теперь он имеет в своей коллекции: - новый «ребенок» объекты, где идентификатор утративший должен быть сохраняться - модифицированном «ребенок» объектов, где идентификатор не является нулевым и должны быть слияние - потенциально взломанные «ребенок» объекты, где идентификатор не является нулевым, но изначально не принадлежат Материнской - дочерние объекты отсутствуют (удалены): необходимо удалить

Как сохранить родительский объект (и его сбор)? загружаете родительскую коллекцию из базы данных, чтобы сравнить каждый объект измененной коллекции, чтобы увидеть, нет ли взломанного элемента? Вы очищаете старую коллекцию (для удаления сироты) и повторно добавляете нового ребенка (но есть какой-то ребенок, который не был изменен)?

благодаря

PS: Извините за мой английский, я надеюсь, что вы понимаете концепцию;)

Answer 1

Лучшее решение, которое я нашел, это управлять созданным вручную DTO. DTO отправляет только нужные данные клиенту. Для каждого поля, которое я хочу установить в режиме ReadOnly, я вычисляю подпись на основе секретного ключа, который я отправляю клиенту с помощью моего dto.

Когда мой DTO возвращается на сервер, проверить подпись, чтобы убедиться, что мои чтения только поля не изменились (пересчитать подписи с возвратом поля и сравнить ее с подписью возвращающейся с DTO)

Это позволяет мне указывать только поля для чтения и быть уверенным, что мои объекты не взломаны.

Answer 2

Что-то в стеке должен поставить логику вы говорите, и, учитывая ваши обстоятельства это, вероятно, вы. Вам нужно будет получить текущее состояние объекта, прочитав его с вашего источника данных, чтобы вы могли выполнить сравнение. Имейте в виду, что если несколько законных действий могут одновременно обновлять родительский объект и его коллекцию, вам нужно будет проявлять большую осторожность при определении размера транзакционного зерна и потокобезопасности вашего кода.

Это не простая проблема, и могут быть возможности, которые могут помочь, но мне еще предстоит найти что-то, что разрешило это для любой реальной реализации, с которой я столкнулся, особенно когда у меня есть логика, которая пытался различать законные и «взломанные» данные.

Возможно, вы захотите изменить свою архитектуру таким образом, чтобы родитель и дети сохранялись в отдельных действиях. В вашем случае это может быть нецелесообразно, но вы можете иметь более тонкое зерно транзакции, разделив действия настойчивости и обеспечив безопасность, ориентированную на детей, что делает вашу проблему взлома более управляемой.

Удачи. Я рекомендую вам нарисовать подробную блок-схему вашей логики, прежде чем делать слишком много кодирования.