Противостояние атакам в ДиБ Личном кабинете брокера

Провели глубокий анализ всех исходных кодов ДиБ Личного Кабинета Брокера версии 4 с учётом взаимодействия с БД учётной системы ДиБ Бэк-офис и ДиБ Депозитарий.

Современные финансовые сервисы работают в условиях, когда атакующие не ограничиваются одним способом проникновения: они сочетают подмену данных, перебор учётных записей, повторное использование legitimate-механизмов и попытки получить доступ к чужим данным через штатные функции системы. Ответ на такие угрозы - не одна «серебряная пуля», а продуманная многоуровневая защита, встроенная в каждую операцию: от входа пользователя до формирования отчёта и подписания документов.


1. Защита самых критичных операций - подписания документов

Электронная подпись - одна из наиболее чувствительных функций брокерского сервиса, поскольку именно она фиксирует волю клиента. Современный подход подразумевает, что доступ к сервису подписи открыт только авторизованным пользователям, а подписание от имени брокера и получение данных для него доступны исключительно сотрудникам с отдельным разрешением. Перед сохранением результата обязательно проверяется сама подпись, а связь документа с текущим пользователем - усиливается. Отдельные операции подписания, к которым можно обратиться в обход основного интерфейса, закрываются: злоумышленник не должен иметь возможность подписать или получить документ, минуя проверки прав.


2. SMS- и email-подтверждения: коды, которые нельзя переиспользовать

Одна из распространённых слабостей - когда механизм подтверждения работает «сам по себе» и не привязан к конкретному действию. Современная защита строится на трёх принципах: подтверждение всегда связано с пользователем, получателем и назначением операции; для подписания документов оно дополнительно привязано к конкретным документам и их содержимому; использованное подтверждение нельзя применить повторно. Дополнительно ограничивается количество попыток ввода кода и время его действия. Параллельные запросы обрабатываются так, чтобы одновременные попытки не позволяли обходить лимиты, а переключение между SMS и электронной почтой исключает подмену нового подтверждения старым. Эти правила единообразно применяются в авторизации, восстановлении доступа, регистрации и подписании документов.


3. Хранение паролей: устойчивость к утечке базы данных

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


4. Восстановление и смена пароля, контроль сеансов

Ссылки для восстановления защищены от повторного и одновременного использования, а обновление пароля выполняется с проверкой актуального состояния учётной записи. История паролей сохраняется только при успешном завершении операции. После смены пароля остальные сеансы отзываются, текущий - сохраняется в предусмотренных сценариях. Усилены проверки активности и блокировки учётной записи, проверка актуальности сеанса, а для менеджеров и доверенных лиц - проверка актуальности права работать с выбранным клиентом: после отзыва полномочий дальнейшие запросы в контексте клиента отклоняются.


5. Защита от подмены клиента и доступа к чужим данным

Классическая атака «подмены идентификатора» заключается в том, что пользователь подставляет чужой идентификатор и получает чужие данные. Противодействие - серверные проверки принадлежности каждой записи текущему клиенту, ограничение сведений о доверенных лицах другого клиента и использование в операциях данных, полученных сервером, а не значений из браузера. Устаревшие служебные методы портфельных модулей, обращавшиеся к данным фиксированного договора, удалены, при этом сохранены рабочие способы получения портфельных данных.


6. Регистрация, активация и ЕСИА

Продолжение регистрационной заявки привязано к подтверждённому телефону или адресу электронной почты, а для существующей заявки проверяется соответствие подтверждённых контактов сохранённым данным. Добавлены проверки допустимого состояния заявки, закрыт поиск заявок через подстановку произвольного значения состояния ЕСИА, возврат из ЕСИА привязан к сеансу, заявке и сроку действия. Активация учётных записей доступна только в предусмотренных конфигурациях: нельзя активировать заблокированную или уже активированную учётную запись, а ссылка активации удаляется после успешного завершения. Это исключает обход административной блокировки через ссылку активации.


7. Инвестиционные поручения

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


8. Защита от SQL-инъекций и серверная валидация

Устранены способы влияния пользовательских данных на структуру запросов к базе: усилены проверки полей поиска, значения списков ответов анкет проверяются и передаются отдельно, отключены операции формирования отчётов с небезопасным выбором процедуры (при сохранении безопасных способов). Добавлены проверки длины, формата, принадлежности и состояния записей, проверка соответствия вариантов анкеты конкретному вопросу. Защита перестала полагаться только на проверки в браузере.


9. Загрузка и обработка файлов

Ограничены размер загружаемых файлов и частота обращений к загрузчику. Закрыт прямой доступ к служебным папкам через общий маршрут получения файлов, добавлены проверки непреодолимости границ разрешённой папки, исправлено удаление временных вложений, введена периодическая очистка устаревших файлов. Вспомогательные операции закрыты для прямого внешнего вызова, а для регистрационных документов ограничено формирование путей, чтобы имя файла не позволяло записать данные за пределами нужной папки.


10. Ограничение массовых запросов и защита служебных функций

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


Проведённая работа показывает: современная защита - это не отдельный модуль, а сквозной принцип, применяемый единообразно во всех сценариях. Каждая операция проверяет права, принадлежность данных и актуальное состояние учётной записи; каждое подтверждение привязано к конкретному действию и защищено от повторного использования; каждая точка входа ограничена по частоте и объёму. Такой подход - сочетание многоуровневой проверки, серверной валидации и безопасных практик хранения данных - и составляет основу устойчивости финансового сервиса перед лицом современных атак.