Как логически организовать защиту от удаления чужих записей?
Привет!
Подскажите, пожалуйста, как обычно организовывается защита данных пользователей друг от друга?
Текущий пример-
Есть регистрация пользователей. У каждого есть свои записи в админке. Все сохранено в базе данных
Есть кнопка удаление записи.
Технически удаление записи происходит так:
JS скрипт берет ID удаляемой записи из верстки и отправляет его с помощью POST в PHP файл без перезагрузки страницы. Запись удалена.
Как можно "напакостить":
- В верстке вручную ставим любой ID записи и нажимаем удалить. И чужая запись удалена.
- Если сделать проверку ID пользователя + ID записи, совпадает = удаление. НО можно просто брутом через POST прогнать каждый ID пользователя и по 1000 записей по порядку. В итоге все равно будет попадание и записи удалятся.
Если придумывать генерацию пользователям и записям уникальные скрытые ключи и делать проверку на совпадение?
Однако, если пользователей сто тысяч, то наверняка будут совпадения в генераторе ключей и возникнет конфликт
Как обычно организовывают такие связи?
Мне бы просто логически понять.
В таких делах новичок.
Есть такая штука - авторизация, и есть такое понятие как овнершип (владение) и ACL/RBAC. Во всех скриптах проверяется кто владелец файла, или кто может его изменять/удалять. Если у пользователя есть права на изменение/удаление объекта - скрипт отрабатывает, если нет - выдает ексепшн или иначе оповещает о неудачном завершении.
Mesuti, на объекты обычно. Что там за сущность абсолютно пофиг. Хоть код запуска ракет, хоть картинка, хоть запись в бд/файле. Атрибуты доступа применимы к любой описываемой сущности.
У Вас на бэкэнде пользователь остаётся залогинен даже при POST запросах из JS. В запросах на удаление указывайте только ID удаляемой записи. При его обработке, на бэке, смотрите по залогиненому пользователю, принадлежит ли ему удаляемая запись. Если да - удаляйте, нет - возвращайте сообщение об ошибке.
Вот об этом и говорил.
На бекенде если сделать проверку пользователя + его или нет запись.
То можно по порядку сделать очень много запросов
ID user 1, удалить запись 1,2,3,4...1000
ID user 2, удалить запись 1,2,3,4...1000
Так Вы не передавайте ID юзера, а вытаскивайте его из сессии или восстанавливайте по токену. Зависит от того, как у вас авторизация устроена.
В таком случае злоумышленник сможет выполнить запрос на удаление чужой записи только если угонит сессию\токен жертвы. Чтобы себя обезопасить - используйте https.
Mesuti, С тем же (а то и большим) успехом можно увести логин и пароль.
Если взять, например, JWT, то открытая часть токена защищается цифровой подписью, проверить которую можно только зная ключ, использованный при выдаче токена.
Кроме того, токен имеет срок жизни, от десятков минут до нескольких часов. Часто вместе с основным токеном выдаётся одноразовый для смены пары после истечения срока жизни основного.
Mesuti, я не понимаю ничего
ты какую-то дичь втрираешь
какие множественные запросы?
у тебя в базе должен быть уникальный ID пользователя.
у любой сущности, создаваемой пользователем, должен быть прописан этот User_ID
в чем сложность
- получить сущность по ID
- проверить ее User_id с ID текущего авторизованного пользователя
- если совпадает - удалить
?
С сессиями не знакомы? Ну или как вас админка организована? И как вы умудрились сделать регистрацию пользователей если потом у вас такие странные вопросы возникают.
Регистрация с помощью RedBeanPHP.
Казалось бы все просто, но вот натолкнулся на "дыры" и требуется доделывать.
А проект коммерческий секретный, нормальных PHP прогеров не подключить(
Средний
