Запретить пользователю получать данные путем изменения идентификатора через URL

Question

Запретить пользователю получать данные путем изменения идентификатора через URL

0

Отображение пользовательских данных на странице по запросу:

$query = "SELECT * FROM COLLECTIONS WHERE uid = $_GET['user_id']";

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

Rajeev Malik 10 апр. 2018, в 20:35

Источник

1

Вам необходимо реализовать контроль доступа, проверяя, принадлежит ли коллекция зарегистрированному пользователю.
Barmar 10 апр. 2018, в 17:59
4

Другая проблема ... Ваш код уязвим для внедрения SQL и будет взломан, даже если вы экранируете входные данные! Вместо этого используйте подготовленные заявления .
Mehdi Bounya 10 апр. 2018, в 18:00
3

Не получайте ID пользователя из параметра URL. Когда пользователь входит в систему, установите переменную сеанса и используйте ее.
Barmar 10 апр. 2018, в 18:00
0

зашифруйте user_id, чтобы пользователь не изменил его.
abrar 10 апр. 2018, в 18:01
0

Например: $query = "SELECT * FROM COLLECTIONS WHERE uid = $_GET['$_SESSION['user_id']'];" @barmar
Rajeev Malik 10 апр. 2018, в 18:02
1

@abrar это слишком много
Mehdi Bounya 10 апр. 2018, в 18:02
0

@RajeevMalik В основном просто проверьте, имеет ли пользователь право доступа к элементу из collections если это так, покажите его
Mehdi Bounya 10 апр. 2018, в 18:02
0

@RajeevMalik $_SESSION['uid'] = $uid;
Barmar 10 апр. 2018, в 18:02
0

Как это сделать @ Мехди
Rajeev Malik 10 апр. 2018, в 18:04
0

Общий подход состоит в том, чтобы получить элемент и посмотреть, имеет ли пользователь право видеть его (владеет ли он пользователем), я не могу сказать наверняка, так как не знаю, какие данные вы храните в этой таблице, и какова ее структура.
Mehdi Bounya 10 апр. 2018, в 18:05
0

в чем проблема использования переменных сеанса, можете ли вы дать мне пример кода вашего подхода @MehdiBounya
Rajeev Malik 10 апр. 2018, в 18:07
0

С подходом, предложенным @Barmar, проблем нет
Mehdi Bounya 10 апр. 2018, в 18:08
0

@RajeevMalik Это сайт для хобби? Я действительно надеюсь, что вы делаете это просто для удовольствия, и никто не хранит здесь свои пароли или конфиденциальные данные.
wizzwizz4 10 апр. 2018, в 18:39
0

@MehdiBounya - я бы сказал, что шифрования недостаточно, им нужно будет добавлять разные случайные соли для каждого идентификатора пользователя, чтобы я не мог нарушить любое простое хеширование, которое они могут пытаться выполнить,
ArtisticPhoenix 10 апр. 2018, в 20:42
0

@ArtisticPhoenix не уверен, что если вы серьезный xD, достаточно проверки прав доступа.
Mehdi Bounya 10 апр. 2018, в 20:47
0

Я серьезно, вы не можете просто хэшировать ID и думать, что это безопасно. Я мог бы затормозить его, потому что я знаю, что это число, все, что я хотел бы сделать, это сказать, что это 32, это md5, затем я хэширую свой ID, если он такой же, как этот хэш, ну, я могу взять другой ID и просто хэшировать его. если это не так, но имеет одну и ту же соль для всех, то я могу грубо заставить эту соль из моего хэша и идентификатора пользователя, так что это должна быть случайная соль, которая требует ее хранения, и это было моей точкой зрения, проще управлять доступом в таком случае. Я специально отвечал на этот комментарий, encrypt the user_id so the user will not change it
ArtisticPhoenix 10 апр. 2018, в 21:43
0

@ArtisticPhoenix Мой комментарий состоял в том, что хеширование и шифрование - это слишком много и не нужно (как вы сказали, в этот момент проще осуществлять контроль доступа ), еще один более простой подход заключается в создании уникального ключа, который достаточно длинный, чтобы предотвратить взлом и сохранение его вместе первичный ключ (int id) и использовать уникальный ключ для открытого доступа.
Mehdi Bounya 10 апр. 2018, в 21:54

Показать ещё 15 комментариев

Теги:

php

mysql

1 ответ

Ещё вопросы

Вам необходимо реализовать контроль доступа, проверяя, принадлежит ли коллекция зарегистрированному пользователю.
Другая проблема ... Ваш код уязвим для внедрения SQL и будет взломан, даже если вы экранируете входные данные! Вместо этого используйте подготовленные заявления .
Не получайте ID пользователя из параметра URL. Когда пользователь входит в систему, установите переменную сеанса и используйте ее.
зашифруйте user_id, чтобы пользователь не изменил его.
Например: $query = "SELECT * FROM COLLECTIONS WHERE uid = $_GET['$_SESSION['user_id']'];" @barmar
@RajeevMalik В основном просто проверьте, имеет ли пользователь право доступа к элементу из collections если это так, покажите его
Общий подход состоит в том, чтобы получить элемент и посмотреть, имеет ли пользователь право видеть его (владеет ли он пользователем), я не могу сказать наверняка, так как не знаю, какие данные вы храните в этой таблице, и какова ее структура.
в чем проблема использования переменных сеанса, можете ли вы дать мне пример кода вашего подхода @MehdiBounya
С подходом, предложенным @Barmar, проблем нет
@RajeevMalik Это сайт для хобби? Я действительно надеюсь, что вы делаете это просто для удовольствия, и никто не хранит здесь свои пароли или конфиденциальные данные.
@MehdiBounya - я бы сказал, что шифрования недостаточно, им нужно будет добавлять разные случайные соли для каждого идентификатора пользователя, чтобы я не мог нарушить любое простое хеширование, которое они могут пытаться выполнить,
@ArtisticPhoenix не уверен, что если вы серьезный xD, достаточно проверки прав доступа.
Я серьезно, вы не можете просто хэшировать ID и думать, что это безопасно. Я мог бы затормозить его, потому что я знаю, что это число, все, что я хотел бы сделать, это сказать, что это 32, это md5, затем я хэширую свой ID, если он такой же, как этот хэш, ну, я могу взять другой ID и просто хэшировать его. если это не так, но имеет одну и ту же соль для всех, то я могу грубо заставить эту соль из моего хэша и идентификатора пользователя, так что это должна быть случайная соль, которая требует ее хранения, и это было моей точкой зрения, проще управлять доступом в таком случае. Я специально отвечал на этот комментарий, encrypt the user_id so the user will not change it
@ArtisticPhoenix Мой комментарий состоял в том, что хеширование и шифрование - это слишком много и не нужно (как вы сказали, в этот момент проще осуществлять контроль доступа ), еще один более простой подход заключается в создании уникального ключа, который достаточно длинный, чтобы предотвратить взлом и сохранение его вместе первичный ключ (int id) и использовать уникальный ключ для открытого доступа.

wizzwizz4 · Answer 1 · 2018-04-10T15-41-00.000Z

Возьмите ваш сайт в автономном режиме. СЕЙЧАС. Кто-то собирается либо стереть данные, либо украсть данные, либо ввести вредоносное ПО, которое было доступно всем вашим клиентам

Вдох. Вы купили себе некоторое время, считая, что это еще не было нарушено.

Небольшое подмножество мер безопасности, которые вам НЕОБХОДИМО принять

Эти смягчения в порядке "имеет самые большие непосредственные выгоды" для ", вероятно, наиболее важны", по одной проблеме. (Помимо номера 3, который смягчает от 4 до 32241 проблем равной или большей величины до номера 1.)

Просмотрите каждый экземпляр каждого запроса базы данных и убедитесь, что вы никогда не используете двойные кавычки или . при определении строки запроса. Перестройте весь код обработки базы данных, чтобы использовать некоторую систему параметризованных SQL-запросов.
Используйте библиотеку аутентификации или, по крайней мере, криптографическую библиотеку.
Спросите о своей настройке в Security Stack Exchange, используя учетную запись, которая никоим образом не отслеживается на вашем веб-сайте. Даже для вашей компании, если ваш сайт связан с вашей компанией.

Зачем?

Да, я знаю, что этот веб-сайт, вероятно, важен и должен оставаться в стороне, чтобы люди могли его использовать. Но попробуйте следующее:

www.badwebsite.com/your/page/here?uid=1 OR 1

Все данные видны! Вы принимаете код от пользователя и запускаете его в своей базе данных. Теперь, если я решил удалить все ваши таблицы базы данных?

Это просто покрывает первый пункт, который я сделал. Пожалуйста, верьте, что для ваших пользователей существуют большие проблемы, если вы еще не сделали шаг 2, наименьшее из которых - сотни их учетных записей на других сайтах (например, Gmail, пример банка), которые стали известны киберпреступникам.

Взгляните на эту комикс:

Кроме того, в библиотеке запросов URL-адресов есть ошибка обработки юникода, и мы сохраняем пароли несолеными... поэтому, если мы соединим их с emoji, мы можем закрыть сразу три вопроса!

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

Возможно, вы захотите привлечь технического консультанта; если ваши разработчики не имеют опыта создания защищенного от вторжений программного обеспечения, то они, вероятно, не справляются с задачей обеспечения безопасности без защиты (что на порядок больше, особенно если вы новичок в таких вещах).

Эта инъекция "1;CREATE TABLE you_have_lost (number int);" не будет работать на клиентах MySQL от PHP, потому что они не поддерживают отдельные операторы SQL, разделенные точкой с запятой ( ; ) ... вместо этого вы просто получаете сообщение об ошибке, не выполняя запросы и не создавая таблицу .... если только вы не используете mysqli_multi_qeury () тогда ваш SQL инъекция будет работать ..
@RaymondNijland Спасибо. Можете ли вы придумать простую, понятную демонстрацию инъекции, которая будет работать в этом случае? Какой-то способ прочитать все данные? (Я не думаю, что SQL так плох, как JavaScript в этом отношении.)
@RaymondNijland Это классический случай; Я не знаю, почему я не подумал об этом. Спасибо!
Страница php может просто показать одну запись в этом случае, добавить LIMIT 1 , LIMIT 1, 1 , LIMIT 2, 1 end и так далее к SQL-инъекции, см. Sqlfiddle.com/#!9/b3f901/9
@RaymondNijland Почему вы не делаете редактирование, поэтому вы зачислены в историю редактирования?
Я бы сделал 1 OR 1; -- комментарии остального SQL, то нет LIMIT Здесь пока вы ограничиваете скрипку я просто взломал его sqlfiddle.com/#!9/b3f901/11