2015-08-16 2 views
0

Я новичок в Spring JPA/jHipster. Мой вопрос навеян jHipster разговора Жюльен Дюбуа: https://youtu.be/R3jm2qmqctI?t=43m7sКак предотвратить вредоносный ввод в Spring JPA + Spring REST + jHipster

Предположим, у вас есть счет в банке с операциями на нем (+ 100 $ для ресторана, -50 $ ATM, ...) Каждый банковский счет имеет владелец конечно.

Полезная нагрузка вызова POST REST, который создает операцию может выглядеть следующим образом: { "сумма": 100, "Описание": "ресторан", "ВагЛАссоипЬ": { "ID": 1136}}

Идентификатор bankaccount уникален и (ради этого примера) был бы отправлен мне ранее через другой вызов REST.

К сожалению, ничто не мешает злоумышленнику изменить это значение. Можно было просто угадать идентификатор банковского счета, принадлежащего кому-то другому, и затем операция будет добавлена ​​к этому.

Я еще не видел примеры, которые справляются с этой проблемой.
Должен ли я явно проверить, принадлежит ли банковский счет пользователю? Я предполагаю, что этот тип проверки может каскадироваться через все ваши сущности, вызывая много дополнительных вызовов. Может, мне что-то не хватает?

Спасибо, Энди

+0

Нашел интересную статью, которая поддерживает мои заботы;) у нее даже есть имя, это называется прямой ссылкой на объект или атаку DOR: http://www.jtmelton.com/tag/direct-object-reference/ –

ответ

0

Да это ваш страх и риск, чтобы проверить в контроллере REST или базовых услуг, которые разрешается операция. Spring security предлагает d ifferent mechanisms to do it, в частности, используя @PreAuthorize и @PostFilter.

Также полезно использовать DTO, таким образом вы можете лучше контролировать, какие поля ваших объектов открыты для чтения и записи через API.

+0

Спасибо, что нашли время ответить. Это помогает. Я был бы признателен, если бы вы могли указать мне на некоторые реальные примеры (на GitHub, ...) Я все еще думаю, что я что-то упустил или, если нет, я считаю, что в дикой природе есть много уязвимых приложений, которые имеют игнорируются для выполнения этих проверок. –

+0

Разрабатывая это немного подробнее ... Предполагая, что у нас есть 3 объекта A, B и C. A имеет поле владельца (со ссылкой на объект пользователя), а также набор B. B имеет указатель на A, а также набор C. C имеет указатель на B. Таким образом, это иерархия. Как указывалось ранее, все запросы могут быть изменены. Так было бы правильно/необходимо (!) Сделать это в методе create (конечная точка REST) ​​C (в псевдокоде)? 0_'entityC.getEntityB(). GetEntityA(). GetOwner(). Equals (currentUser)' Если нет, возможно, я догадался, что идентификатор B принадлежит другому пользователю, не так ли? –

+0

RIght, еще одна возможность - открыть идентификаторы, которые имеют смысл только для текущего пользователя. Поэтому, если пользователь владеет 3 учетными записями, идентификатор учетной записи 1 будет ссылаться только на одну из его учетных записей, и это легко сделать с использованием DTO. –

Смежные вопросы