ActiveRecord безопасность поля ID

[IIIKET]

Доброго дня.

Расскажите пожалуйста безопасны ли модели в Yii2 и как это реализовано.

Если я правильно понял логику ActiveRecord, то при создании модели она получает schema таблицы к которой привязана.
А мы в своих моделях грубо говоря переопределяем геттеры и сеттеры.

Допустим:
Я хочу обезопасить поле ID (Выдуманый случий. Я отправляю форму в которой лежит hide/readonly id. Если кто то с помощью JS или просто ручками его поменяет, то контролер примет не коректные данные и вкинет их в load). Таким образом если я редактированию запись id = 2 и ручками поставлю id = 1, то при сохранении я перетру все данные в 1 записи.

Как от этого защитится?

[maleks]

Это все уже решено. load только безопасные атрибуты присваивает

[IIIKET]

Это все уже решено. load только безопасные атрибуты присваивает

Если Вы разобрались можете рассказать о самом принципе? Как это работает?

[yan]

Таким образом если я редактированию запись id = 2 и ручками поставлю id = 1, то при сохранении я перетру все данные в 1 записи.

Как от этого защитится?

с id = 1 не должно редактироваться? тогда сами проверяйте и делайте ограничения, фреймворк не знает как вы хотите ограничить редактирование по ид

[ElisDN]

Если Вы разобрались можете рассказать о самом принципе? Как это работает?

Метод load() из формы присваивает только те атрибуты, которые присутствуют в rules().

[yan]

Если Вы разобрались можете рассказать о самом принципе? Как это работает?

Метод load() из формы присваивает только те атрибуты, которые присутствуют в rules().

судя по описанию id должно загружаться, иначе не понятно, что именно редактируем

[ElisDN]

Поле id обычно GET-параметром в адресе передают или из Yii::$app->user->id берут, так что смысла в hidden его держать нет никакого.

[IIIKET]

Поле id обычно GET-параметром в адресе передают или из Yii::$app->user->id берут, так что смысла в hidden его держать нет никакого.

Вы не до конца поняли о чем я говорю.
Допустим я пишу CMS. В ней есть редактор страниц, доступный из админки. Когда в админке модератор кликает по редактировать он оказывается на странице с формой. Там много всяких полей (content, title, keywords etc.), которые передадутся POST-ом.
Одно из этих полей это id - страницы которую мы редактирываем, обычно это

Код: Выделить всё

type="hidden" 

.
Так вот, если я жмякну F12 могу написать туда id любой другой страницы.

Вот от чего я спрашиваю как защитится.

[zelenin]

Поле id обычно GET-параметром в адресе передают или из Yii::$app->user->id берут, так что смысла в hidden его держать нет никакого.

Вы не до конца поняли о чем я говорю.
Допустим я пишу CMS. В ней есть редактор страниц, доступный из админки. Когда в админке модератор кликает по редактировать он оказывается на странице с формой. Там много всяких полей (content, title, keywords etc.), которые передадутся POST-ом.
Одно из этих полей это id - страницы которую мы редактирываем, обычно это

Код: Выделить всё

type="hidden"

.
Так вот, если я жмякну F12 могу написать туда id любой другой страницы.

Вот от чего я спрашиваю как защитится.

вам и сказали - id берется из $_GET и не фигурирует в форме.

[ElisDN]

Одно из этих полей это id - страницы которую мы редактирываем, обычно это type="hidden"

В админке по ссылке редактирования /admin/post/update?id=5 попадаем на actionUpdate($id). Как в стандартном CRUD, сгенерированном в Gii. А какой смысл здесь выводить в hidden и защищать id?

[zabachok]

Я так понимаю, что ТС боится изменения айдишника в гете или в скрытом поле. Типа нажал редактировать пост с айдишником 1, поправил в урле на 2 и редактируешь пост с айдишником 2. Если так, то никаких уязвимостей тут нет. Пользователь может редактировать пост 1 и также пост 2.
Если вы боитесь, что пользователь редактируя пост 2, когда редактирует 1 таким хакерским(кек) приемом, то используйте рбак. Это подойдет вам в том случае, если этот пользователь не должен иметь доступа на редактирование поста 2.

[zelenin]

все данные, которые мы отдаем на клиент, можно на клиенте отредактировать. Все проверки должны быть на сервере.
В случае конкретно с id, id на клиент не отдаем. В случае от zabachok - rbac.

[IIIKET]

Я так понимаю, что ТС боится изменения айдишника в гете или в скрытом поле. Типа нажал редактировать пост с айдишником 1, поправил в урле на 2 и редактируешь пост с айдишником 2. Если так, то никаких уязвимостей тут нет. Пользователь может редактировать пост 1 и также пост 2.
Если вы боитесь, что пользователь редактируя пост 2, когда редактирует 1 таким хакерским(кек) приемом, то используйте рбак. Это подойдет вам в том случае, если этот пользователь не должен иметь доступа на редактирование поста 2.

Спасибо за ответ. Вы меня поняли в полной мере.

Но тут такое дело, что кто то может это сделать случайно "играясь". А возможно у кого то будет вредоносный плагин в браузере.

[ElisDN]

Но тут такое дело, что кто то может это сделать случайно "играясь". А возможно у кого то будет вредоносный плагин в браузере.

И что в этом вредоносного?

[zabachok]

В этом нет ничего вредоносного. Вы даете пользователю редактировать контент(заголовок поста, его контент, анонс, теги и пр.). Если вы считаете, что он вписал туда что-то не то, то надо с ним поговорить, отредактировать этот пост или заблокировать. С точки зрения программы тут нет уязвимости.

[caHek2x]

суть не в модели и не в фреймворке ...
человек может заменить передаваемые на сервер параметры ...
но если вы ему дали право на редактирование записи то он её редактирует ...
если он может редактировать запись 1 но не может редактировать запись 2 то то что он откроет запись 1 а потом отправит в параметре ид2 это ничего не поменяет т.к. при сохранении вы еще раз проверите на его права ...

[IIIKET]

Суть не в человеке. Суть в плагине установленном в браузере.

Думаю можно закрывать.

[zabachok]

А причем тут плагины браузера?

[IIIKET]

А причем тут плагины браузера?

Сидит у Вас в офисе блондинка. Которая целими днями раскладывает пасьянсы и копи пастит вычитанные тексты в админку.
При этом может жмякать на любые кнопки. Установила она как то раз себе плагин. Который вывел production сайт на несколько часов из строя (пока поднимались бэк апы).

А за несколько часов до этого, проводилась рекламная компания с затратами финансов. И потенциальный клиент приходящий на сайт увидил белые страницы. Сомневаюсь что он когда либо захочет вернутся.

[zelenin]

А причем тут плагины браузера?

Сидит у Вас в офисе блондинка. Которая целими днями раскладывает пасьянсы и копи пастит вычитанные тексты в админку.
При этом может жмякать на любые кнопки. Установила она как то раз себе плагин. Который вывел production сайт на несколько часов из строя (пока поднимались бэк апы).

А за несколько часов до этого, проводилась рекламная компания с затратами финансов. И потенциальный клиент приходящий на сайт увидил белые страницы. Сомневаюсь что он когда либо захочет вернутся.

вы сказали все про блондинку, но ничего про разработчика, который оставил некие дыры (а это даже не дыры, а просто непредусмотренная фича) на сайте, выведя тем самый продакшн на несколько часов.
Еще раз - проверки должны быть на сервере, а не на клиенте.