Как программисту, принимавшему участие в разработке платежных систем, мне неоднократно приходилось анализировать на наличие уязвимостей различные платежные сервисы, хранящие персональные данные клиентов и я постоянно сталкиваюсь с одной очень распространенной проблемой. Имя этой проблеме — инкрементальные айдишники.
Пример №1.
Сайт крупнейшего агрегатора платежных методов в России, обслуживает лидера онлайн-игр. После оплаты заказа переадресовывает клиента на урл вида
Перебирая значения параметра
Пример №2.
На одном из активно рекламируемых сайтов по выдаче онлайн кредитов после заполнения формы с личными данными, результат сформированной заявки выдавался по ссылке вида
Эти данные нужно было передать на клиента для формирования счета на оплату через кассу банка. Но если перебирать значения параметра
Пример №3.
Интернет-банк одного из крупнейших банков страны. При формировании регулярного платежа ему присваивался инкрементальный айдишник и по POST запросу на адрес вида
Пример №4.
Довольно популярный чат для сайтов. Учетная запись имела настройки, историю диалогов, администрирование операторов и пр.
Идентификатор сессии имел вид
где первая часть — идентификатор компании, вторая — идентификатор пользователя.
Как результат, при изменении первого идентификатора мы попадали в админку совершенно чужой компании. Получив доступ к аккаунту, мы имели возможность добавлять операторов и вести диалог с клиентами от имени кампании.
Вывод:
В приведенных выше примерах из-за ошибок программистов была допущена потенциальная возможность утечки персональных данных. Это большая цена за удобство использование целочисленного идентификатора.
Что делать? Используйте токен. Произвольная строка даже небольшой длины защитит вас от перебора и массовой кражи информации. Ведь вы не можете защититься от ошибок программистов, а код, который построен на использовании инкрементальных идентификаторов, придется постоянно контролировать
P.S.
Соглашусь с комментариями и добавлю от себя:
Использование токена подходит только как дополнительный уровень безопасности, полноценная защита должна быть реализована в архитектуре приложения через систему прав и доступов.
Пример №1.
Сайт крупнейшего агрегатора платежных методов в России, обслуживает лидера онлайн-игр. После оплаты заказа переадресовывает клиента на урл вида
aggregator-domain/ok.php?payment_id=123456, который в свою очередь переадресовывает на сайт онлайн-игры с адресом вида (декодировал для читабельности) online-game-domain/shop/?...amount=32.86...¤cy=RUB...&user=user_email@gmail.com...&item_name=1 день премиум аккаунта...Перебирая значения параметра
payment_id, мы можем видеть логины юзеров в онлайн-игре, покупки, которые они совершали, их сумму.
Пример №2.
На одном из активно рекламируемых сайтов по выдаче онлайн кредитов после заполнения формы с личными данными, результат сформированной заявки выдавался по ссылке вида
domain/confirmation?clientId=12345, где при GET запросе возвращались, помимо всего, ФИО, адрес проживания, идентификационный номер налогоплательщика. Эти данные нужно было передать на клиента для формирования счета на оплату через кассу банка. Но если перебирать значения параметра
clientId, мы получали персональные данные других клиентов. 
Пример №3.
Интернет-банк одного из крупнейших банков страны. При формировании регулярного платежа ему присваивался инкрементальный айдишник и по POST запросу на адрес вида
domain/calendar_event.php с параметром id=12345 возвращалась подробная информация о созданном регулярном платеже, включая ФИО пользователя, номера карт, сумму платежа, назначение, регулярность. И опять же, при изменении параметра id в меньшую или большую сторону мы получали доступ к приватной информации других клиентов.
Пример №4.
Довольно популярный чат для сайтов. Учетная запись имела настройки, историю диалогов, администрирование операторов и пр.
Идентификатор сессии имел вид
sessionID=”12345|6749476c44696255216a6148516d5e33”где первая часть — идентификатор компании, вторая — идентификатор пользователя.
Как результат, при изменении первого идентификатора мы попадали в админку совершенно чужой компании. Получив доступ к аккаунту, мы имели возможность добавлять операторов и вести диалог с клиентами от имени кампании.
Вывод:
В приведенных выше примерах из-за ошибок программистов была допущена потенциальная возможность утечки персональных данных. Это большая цена за удобство использование целочисленного идентификатора.
Что делать? Используйте токен. Произвольная строка даже небольшой длины защитит вас от перебора и массовой кражи информации. Ведь вы не можете защититься от ошибок программистов, а код, который построен на использовании инкрементальных идентификаторов, придется постоянно контролировать
P.S.
Соглашусь с комментариями и добавлю от себя:
Использование токена подходит только как дополнительный уровень безопасности, полноценная защита должна быть реализована в архитектуре приложения через систему прав и доступов.
