Как защитить запрос от изменения?

Question

[lUser L]

Как защититься от изменение запроса.
Например есть вот

такой

блок с data-id он отправляет в базу id и выводит запись. Но если пользователь изменит его через код-элемента например id 274 на 666 то выведется запись 666. Как сделать так, что бы запрос выводил 274 а не 666
В интернетах это называется CSRF но на большинство сайтов пишут про уязвимость и про то, что мол очень серьезно а не то как ее предотвратить

Comments

[Дмитрий]

Изменит? Если вы про панель разработчика, то вроде как там редактируется готовый DOM

[Orbb]

Дмитрий, можно любой запрос изменить и отправить, в т.ч. если идет привязка элементов к дом - можно изменить элемент и какой-нить жквери подвоха не заметит

[lUser L]

Дмитрий, на сайте выводится кнопка с id если нажать на нее отправляется ajax запрос на страницу content.php например.
Как видишь на скрине ссылку с data-id если на нее нажать то на content.php отправиться id274 но если я изменю через панель разработчика id274 на 555 то отправиться 555. Вопрос и был в том , как мне сделать так, что бы пользователь не мог изменить атрибут data-id

[Nujabes37]

Эмиль Гасанов, никак, все проверки надо делать через back.

[edward_freedom]

Эмиль Гасанов, а зачем это нужно? Пусть меняет пользователь что хочет, ничего это не изменит

[alex-1917]

это сродни защите от копирования текста страницы... бгг

Answer 1

[Narts]

Решение очень простое
Создаем две функции: cryptID и decryptID, которые шифруют и дешифруют ID. Пользователю отдаем зашифрованный ID, типа:
data-id="wallId_G5ht3Q"
Далее когда пользователь отправляет запрос, получаем G5ht3Q, расшифровываем его, и проверяем, существует ли запись с таким ID

Comments

[Randewoo]

Интересная идея, кстати)

[alex-1917]

Randewoo, интересная-то интересная, но чего ради таки не ясно. то ли у автора бекенд сделан криворучкой, по видеогайдам и тогда через публичный пост можно будет в БД удалять что хошь , то ли он что-то задумал...)))

Answer 2

[FanatPHP]

О господи, опять этот вопрос.

Запрос никак не защищать.
Если пользователь может видеть запись 666, то пусть смотрит что хочет.
Если пользователь не имеет права видеть запись 666, то получив любой запрос проверять его на наличие прав. А изменение запроса оставить в покое. Клиент по определению может отправить любой.

К CSRF это абсолютно безобидное ковыряние в хтмлочке никакого отношения не имеет.

Answer 3

[Orbb]

если это только гет - то пусть гетит себе на здоровье. С лимитом на запросы, не более 20 в минуту, например. А на update-delete-create, конечно, проверка прав и CSRF.

Comments

[alex-1917]

А на update-delete-create, конечно, проверка прав

в большинстве видеогайдов этот вопрос не разжеван)))