Как запретить локальное редактирование input значения перед отправкой формы?

Question

[Роман]

Имеем обычную POST форму

<form action="test.php" method="POST">
<input type="hidden" value="id" value="1">
<input type="submit" name="submit" value="POST">
</form>

В общем при отправке в $_POST мы должны строго получать ид=1 т.к. пользователь не видит этого инпута и в теории даже не знает о его существование. Но Если открыть консоль браузера и в ручную изменить код инпута, к примеру на value=2222
То и POST спокойно отправит это значение. Так же с disabled элементами и тд. По сути можно хоть как обманывать POST. Есть ли какое-то решение этой ситуации?) Простите если вопрос вдруг глупый, но что-то не надумал ничего)

Answer 1

[ThunderCat]

Непреложная истина: Все что находится на/приходит с клиента может и будет изменено с целью взлома/вреда.

Защищать что-либо на фронтэнде абсолютно нет смысла, все проверки делаются на сервере.

Если открыть консоль браузера и в ручную изменить код инпута, к примеру на value=2222
То и POST спокойно отправит это значение.

Ваша задача проверить имеет ли клиент право на изменение объекта с данным значением. Остальное не особо важно, даже если он подставил это значение руками.

Answer 2

[vdem]

Сохранять нужное значение в сессии ($_SESSION) и при отправке формы брать его из сессии, а не формы.
P.S. Только не забыть сделать session_start() до какого-либо вывода в PHP.

Comments

[ThunderCat]

какой замечательный способ навести бардак в админке, лайк!

Answer 3

[AUser0]

Если нужно передать какие-то данные немодифицируемыми - шифруйте их на сервере, запихивайте в форму, при получении данных формы - расшифровывайте и пользуётесь неизменёнными данными. Вуаля, профит!

Но есть способ проще и лучше - храните данные в сессии на стороне сервера, а клиенту передавайте только ID этой сессии, и пускай пытается что-нибудь модифицировать...

Comments

[ThunderCat]

Ваще шикос, особенно когда редактируешь 2-3 сущности в разных вкладках. Хотя можно просто включить мозг, профита будет на порядок больше.

Answer 4

[Роман]

ну я к примеру привел скрытую форму. Допустим возьмем select с разными опциями. Что помешает вместо г.Барнаул написать, что-то плохое и отправить в базу?) В таком случае конечно да, можно на беке проверять есть ли вообще такое слово и кидать ошибку при его отсутствие. Вообще стараюсь такие вещи избегать и как раз все проверять на серверной части, но просто стало интересно, вдруг есть какие-то способы стандартные) В общем вопрос по большей степени для саморазвития.
А если у нас список того, что в форме формируется динамично, прям в момент загрузки страницы. Допустим мы не заполняем шаблонную форму логина и пароля, а формируем какой-то отчетный шаблон.
Мол из базы достаем список индикаторов и для них выводим строки. Тогда удобно скрытым полем списывать ИД индикатора, что бы в дальнейшем обрабатывая понимать, что работаем именно с ним.

Comments

[ThunderCat]

Что помешает вместо г.Барнаул написать, что-то плохое и отправить в базу?

Если у вас в базе хранятся текстовые имена городов - у меня для вас плохие новости. Должен передаваться идентификатор. И да, его надо проверять на существование.

вдруг есть какие-то способы стандартные

Есть конечно. Создается сущность из идентификатора, и если она не пустая - все ок. В некоторых случаях (на самом деле довольно часто) нужно проверять разрешено ли модифицировать данную сущность данным пользователем.

[Роман]

ThunderCat, не, у меня слава богу все хранится в связке Ид и наименование) и работаю исключительно с ИД. А потом по ИД вытаскиваю название города и если ид поменять, то пользователь просто пропишет себя в другом городе (по сути он может это и так сделать тупо выбрав в селекте другой регион). А если нет ИД, то извините и запись не запишется)