Почему небезопасно показывать ID пользователя в URL, и чем его заменить?

Question

[Павел]

Собственно суть вопроса такая. Есть, например, ссылка на профиль юзера site.com/user/123, где 123 - это id в БД. Почему так небезопасно делать, и какой идентификатор можно использовать вместо id-шника ?

Comments

[sim3x]

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

[Сергей delphinpro]

Небезопасно читать говнобложики.

[Павел]

sim3x, как-то делал тестовое задание для одних ребят. Помимо всего прочего, там нужно было сделать подтверждение регистрации по ссылке, отправленной на email. Я сделал, что-то типа такого
site.com/confirm?id=12&confirmtoken=2faoihoirh38y

Мне указали, что так делать небезопасно. Плюс сейчас делаю приложение с фрондендщиком, он говорит, что на старой его работе за такое по рукам били, и настаивает, что бы я все переделал. А я понять не могу что тут такого, ведь запросить, например, пост по id - site.com/post/234 - это в порядке вещей, а вот юзера вдруг небезопасно.

[Александр Таратин]

sim3x, Сергей, Например неупорядоченные id пользователей усложнят парсинг профилей.

[sim3x]

Павел, Почему не безопасно?

Пусть отвечающий пояснит на пальцах, как можно проексплуатировать уязвимость

[sim3x]

Александр Таратин, К безопасности ето не имеет прямого отношения

[Сергей delphinpro]

Павел,

Мне указали, что так делать небезопасно.

Вам объяснили почему? Вы спросили?

Плюс сейчас делаю приложение с фрондендщиком, он говорит, что на старой его работе за такое по рукам били, и настаивает, что бы я все переделал.

Ему, видимо, тоже не стали объяснять, а он по инерции вас дрочит. =))

[Сергей delphinpro]

Павел, Касательно озвученного кейса — зачем там вообще ID? Сгенерили какой-то уникальный хеш, записали у себя, что такой-то хеш соотнесен с таким акком. Отправили ссылку на мыло только с этим хешем.

Answer 1

[ThunderCat]

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

Comments

[Boris Köln]

Вброс не засчитан.
Описанный mass assignment не имеет отношения к id существующего юзера. Там взлом с использованием id дефолтной группы и кривых рук разработчика.

[ThunderCat]

Boris Korobkov, И? Кривые руки никто указом президента не отменял, дыра в довольно распространенной системе есть (была). что говорить о менее компетентных разработчиках, например - смотрим ид админа, меняем в подстановке логин и пароль себе - ставим ид админа - и хопа - мы поменяли пароль админу. Понятное дело что для серьезных систем такое не прокатит, но я сам видел код а ля $user->initByArray($_POST); на продакшене в ничего так себе конторе.

[Boris Köln]

ставим ид админа

И для защиты от этого скрывать id юзеров? security through obscurity

[ThunderCat]

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

Answer 2

[Exploding]

Тю, а че это не безопасно? Нормально, как по мне. Главное обрабатывать GET правильно и все там вполне безопасно.
Заменить... Ну... Транслитерация фио и канкатонировать тот же id^2 например, чтоб уж секретность была такой секретной))

Answer 3

[Boris Köln]

Не вижу никаких проблем, если засветить ID юзера.

1. Ну, можно их спарсить перебором - так ведь профили публичные, все равно их проиндексируют.
Если же профили непубличные, то и вообще не надо делать никаких URL для них, а просто по site.com/user показывать профиль текущего залогиненного юзера.

2. Если ID секретный, то в чем секретность? Даже при генерации 1 млн. ID рандомно не будет особой проблемы при брутфорсе.

3. Если вместо ID в URL используется другой идентификатор (например, уникальный ник), то он все рано представляет ровно такую же секретность, как и ID. То бишь почти никакой.

Answer 4

[Александр Таратин]

Просто раздавайте пользователям id не по порядку.
Генерация 1млн билетов со случайными уникальными ID

Answer 5

[x67]

Используйте хеш уникального имени+соли или UUID - их хватит надолго

Answer 6

[eRKa]

Есть такое дело, что не рекомендуют показывать реальные id на клиенте. В этом случает заводят еще одно поле, чаще всего guid, и если на клиенте нужно показать какой то идентификатор, то показывают его.

Comments

[Павел]

Есть такое дело, что не рекомендуют показывать реальные id на клиенте

Вот, да... а почему?

[eRKa]

Павел, у меня был год опыта работы в проекте платежного шлюза: карточки, электронные платежи и все такое. Так вот у нас там как раз так и было, что если надо было клиенту отдать идентификатор платежа или сохраненных данных карты, или созданного рекурентного платежа, то отдавали мы ему специально созданный идентификатор, а не реальный с бд, но внутри проекта для работы использовали реальный. Почему, с ходу сказать не могу, почему то я это принял как данное, но теперь я поинтересуюсь тоже). Но дураков там не было точно, через шлюз шло до 1млрд руб в месяц.

[Stalker_RED]

Павел, Вам ThunderCat все правильно написал - это облегчает некоторые виды атак.

Answer 7

[Сергей]

Пример. Vk.com. Они светят ид пользователя. И на заре существования можно было взяв это ид увидеть фотку любого пользователя.

Тут важно использовать эти ид вдумчиво.

Answer 8

[Psq]

Если используете в GET запросах сей параметр - приводите его к int при обработке, для избежания ряда SQL инъекций.