Вход в личный кабинет Почему безопасность сессий важна?
В любой системе типа «клиент-сервер» неправильная защита приведёт к уязвимости учётных записей для НСД. OWASP (ведущий орган по безопасности) считает неправильно реализованную авторизацию/аутентификацию вторым по величине риском для безопасности приложений. Несколько известных прецедентов хорошо показывают всю серьёзность вопроса:
Правильно реализовать управление сессиями пользователей сложно, это отнимает много времени и средств. По словам партнёра a16z и бывшего главы безопасности Box, организация аутентификации и авторизации стоит на первом месте по расходам в бюджетах организаций.
Игнорирование 2FA при восстановлении пароля
Многие сервисы выполняют автоматический вход в аккаунт после завершения процедуры восстановления пароля. Так как доступ к аккаунту предоставляется мгновенно, при входе в аккаунт 2FA может миноваться и полностью игнорироваться.
Impact аналогичного репорта на hackerone, который я прислал недавно:
Если злоумышленник получит доступ к электронной почте жертвы (он может взломать учетную запись с помощью фишинга, brute-force атаки, credentials stuffing и тд), он может обойти 2FA, хотя в этом случае 2FA должен защищать учетную запись. На данный момент для 2FA есть проверка кода Google Authenticator или резервного кода, но не кода из электронного письма, поэтому данный Bypass имеет смысл.
Ограничение скорости потоков с отсутствием блокировки после достижения определенной скорости
Зачастую исследователи безопасности пытаются подобрать код с использованием 5-и или более количества потоков, чтобы быстрее выполнить атаку (в Burp Intruder количество потоков по умолчанию- 5 без задержки). Но иногда система безопасности от перебора или обычный Load Balancer может реагировать только на этот единственный фактор.
Если вы пытаетесь брутфорсить с 5-ю потоками, стоит уменьшить количество до 1-го, а потом до 1-го с задержкой в одну секунду. Ранее мне посчастливилось наблюдать за таким поведением и именно с помощью таких манипуляций произошел успешный подбор кода, что привело к Account Takeover.
Если у 2FA кода нет определенного срока действия, то у нас есть много времени на перебор. Если же срок действия присутствует, то успешность атаки уменьшена, но потенциальная опасность уязвимости все равно присутствует, так как шанс попадания в нужный код все же есть.
Отсутствие Rate-лимита
Алгоритм Rate-лимита используется для проверки возможности пользовательского сеанса (или IP-адреса) быть ограниченым в попытках или скорости, и при каких обстоятельствах это происходит. Если пользователь выполнил слишком много запросов в течение определенного промежутка времени, веб приложение может ответить 429 кодом (много запросов) или применить Rate-лимит, не показав при этом ошибок.
. Манипуляция версиями API
Если вы видите в запросе web приложения что-то вроде /v*/, где * — это цифра, то есть вероятность, что можно переключиться на более старую версию API. В старой версии API может быть слабая защита или таковой может вовсе не быть. Это довольно редкое явление и возникает в том случае, если разработчики забыли удалить старую версию API в production/staging среде.
Генерируемый OTP код не изменяется
Это касается не постоянно изменяющихся кодов как в Google Authenticator, а только статичных, которые приходят в SMS, email или личным сообщением в мессенджере.
Суть данного обхода состоит в том, что постоянно или в течении некоторого времени, например, 5 минут, в SMS отправляется один и тот же OTP код, который в течении всего этого времени является валидным. Так же стоить следить за тем, чтобы не произошел silent rate-limit.
Если 2FA крепится к IP-адресу, то можно попытаться его подменить
Чтобы идентифицировать данный метод, войдите в свой аккаунт с помощью функции запоминания 2FA, потом перейдите в другой браузер или incognito режим текущего браузера и попробуйте войти снова. Если 2FA не запрашивается вовсе, значит произошло крепление 2FA к IP-адресу.
Игнорирование 2FA при входе через соцсеть
К аккаунту пользователя можно прикрепить социальную сеть для быстрого входа в аккаунт и одновременно настроить 2FA. При входе в аккаунт через соцсеть, 2FA может игнорироваться. Если email жертвы будет взломан, то можно будет восстановить пароль к аккаунту соцсети (если она позволяет это сделать) и войти на сервис без ввода 2FA.
Impact одного из репортов:
Rate лимит существует, но его можно обойти
Кейсы, которые раньше приходилось встречать:
Сброс rate-limit-a при обновления кода.
В запросе проверки кода, rate-лимит присутствует, но после задействования функционала повторной отправки кода он сбрасывается и позволяет продолжать брутфорс кода.
Примеры репортов:
Обход 2фа с помощью подстановки части запроса из сессии другого аккаунта
Если для верификации кода в запросе отправляется параметр с определенным значением, попробуйте отправить значение с запроса другого аккаунта.
Например, при отправке OTP-кода проверяется ID формы, ID пользователя или cookie, которое связано с отправкой кода. Если применить данные с параметров аккаунта, на котором нужно обойти code-верификацию (Account 1), на сессию совсем другого аккаунта(Account 2), получим код и введем его на втором аккаунте, то сможем обойти защиту на первом аккаунте. После перезагрузки страницы 2FA должна исчезнуть.
Игнорирование 2FA в случае кроссплатформенности
Имплементации 2FA в мобильной или десктопной версии могут отличаться от web версии приложения. 2FA может быть слабее, чем в web версии или вовсе отсутствовать.
7. При отключении 2FA не запрашивается текущий код.
Если при отключении 2FA не запрашивается дополнительное подтверждение, такое как текущий код с google authenticator приложения, код с email/телефона, то в таком случае имеются определенные риски. При чистом запросе существует вероятность CSRF атаки. Если будет найден вектор обхода CSRF защиты (если она есть)
, то 2FA можно будет отключить. Также может использоваться clickjacking уязвимость, — после пары кликов от ничего не подозревающего пользователя 2FA будет отключена. Подтверждение предыдущего кода добавит дополнительную защиту 2FA, учитывая потенциальные CSRF/XSS/Clickjacking атаки, а также CORS misconfigurations.
Обход rate-лимита путем смены IP адреса
Множество блокировок основаны на ограничении приема запросов с IP, который достиг порога определенного количества попыток при выполнении запроса. Если IP-адрес сменить, то есть возможность обойти это ограничение. Для того, чтобы проверить данный способ, просто смените свой IP с помощью Proxy-сервера/VPN и увидите, зависит ли блокировка от IP.
Способы смены IP:
Так как IP rotate тулза отправляет запросы с помощью AWS IP-адресов, все запросы будут блокироваться, если веб приложение находится за CloudFlare фаерволом.
В данном случае нужно дополнительно обнаружить IP оригинального веб сервера или найти способ, не касающийся AWS IP-адресов.
Обход 2FA с помощью «функционала запомининания»
На многих сайтах, поддерживающих 2FA авторизацию, есть функционал «запомнить меня». Он полезен в том случае, когда пользователь не желает вводить 2FA код при последующих входах в аккаунт. Важно идентифицировать способ, с помощью которого 2FA «запоминается». Это может быть cookie, значение в session/local storage или просто крепление 2FA к IP адресу.
На сайте включена поддержка X-Forwarded-For
Встроенный header X-Forwarded-For может использоваться для смены IP. Если в приложение встроена обработка данного хедера, просто отправьте X-Forwarded-For: desired_IP для подмены IP, чтобы обойти ограничение без использования дополнительных прокси. Каждый раз, когда будет отправлен запрос с X-Forwarded-For, веб-сервер будет думать, что наш IP адрес соответствует значению, переданному через хедер.
Материалы на эту тему:
Improper access control баг на странице ввода 2FA
Иногда страница-диалог для ввода 2FA представлена в виде URL с параметрами. Доступ к такой странице с параметрами в URL с cookies, которые не соответствуют тем, которые использовались при генерации страницы или вообще без cookies, — это не безопасно. Но если разработчики решили принять риски, то нужно пройтись по нескольким важным пунктам:
- истекает ли ссылка для ввода 2FA;
- индексируется ли ссылка в поисковиках.
Игнорирование 2FA при определенных обстоятельствах
При выполнении некоторых действий, которые приводят к автоматическому входу в аккаунту, 2FA может не запрашиваться.
Отсутствие Rate-limit-а в личном кабинете
2FA может внедряться в различные функционалы личного кабинета пользователя для большей безопасности. Это может быть изменение email адреса, пароля, подтверждение изменения кода для осуществления финансовых операций, etc. Наличие rate-limit-a в личном кабинете может отличаться от наличия rate-limit-a в 2FA при входе в аккаунт.
Если разработчики изначально добавили защиту против несанкционированного изменения данных, то данную защиту нужно поддерживать и исправлять все возможные bypass-ы. Если bypass найден, то это расценивается как уязвимость обхода «security feature», которая была имплементирована разработчиками.
Jwt и непрозрачные токены
Это два преобладающих типа токенов, которые используются в управлении сессиями.
Атака грубой силой
Злоумышленник с достаточными ресурсами может непрерывно «угадывать» токены аутентификации, пока одна из попыток не окажется успешной. Это даст ему доступ ко всем украденным токенам. Защититься можно, используя длинные токены с высокой энтропией.
Атака посредника
Такая атака возможна при следующих сценариях:
Атаки xss
Злоумышленник может внедрить JavaScript-код в приложение, запущенное в браузере жертвы. Внедрённый код читает и передаёт токены аутентификации злоумышленнику.
Веб-токен json
Каждый JWT содержит конкретную информацию, которая может быть интерпретирована любой стороной, имеющей этот токен. Например, эта информация может содержать идентификатор пользователя, которому она была выдана.
Плюс JWT — это масштабируемость. Бэкенду не нужно выполнять поиск по базе данных для каждого вызова API.
Недостатком является то, что отзыв одного токена по требованию (до истечения срока его действия) может быть затруднён, если не используются методы вроде внесения в чёрный список, которые влияют на масштабируемость решения. Однако можно отменить все токены, изменив ключ подписи.
Главные уязвимости онлайн-банков: авторизация, аутентификация и android
Уязвимости высокого уровня риска в исходном коде, а также серьезные недостатки механизмов аутентификации и авторизации во многих системах дистанционного банковского обслуживания позволяют проводить несанкционированные транзакции или даже получить полный контроль над системой со стороны внешнего злоумышленника, что может привести к существенным финансовым и репутационным потерям. Такие выводы содержатся в исследовании уязвимостей ДБО, обнаруженных экспертами Positive Technologies в 2022 и 2022 годах в ходе работ по анализу защищенности для ряда крупнейших российских банков. В данной статье мы представляем некоторые результаты этого исследования.
В рамках исследования было рассмотрено 28 систем дистанционного банковского обслуживания физических (77%) и юридических лиц (23%). Среди них были и мобильные системы ДБО, представленные серверной и клиентской частью (54%). Две трети систем (67%) являлись собственными разработками банков (использовались Java, C# и PHP), остальные были развернуты на базе платформ известных вендоров. Большинство систем ДБО (74%) находились в промышленной эксплуатации и были доступны для клиентов, а четверть ресурсов составляли тестовые стенды, готовые к переводу в эксплуатацию.
Общие результаты
Почти половина обнаруженных уязвимостей систем ДБО (44%) имеет высокий уровень риска. Примерно одинаковое количество уязвимостей имеют среднюю и низкую степень риска (26% и 30%). В целом, уязвимости высокого уровня риска были выявлены в 78% исследованных систем.
Большая часть уязвимостей (42%) связана с ошибками реализации механизмов защиты систем ДБО, заложенных разработчиками. В частности, к данной категории уязвимостей относятся недостатки механизмов идентификации, аутентификации и авторизации. На втором месте — уязвимости, связанные с ошибками в коде приложений (36%). Остальные уязвимости в основном связаны с недостатками конфигурации (22%).
Наиболее часто в системах ДБО встречались уязвимости, связанные с возможностью идентификации используемого ПО и с предсказуемыми форматами идентификаторов пользователей (57% систем). Более чем в половине систем (54%) обнаружены ошибки в программном коде типа «Межсайтовое выполнение сценариев». Если при наличии этой уязвимости в системе клиент банка перейдет по специально сформированной вредоносной ссылке, атакующий может получить доступ к системе ДБО с привилегиями данного клиента.
Распространены также уязвимости, позволяющие реализовать атаки на сессии пользователей (54% систем). Сюда относятся уязвимости, связанные с некорректным завершением сессий, некорректной настройкой cookie-параметров, возможностью параллельной работы нескольких сессий для одного пользователя, отсутствием привязки сессии к IP-адресу клиента и др. При успешной атаке злоумышленник может получить доступ к личному кабинету пользователя с его привилегиями.
В число наиболее распространенных вошла уязвимость высокой степени риска «Внедрение внешних сущностей XML», которая обнаружена в 46% систем. В результате ее эксплуатации злоумышленник может получить содержимое файлов, хранящихся на уязвимом сервере, данные об открытых сетевых портах узла, вызвать отказ в обслуживании всей системы ДБО, — а также, в ряде случаев, обратиться к произвольному узлу от лица уязвимого сервера и развить атаку.
Отказ в обслуживании системы ДБО может быть вызван с использованием различных уязвимостей в половине исследованных ресурсов (52%).
Самые распространенные уязвимости систем ДБО (доля систем)
Большинство распространенных уязвимостей имеет средний или низкий уровень риска. Тем не менее, в сочетании с особенностями функционирования конкретных систем ДБО это может привести к реализации серьезных угроз безопасности, включая кражу конфиденциальных данных (89% систем) и кражу денежных средств (46%).
Исследованные системы ДБО содержат также ряд существенных недостатков на уровне логики. К примеру, в ряде систем была обнаружена возможность атак на основе некорректного использования алгоритмов округления чисел. Скажем, злоумышленник переводит 0,29 рублей в доллары США. При стоимости одного доллара в 60 рублей, сумма в 0,29 рублей соответствует 0,00483333333333333333333333333333 долларов. Данная сумма будет округлена до двух знаков после запятой, т. е. до 0,01 доллара (один цент). Затем злоумышленник переводит 0,01 доллара обратно в рубли и получает 0,60 рублей. Таким образом злоумышленник «выигрывает» 0,31 рублей. В результате автоматизации данной процедуры, учитывая отсутствие ограничений по количеству транзакций в сутки и минимальному размеру транзакции, а также возможности эксплуатации уязвимости типа Race Condition («Состояние гонки»), — в ряде случаев злоумышленник может получать неограниченные суммы денежных средств.
Уязвимости по разработчикам
Уязвимостей высокой степени риска больше в системах ДБО, предоставленных вендорами (49%), чем в системах собственной разработки конкретного банка (40%). Кроме того, системы, поставляемые профессиональными разработчиками, в среднем содержат в 2,5 раза больше уязвимостей на уровне кода приложения, чем системы собственной разработки. Данный факт можно объяснить тем, что при использовании ПО от вендора банк в вопросах качества кода полагается главным образом на поставщика. При этом сложная архитектура, кроссплатформенность и большое количество функций систем ДБО не всегда позволяют вендору обеспечить должный уровень защищенности на уровне кода приложения.
Среднее количество уязвимостей в системах (в зависимости от разработчика)
Уязвимости механизмов защиты
Наиболее распространенным недостатком механизмов идентификации систем ДБО является предсказуемость формата идентификатора учетной записи (64% систем). Зная несколько существующих в системе идентификаторов, злоумышленник может вычислить механизм их формирования и подобрать нужный. 32% исследованных систем раскрывали информацию о существующих в системе учетных записях, возвращая различные ответы в зависимости от существования введенного идентификатора; в 20% случаев системы ДБО содержали обе вышеупомянутые уязвимости идентификации.
58% рассмотренных систем имели недостатки реализации механизма аутентификации — слабую парольную политику, недостаточную защиту от подбора учетных данных, возможность обхода механизма CAPTCHA или отсутствие обязательной двухфакторной аутентификации при входе в личный кабинет.
Уязвимости механизмов аутентификации (доли систем)
79% систем содержали различные недостатки авторизации и защиты транзакций. При этом в 42% случаев злоумышленник мог получить несанкционированный доступ к данным пользователей (персональным данным, информации о счетах, платежах и т. п.), а в 13% систем нарушитель мог напрямую осуществлять банковские операции от лица других пользователей.
Недостатки механизмов авторизации (доля уязвимых систем)
Уязвимости мобильных клиентов
Клиентское ПО для ОС Android более уязвимо по сравнению с приложениями для iOS. В частности, критически опасные уязвимости содержатся в 70% приложений для Android и в 50% приложений для iOS.
Доли клиентских мобильных программ, подверженных уязвимостям
В среднем каждое приложение на базе Android содержит 3,7 уязвимостей, в то время как для iOS-приложения данный показатель равен 2,3.
Наиболее часто в мобильных системах ДБО встречались уязвимости, связанные с небезопасной передачей данных (73%), далее идут недостаточная защита сессий (55%) и небезопасное хранение данных в мобильном приложении (41%).
Наиболее распространенные уязвимости клиентского ПО мобильных систем
Хотя наиболее распространенные уязвимости мобильных систем ДБО имеют среднюю или низкую степень риска, в ряде случаев совокупность выявленных недостатков позволяла реализовать серьезные угрозы безопасности. Например, одно из исследованных приложений отправляло широковещательное сообщение, содержащее полученное от банка SMS-сообщение (с одноразовым паролем для проведения транзакции), которое могло быть перехвачено сторонним приложением. Кроме того, данное мобильное приложение осуществляло журналирование важных данных, таких как учетная запись пользователя, вследствие чего при успешном заражении устройства пользователя вредоносным кодом атакующий мог получить полный доступ к аутентификационным данным и проводить транзакции от лица пользователя мобильного приложения.
Более детальные результаты данного исследования будут представлены на международном форуме по безопасности Positive Hack Days V, который пройдет 26 и 27 мая в Москве. Там же можно поучаствовать в конкурсах по взлому банкоматов и онлайновых банковских сервисов. Подробности на сайте www.phdays.ru.
Дбо от известного вендора не гарантирует защиту
В системах, приобретенных банками у известных вендоров, доля уязвимостей, связанных с ошибками в программном коде, оказалась выше, чем в системах собственной разработки банков (40% против 28%). В то же время в системах собственной разработки был выявлен больший процент уязвимостей конфигурации (35% против 27%). В прошлые годы таких уязвимостей у ДБО вендоров было вдвое меньше (14%).
По сравнению с предыдущими годами, количество уязвимостей высокой степени риска в системах ДБО, предоставленных вендорами, снизилось практически вдвое. Однако все такие продукты подвержены критически опасным уязвимостям.
Кроме того, системы ДБО, поставляемые специализированными компаниями, в среднем содержат в 1,5—2 раза больше уязвимостей, чем системы собственной разработки. Это неудивительно, поскольку собственные системы ДБО проектируются под конкретную архитектуру и обладают заданным банком функционалом, что делает их более простыми и, как следствие, менее уязвимыми.
Распределение уязвимостей по степени риска для систем, предоставленных разными категориями разработчиков (доля от общего количества уязвимостей)
Долгоживущий токен доступа
Особенности:
- Если пользователь добровольно выходит из системы, токен доступа аннулируется и удаляется на фронтенде.
- Токен авторизации постоянно открыт в трёх пространствах для атаки — фронтенде, бэкенде и во время передачи.
- В случае кражи злоумышленник будет иметь несанкционированный доступ к учётной записи жертвы до истечения срока действия токена, который может составлять недели или месяцы.
- Хищение может быть обнаружено только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуги.
- Если поток реализован с использованием JWT, токен сложно отозвать. Однако токены Opaque легко могут быть отозваны.
Доступ к базе данных/файловой системе
Если злоумышленнику удастся получить доступ к БД/ФС с помощью атаки на базу данных или фактического доступа к серверу, он может получить текущие активные токены авторизации или закрытый ключ JWT/SSL. Кража этих ключей потенциально даже хуже, чем украденные пароли, так как это позволит легко перехватывать сессии, что приведёт к серьёзным последствиям для безопасности.
Чтобы контролировать риск несанкционированного доступа к базе данных или файловой системе, можно сделать следующее:
- Сохраняйте в базе данных только хэшированные версии токенов обновления или доступа, чтобы злоумышленник не смог захватить любую сессию в реальном времени. Эта рекомендация применима ко всем реализациям, описанным выше.
- При использовании JWT вы вынуждены хранить закрытый ключ на сервере, что может привести к краже. Злоумышленник сможет перехватить как текущие, так и будущие сеансы. Чтобы ограничить ущерб, необходимо изменить закрытый ключ, используемый для подписи JWT, и немедленно аннулировать все текущие JWT. Изменение личного ключа не повлияет на взаимодействие с пользователем, поскольку токен обновления будет использоваться для создания JWT, подписанного с новым закрытым ключом.
Исходные данные
В рамках исследования было рассмотрено 20 систем ДБО, включая несколько финансовых сервисов, разработанных на языке 1C, для которых характерны те же угрозы ИБ, что и для систем дистанционного банковского обслуживания. В обзор вошли только те системы ДБО, для которых проводился наиболее полный анализ с учетом логики их функционирования.
65% систем являются собственными разработками банков. В большинстве случаев использовался язык программирования Java и лишь 8% приложений написаны на 1С. Остальные системы развернуты на базе платформ известных вендоров. В соответствии с политикой ответственного разглашения, в настоящем отчете названия компаний-производителей не указываются.
Большинство систем (75%) находились в промышленной эксплуатации и были доступны для клиентов, остальные представляли собой тестовые стенды, готовые к переводу в промышленную эксплуатацию. 57% систем ДБО, предоставляемых известными вендорами, находилась в промышленной эксплуатации.
Кража токена oauth
Если приложение предоставляет токены доступа/обновления через OAuth, существует риск кражи токенов при взломе серверов сторонних приложений. Решить эту проблему (не полностью) можно используя только краткосрочные токены доступа.
Кража токена oauth с помощью параметра redirect_uri
Приложение инициирует процесс авторизации, отправляя запрос на сервер OAuth:
Кратко-/среднесрочный токен для получения нового токена доступа
Новый токен доступа может использоваться на фронтенде, даже если срок действия предыдущего токена не истёк. Если пользователь добровольно выходит из системы, токен доступа на бэкенде аннулируется и удаляется на фронтенде. С большой вероятностью пользователя выкинет из системы, если токен доступа будет недолговечным.
Особенности:
- Токен авторизации постоянно открыт в трёх пространствах для атаки — фронтенде, бэкенде и во время передачи.
- Для поддержания несанкционированного доступа злоумышленник должен постоянно обновлять свой токен.
- Чтобы оставаться в системе, и злоумышленник, и жертва должны запросить у сервера новый токен доступа пока действует текущий (украденный) токен. Оба будут делать это, используя один и тот же токен доступа, поэтому если он используется для запроса дважды, то система может определить, что произошла кража (зависит от реализации фронтенда).
- Сокращённый срок действия токена доступа позволит быстрее обнаружить кражу, но может также ухудшить пользовательский опыт из-за повторяющихся выходов из системы.
- Если обнаружена кража, маркер доступа необходимо отозвать. В случае с JWT может быть сложно остановить атаку.
Кратко-/среднесрочный токен доступа, использование которого продлевает срок его действия
Особенности:
- Если пользователь добровольно выходит из системы, токен доступа аннулируется и удаляется на фронтенде.
- Токен авторизации постоянно открыт в трёх пространствах для атаки — фронтенде, бэкенде и во время передачи.
- Пока жертва/злоумышленник активны, злоумышленник сможет поддерживать несанкционированный доступ.
- Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуги.
- После обнаружения маркер доступа необходимо отозвать. При использовании JWT может быть сложно остановить атаку.
Краткосрочный токен доступа
Особенности:
- Если пользователь добровольно выходит из системы, токен доступа аннулируется и удаляется на фронтенде.
- Здесь нет критических токенов авторизации. Этот метод часто предоставляет учётные данные пользователя во время передачи, что делает их уязвимыми.
- Если токен украден, атакующий сможет наносить урон в течение короткого периода времени.
- Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуг.
- Токены доступа не нужно отзывать, поскольку они недолговечны. Однако при необходимости токены доступа Opaque можно отозвать, удалив их из базы данных.
Краткосрочный токен доступа с долгоживущим токеном обновления
Особенности:
- Если пользователь добровольно выходит из системы, токены доступа и обновлений аннулируются и удаляются на фронтенде.
- Токен авторизации (токен обновления) постоянно открыт в двух пространствах для атаки — фронтенде и бэкенде — и время от времени открыт во время передачи.
- В случае кражи злоумышленник будет иметь несанкционированный доступ в течение короткого периода времени (до истечения срока действия токена).
- Злоумышленник может использовать украденный токен обновления, чтобы получить новые токены доступа и пользоваться несанкционированным доступом к учётной записи жертвы долгое время.
- Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуг.
- Токены доступа не нужно отзывать, поскольку они недолговечны. При необходимости токены доступа Opaque и токены обновления можно легко отозвать, удалив их из базы данных.
Обнаружить кражу можно при определённых сценариях и реализациях. Например, в одной из реализаций предыдущие токены доступа будут немедленно аннулированы при создании нового токена. Это позволяет системе распознать кражу, когда злоумышленник и жертва находятся в сети одновременно.
Если злоумышленник использует токен обновления, токен доступа жертвы будет аннулирован, что заставит жертву запросить новый токен доступа. Это приведёт к другому запросу от злоумышленника и так далее. Если бэкенд обнаруживает короткие интервальные запросы на новые токены, можно сделать вывод, что произошла кража.
Мобильные системы дбо для ios немного лучше
Мобильные системы ДБО под управлением iOS по-прежнему обладают более высоким уровнем защищенности по сравнению с системами под Android, где 75% исследованных приложений подвержены критически опасным уязвимостям. Однако треть уязвимостей, обнаруженных в приложениях для iOS, характеризуются высокой степенью риска. Эти недостатки связаны с хранением и передачей важных данных в открытом виде.
Доли клиентского ПО мобильных систем ДБО, подверженных уязвимостям различной степени риска
Каждое приложение на базе Android содержит 3,8 уязвимости, что примерно соответствует уровню 2022 и 2022 годов (3,7). Для iOS-приложений данный параметр равен 1,6, что значительно лучше результата предыдущих лет, когда на каждое приложений приходилось 2,3 уязвимости.
Наиболее распространенные уязвимости клиентского ПО мобильных систем
Непрозрачный токен
Представляет собой случайные строки, которые действуют как указатели на информацию, хранящуюся только в системе, которая их выдаёт. Они требуют поиск в базе данных/кэше при каждом использовании. Один токен может быть легко отозван по требованию.
Эти два типа токенов имеют разные свойства, но кража любого из них может привести к несанкционированному доступу в учётную запись.
Обнаружение кражи аутентификационных токенов
Предотвращение — это первая линия защиты: должны быть приняты все возможные меры, чтобы снизить шанс воровства. Однако аутентификационные токены относительно часто подвержены краже из-за того, что передаются ненадёжной стороне (интерфейсу приложения), поэтому обнаружение кражи играет важную роль в безопасности.
Существующие методы обнаружения основаны на эвристических алгоритмах вроде отслеживания внезапных изменений IP-адресов и следов браузера (или мобильного устройства), а также маркировка «необычного поведения пользователя». К несчастью, эти методы могут быть неточными, их легко подделать и сложно реализовать. Однако есть надёжный способ интегрировать обнаружение кражи в поток управления сеансом.
Когда уязвимости сессий публично раскрываются, компании могут заявлять, что нет никаких признаков использования уязвимости. Но они не упоминают, насколько обширно их система способна обнаруживать кражу токенов.
Общие результаты
В ходе анализа защищенности систем ДБО в каждом из приложений были выявлены недостатки безопасности. В общей сложности была выявлена 171 уязвимость. Большинство из них характеризуются низкой степенью риска (39%). Общая доля уязвимостей высокой степени риска в этом году составила 30%, примерно столько же — средней (31%). В сравнении с результатами 2022—2022 годов общая доля критически опасных уязвимостей заметно снизилась (на 14%).
Однако уровень защищенности систем ДБО в целом остается на довольно низком уровне: критически опасные уязвимости встречаются почти в каждом интернет-банкинге (90%), что значительно хуже уровня 2022—2022 годов.
Распределение систем по максимальной степени риска обнаруженных уязвимостей
Наиболее часто (55%) в системах ДБО встречались уязвимости, позволяющие получить несанкционированный доступ к данным пользователей. К этой категории в основном относятся недостатки авторизации. На втором месте (50%) — «Недостаточная защита сессии» (некорректное завершение сессий пользователей, некорректная настройка cookie-параметров, возможность параллельной работы с несколькими активными сессиями для одного пользователя, отсутствие привязки сессии к IP-адресу клиента).
Общие способы реализации управления сессиями
Наиболее часто используемые потоки управления сессиями и их классификация:
- долгоживущий токен доступа;
- краткосрочный/среднесрочный токен доступа, используемый для получения нового токена доступа;
- краткосрочный/среднесрочный токен доступа, использование которого продлевает срок его действия;
- краткосрочный токен доступа;
- краткосрочный токен доступа с долгоживущим токеном обновления.
Проблемы механизмов защиты
Предсказуемый формат идентификаторов характерен для всех систем ДБО, при этом возможность сменить такой идентификатор предоставлена пользователям лишь 60% систем.
Двухфакторная аутентификация при входе в личный кабинет и проведении транзакций позволяют существенно снизить риски хищения денежных средств со счетов пользователей, однако по-прежнему велика доля систем ДБО, где такие механизмы не предусмотрены вовсе (24%), либо реализованы некорректно (29%).
Кроме того, каждая третья система ДБО (35%) не обеспечивает достаточную защиту сессии от перехвата и последующего использования злоумышленником.
Доля систем, подверженных уязвимостям механизмов аутентификации (для различных категорий разработчиков)
Распространённые атаки на сессии
Токены аутентификации хранятся как в фронтенде, так и в бэкенде, и часто отправляются по сети. Поэтому они уязвимы для нескольких типов атак:
Может показаться, что эти атаки маловероятны, но важно серьёзно относиться к безопасности сессий и применять соответствующие меры. Уязвимость системы основана на совокупной вероятности всех типов атак.
Чтобы обеспечить безопасность токенов, системный архитектор должен не только предотвращать их кражу, но и гарантировать скорейшее обнаружение уже совершённого хищения.
Рассмотрим каждый вид атаки подробнее.
Системы в эксплуатации остаются уязвимыми
Общее количество уязвимостей различных категорий в продуктивных системах в 2022 году заметно ниже, чем в тестовых. Это свидетельствует о положительных результатах работы банков по обеспечению защиты приложений, находящихся в эксплуатации. Однако уровень защищенности продуктивных систем ДБО нельзя считать высоким: практически во всех таких системах были выявлены критически опасные уязвимости.
Соотношение уязвимостей различного уровня риска в тестовых и продуктивных системах (доля от общего количества уязвимостей)
Системы для юрлиц стали уязвимее
Все исследованные системы ДБО для юридических лиц оказались подвержены опасным уязвимостям, а среди систем для физлиц таких оказалось 87%. При этом в системах ДБО для юридических лиц в 2022 году количество уязвимостей средней степени риска на одну систему возросло в несколько раз.
Среднее количество уязвимостей различного уровня риска на одну систему для физических и юридических лиц
Социальная инженерия и физический доступ
При физическом доступе к устройству жертвы можно украсть аутентификационные токены несколькими способами:
Эти два случая ещё более вероятны, если приложение используется на общедоступном компьютере, что необходимо учитывать.
Единственный способ действительно решить проблему — установить обнаружение кражи токенов и позволить пользователям выходить из аккаунта на всех устройствах сразу. Это означает, что есть возможность отменить все токены обновления и доступа для этого пользователя. При этом некоторые методы, которые используют долгоживущие токены JWT, могут быть трудными для реализации.
Фиксация сессии
Это возможно, если есть анонимные сессии в веб-приложении.
Для решения этой проблемы нужно генерировать новый набор токенов аутентификации каждый раз, когда пользователь входит в систему, и аннулировать старые (если таковые имеются). Это делается для каждого устройства, а не для пользователя.
Заключение
Уровень защищенности систем ДБО остается низким, несмотря на сокращение общей доли критически опасных уязвимостей среди всех выявленных недостатков по сравнению с прошлыми годами.
Низкая защищенность систем ДБО, находящихся в эксплуатации, наглядно свидетельствует о необходимости внедрения процессов обеспечения безопасности на всех стадиях жизненного цикла приложений. Анализ защищенности систем необходимо проводить не только на этапах разработки приложения и перед вводом системы в эксплуатацию, но и во время ее активного использования клиентами банка.
Системам ДБО, приобретенным у вендоров, стоит уделить особое внимание: они зачастую более подвержены уязвимостям, чем системы собственной разработки банков. Кроме того, рекомендуется использовать средства превентивной защиты, такие как межсетевой экран уровня приложения.
Для получения доступа к личному кабинету пользователя нарушителю достаточно использовать давно известные и распространенные уязвимости (например, недостаточную защиту сессии). Необходимо уделять особое внимание корректной реализации механизмов защиты.
Также следует внедрять процессы безопасной разработки, обеспечивать всестороннее тестирование безопасности систем при приемке работ. В качестве основы для внедрения процессов обеспечения информационной безопасности систем ДБО на всех стадиях жизненного цикла могут быть использованы выпущенные в 2022 году рекомендации Банка России РС БР ИББС-2.6-2022.
Учитывая высокую долю критически опасных уязвимостей на уровне кода веб-приложений, необходимо проводить регулярные проверки его качества, например, путем проведения анализа защищенности методом белого ящика (в том числе с помощью автоматизированных средств).