#php #jquery #post
#php #jquery #Публикация
Вопрос:
Я использую вызовы jquery POST для извлечения данных для отображения в различных разделах моих веб-сайтов.
Обычно они ПУБЛИКУЮТ на одном ‘ajax_handler.php ‘ страница, которая считывает запрошенные параметры и возвращает соответствующие данные. Типичными параметрами могут быть ‘get_order_details’,123
Как я мог бы запретить пользователям отправлять сообщения в скрипт, чтобы попытаться извлечь данные, которые они не должны иметь возможности? Я знаю, что могу проверить, принадлежат ли данные, например, текущему авторизованному пользователю, но как я мог бы помешать пользователям «догадываться», что может существовать обработчик для ‘get_some_info’?
Поскольку пользователи могут даже запускать javascript прямо с URL-адреса, мне кажется, это серьезная проблема безопасности, поскольку клиент будет иметь доступ к данным сеанса и COOKIE (которые я бы в противном случае использовал для безопасности).
Думаю, я мог бы начать с присвоения каждому из моих идентификаторов обработчика имени случайной строки, но я бы предпочел не ставить под угрозу разборчивость моего кода.
Ответ №1:
Присвоение имен вашим обработчикам со случайной строкой — это защита от неизвестности, и хотя это может замедлить работу кого-то, это не остановит их.
Лучшее, что можно сделать, это сохранять контрольную сумму сеанса или базы данных при каждом обращении к странице. Затем также отправьте ту же контрольную сумму вместе с содержимым POST. Когда форма отправлена, через AJAX или иным способом, вы сравниваете контрольные суммы. Если они не совпадают, то вы знаете, что пользователь не был на соответствующей странице и пытается получить доступ к обработчику каким-либо другим методом.
Комментарии:
1. Я читал об этих «токенах аутентификации», но если пользователь запускает javascript через адресную строку, токен аутентификации будет передаваться / доступен точно таким же образом, что делает его избыточным. Если я чего-то не понимаю?
2. Это дерьмовая вещь для ваших пользователей, и это не то, как должен работать Интернет. Это также защита через неизвестность, поскольку пользователь может легко увидеть любую «контрольную сумму», которую вы предоставляете с каждым запросом…
3. @cusimar9 — нет, им пришлось бы сначала загрузить соответствующую страницу, чтобы получить токен. Да, они могут перейти на страницу, просмотреть исходный код, получить токен, но в этот момент какое значение имеет, отправят ли они запрос, введя его в адресной строке? Этот метод предотвращает «горячую ссылку» на запрос. Чтобы это сработало, вам необходимо повторно создавать параметр для каждого запроса. Таким образом, если у них есть доступ к определенному идентификатору базы данных, они все равно могут получать каждый идентификатор, но не автоматическим способом, по крайней мере, им приходится загружать всю страницу каждый раз.
4. @meagar — что за глупое заявление. Я полагаю, вы думаете, что мы должны избавиться от паролей и учетных записей и просто позволить каждому ссылаться на любые данные, которые они хотят. Это должно быть прозрачно для законного пользователя, но не позволять нечестивому пользователю получать данные, которые ему не положены. Или, что еще хуже, гнусный человек, создающий ссылку или изображение и делающий всевозможные неприятные вещи с учетной записью пользователя без их ведома. Атаки Google XSRF
5. Нет, я конкретно выступаю в пользу паролей и учетных записей. Пока пользователь аутентифицирован, попытки контролировать, как он получает доступ к своим данным, бесполезны.
Ответ №2:
Для каждого пользователя вы можете хранить в своей базе данных, какие данные он должен иметь возможность просматривать, а какие нет. Каждый раз, когда вы получаете запрос, например get_order_details, вы должны вызывать функцию, которая выполняет вашу проверку безопасности, чтобы убедиться, что пользователь вошел в систему и что у него есть доступ к методу ‘get_order_details’ или любому другому методу, к которому он пытается получить доступ.
Комментарии:
1. Я знаю, что могу подтвердить пользователя, но я говорю о функциональности, которая не требует входа пользователя в систему
2. @cusimar Вы можете присвоить каждому посетителю вашего сайта временный идентификатор пользователя и использовать его для отслеживания того, какие разделы он загрузил. Запускайте скрипт в Cron каждые 24 часа, чтобы удалять временные учетные записи, созданные 24 часа назад.
Ответ №3:
То, что вы пытаетесь сделать, в корне противоречит тому, как работает Интернет. Вы не можете и не должны пытаться ограничить способ, которым пользователи делают запросы к вашим сервисам. Это крайне устаревший и отсталый способ мышления. Вместо того, чтобы пытаться ограничить способы, которыми пользователи могут использовать ваш сервис, будьте благодарны за то, что они используют ваш сервис в первую очередь.
Все, что вы можете сделать, это убедиться, что пользователь аутентифицирован и имеет доступ к запрашиваемой им записи. Если вы используете систему, в которой нет аутентификации, и вы хотите, чтобы пользователи не «угадывали» идентификатор следующей записи, не используйте последовательные идентификаторы. Используйте случайно сгенерированные строки в качестве вашего идентификатора. Сделайте их достаточно длинными, чтобы пользователям было трудно наткнуться на другие записи.