Не заметите, как сломают
За 2015-2025 очень изменился подход к защите и безопасности сервисов, юзерских. Потому что вам не будут ломать сервис; вам сломают пользователя, любым способом, а потом с этими данными уже придут к вам.
Задача ситуативная, но достаточно важная, чтобы о ней писать. Сейчас золотой стандарт продукта или сервиса — штука, которая чем-то там торчит в интернет, и в ней ваши люди как-то авторизуются. Логин-пароль или oauth, все дела.
Еще 10 лет всё это работало нормально, плюс-минус. Используй разные пароли с нормальной стойкостью, постарайся их не просрать, итп. Логируй подозрительную активность. Защита «в точке авторизации» в принципе себя оправдывала.
Из того, что я за последние 10 лет вижу на различных высоконагруженных популярных сервисах, моих или в моем доступе — теперь процесс «лома» ваших юзеров и юзербазы выглядит совсем не так.
Во-первых, будут ломать конечное устройство пользователя, всем пофиг на ваш конкретный сервис. Этот процесс происходит массово, по площадям, постоянно. Малвари браузера, малвари на клиентском устройстве, промежуточные точки. Современные системы ботнетов занимаются тем, что постоянно пробуют всё найденное в интернете на прочность, в первую очередь клиентские устройства (потому что их много, апдейты доезжают не везде, у них предсказуемый набор софта и конфиги, а юзеру вообще на всё насрать).
Во-вторых, проще считать, что клиентское устройство заведомо скомпрометировано. Как и его identity origin, обычно это почта или oauth-аккаунт. Потому что общеизвестно, на почту у народа завязана тонна сервисов. Получить доступ к почте, с клиентского устройства или даже тупо перебором — первоочередная цель. И пароли на почте меняются хрен пойми когда. В интернетах тонны баз с аккаунтами, и аккаунты там именно почтовые.
Когда клиентское устройство «пробито», то есть скомпрометировано, уже малварем специальный код догружается на устройство, и смотрит, чего оттуда можно вкусного достать. Вся авторизация браузера (ов), все куки, сессии, jwt и локал-сторадж. Весь установленный софт, особенно для доступа к деньгам. Все менеджеры паролей — вы же уже на устройстве, как бы оно там не было зашифровано — рано или поздно оно отобразится на экране, или пролетит в браузер. Вся почта за полгода например, с сервисами, контакт-листом и ключевыми словами (пароль, банк, крипта, список отправителей). Знание обо всем этом периметре мгновенно уплывает в управлялку ботнета, вместе с данными.
В-третьих, по известному периметру, у владельца ботнета можно пойти и купить «доступ» к скомпрометированным машинам и данным, которые подпадают под заданные условия и сигнатуру. Например, «дай мне браузерные сессии и JWT людей, которые пользовались сервисом abc.tld за последний месяц». В ботнете до миллиона машин, неплохой шанс что среди них будут 10-100 ваших клиентов и их активных сессий. А ботнетов сотни.
И вот тут вся эта театральщина уже приходит к вам. С готовыми аккаунтами, с валидными JWT, с актуальными сессиями. Возможно даже, прямо из браузера клиента, малвари такое сейчас позволяют. Вся ваша защита «в точке авторизации» скорее всего сходит нафиг — потому что для вас это легальный клиент с вашими же данными и подписями, и даже с его устройства.
Ну и в-четвертых, всё это уже работает и автоматизировано в глобальных масштабах. Хочешь получить своих же юзеров — на рубль мешок.
То, что вынесено в заголовок: вы даже не заметите, что у вас под 100% валидными авторизационными данными пользователя пришел кто-то злонамеренный. Потому что все данные целиком уже сперли с устройства, к которому есть полный доступ, и возможно даже доступ с него же. И базовый identity origin уже скомпрометирован, та же почта, как самый частый пример.
С точки зрения сервиса и продукта — «ну мы не могли знать, что у вас уведут телефон и почту одновременно, чего вы от нас хотите». А с точки зрения клиента — из-за дыры в безопасности клиент оказался под ударом.
На одном сервисе с 100+ млн юзеров, мы посчитали, попытки доступа с угнанными учетными данными (с других сервисов! не с нашего!) поступали примерно 1 раз в 2-3 секунды, 24 часа. Это для понимания масштаба.
Вариантов защиты, о которых стоило бы подумать уже лет 10 как — их есть
— двухфакторка. Знание любого подтверждения, которое не связано с одним клиентским устройством (например, браузером). Беда только в том, что если OTP-генератор кода стоит на той же машине — ну, вы поняли, фактор у вас все еще один.
— почта отдельным фактором уже давно не является. Потому что как я выше сказал, весь пробив начинают с почты. Статистически, если у нас на сервисах приходил юзер «мне акк взломали», 90%+ шанса что почту ему сломали тоже. И если вы начнете с нее что-то подтверждать письмами, ничего не изменится. Максимум, юзер это заметит и что-то предпримет, но и то не факт.
— смски и коды в мессенджеры — неплохо, хотя и не панацея. Мессенджеры работают на той же машине, смски перехватываются с устройства (хотя телефон это не десктопный браузер, иногда спасает). Что тут хорошего — сессий мессенджера у пользователя обычно несколько, с разных устройств, и если похакали десктопный телеграм, в мобильный клиент все равно придет мессага и ее push, будет заметно, что что-то не так
— фингерпринтинг устройств. Зачастую для эксплойтинга используются другие хосты, в абузо-устойчивой юрисдикции (это дешевле), и для пользователя из России можно отловить и ограничить доступ из Зимбабве. Некоторые корректировки вносит повсеместный VPN, но даже там страна обычно фиксирована; новая страна и новое устройство — повод спросить про безопасность. Фингерпринтинг должен быть как статический (ip, подсеть, asn, страна) так и динамический (сгенеренный ключ именно для этого устройства)
— уровень доверия сессиям. Реализуется как: для каждой сессии, с конкретным фингерпринтом конкретного юзера мы храним однозначное указание, насколько и на_сколько стоит ей доверять. Ползать по приложению — окей, подойдет любая авторизованная, помним месяцами. Лазить в деньги — должна быть свежая двухфакторка, изволь. Управление аккаунтом и настройками безопасности — проходишь все проверки, и доверие не более чем на 10 минут (см. у гитхаба sudo mode). Доверие устаревает и понижается
— механизмы отзывов авторизации. Возможность посмотреть и прибить все свои сессии, включая понижение в правах и своей-текущей (потому что ее тоже могли спереть). Возможность сделать невалидными все выданные ключи, например JWT — реализуется элементарно через timestamp актуальности, если у вас нет процедуры отзыва по ключу. Включая их токены обновлений (refresh), а то случаются такие перлы, когда JWT отозван, а refresh позволяет тут же получить новый
— полная блокировка с фоллбеком в оффлайн, в телефон или в физическое подтверждение. Может, и не полная, а только запрет на elevation; ползать по системе сможешь, а получить ручки к деньгам и управлению — не сможешь. Неплохо работает здесь «человеческая прослойка», то есть доступ и проверка через саппорт; боты пока не умеют постучаться в чат и обрисовать проблему, это хотя бы не массово. Хотя нейросетки стараются
— для денег есть чит-код, можно сбросить проверку KYC при компрометации аккаунта (или подозрении на нее), тогда законодательство дает легальное право прогнать пользователя через проверку третьим лицом/сервисом, и прибить/понизить в правах все сессии и ключи. А третьи сервисы KYC-check запросят пакет актуальных подтверждений, которые сложно подделать одномоментно
— коммуникации в почте все еще верить нельзя примерно никогда
— «восстановление пароля» и доступа у вас работает в конечном итоге куда? в почту? Ага, вы понимаете.
Какая тут основная мысль. «Единая точка авторизации» больше не работает, потому что всю эту авторизованную сессию сопрут целиком. А также почту и oauth-аккаунт, в большинстве случаев.
Защита и проверка прав должны стать гранулярными, постоянными и размазанными по всей системе целиком. Из наиболее гибких подходов рекомендую уровень доверия конкретной сессии, который повышается строго на время, и понижается при любых сомнениях. Так, кстати, делают многие большие мальчики давно, начиная с гугла и амазона.
Про требования к аудиту промолчу, аудит просто должен быть — это ваш материал для разбора полётов, поиска концов и чистой задницы. Аудит следует хранить сразу в разрезе пользователей/аккаунтов, в доступном хранилище (а не текстовых логах где-то в кубике на 163 серверах). Если есть атрибуция, например фингеры (страна, устройство, сессия) — их тоже.
Клиентское устройство и браузер считаются недоверенными по определению, независимо от того, что конкретно вы там на них используете; у малваря скорее всего будет доступ и к браузеру, и к файловой системе, и даже к secure vault + TPM, потому что у него вся система доступна.
Биометрию не рекомендую, как ни странно.
Во-первых, бессмысленно: если есть доступ к устройству, то перехватить ее можно; далее утащить доверенную сессию, потому что всё сведется к ней же (а она уже валидно подтверждена исходным механизмом).
Во-вторых, использовать и хранить ее очень геморройно. Подписи и хеши ломаются и перехватываются на этапе передачи; хранить сырые данные — чревато юридически, представьте что будет, если вы это продолбаете или сопрут. Категории перс.данных не просто так придумали.
В-третьих, биометрия очень быстро всех задалбывает, «разблокировка телефона на морозе отпечатком носа».