Угон аккаунта без пароля: как крадут cookie сессии и что меняет защита Chrome
Если коротко: войти в ваш аккаунт можно и без пароля — достаточно украсть файл сессии (cookie), по которому сайт «узнаёт» вас после входа. Обычно это делает вредоносная программа-инфостилер на вашем компьютере: она забирает cookie из браузера, и злоумышленник открывает вашу почту или соцсеть так, будто он — это вы, минуя пароль и даже двухфакторную проверку. Защита Chrome делится на два уровня: шифрование cookie на диске и, главное, новая привязка сессии к устройству (DBSC), из-за которой украденный cookie быстро перестаёт работать.
Я Кирилл Огнев, по работе спасаю людей и делюсь тем, как не попасть в беду. Здесь разбираю механизм без паники и без инструкций для злоумышленников: что такое cookie сессии, почему кража работает, что изменил Google и что всё равно остаётся на вас.
Что такое cookie сессии и почему он важнее пароля
Когда вы вводите пароль и код из SMS, сайт проверяет вас один раз. Дальше он не может спрашивать пароль на каждый клик, поэтому выдаёт браузеру маленький файл — cookie сессии с длинным случайным идентификатором. Браузер прикладывает его к каждому запросу, а сайт сверяет с записью у себя и понимает: это тот самый человек, который уже вошёл.
Отсюда вывод, который многие не любят: идентификатор сессии для сайта равен вашему входу. В руководстве OWASP по управлению сессиями прямо сказано, что перехват идентификатора сессии позволяет атакующему полностью выдавать себя за жертву. Пароль и второй фактор уже были пройдены вами — сайт их больше не требует. Поэтому кража cookie обходит и то, и другое.
Как cookie попадают к злоумышленнику
Сайт сам по себе их не отдаёт: для этого есть защитные атрибуты. По рекомендациям OWASP, cookie сессии нужно помечать как Secure (отправляется только по HTTPS) и HttpOnly (скрипты на странице не могут его прочитать), а также задавать SameSite. Это защищает от перехвата в сети и от кражи через уязвимость на самом сайте.
Но есть путь, на который сайт повлиять не может, — ваш собственный компьютер. Если на нём работает вредоносная программа, она читает файлы браузера напрямую. Такие программы называют инфостилерами (от англ. stealer — «воришка»). Попадают они, как правило, через «взломанные» программы, поддельные установщики, фальшивые обновления и письма с вложениями. Они собирают сохранённые пароли, данные автозаполнения и cookie, упаковывают и отправляют на сервер злоумышленника. Дальше украденные сессии продают или используют сами.
Здесь и проходит граница между атаками на сайт и атаками на устройство. HttpOnly бесполезен, если программа читает базу cookie с диска и не обращается к странице через скрипт.
Первый уровень защиты Chrome: шифрование на диске
Раньше cookie в Chrome на Windows шифровались средствами самой системы, и любая программа, запущенная от вашего имени, могла их расшифровать. В июле 2024 года Google объявил об улучшении защиты cookie в Chrome для Windows — это технология App-Bound Encryption: ключ привязывается к приложению, то есть расшифровать данные должен мочь только сам Chrome, а не посторонний процесс.
Идея разумная, но у неё есть предел. Специалисты по безопасности вскоре сообщали о способах обойти такую защиту. Причина принципиальна: если вредоносная программа получила достаточные права на вашей машине, она может действовать от имени браузера или дождаться, когда браузер сам расшифрует данные. Шифрование на диске затрудняет кражу, но не делает её невозможной. Нужна защита, которая работает даже тогда, когда cookie уже украден.
Второй уровень: привязка сессии к устройству (DBSC)
Именно это делает Device Bound Session Credentials. В апреле 2026 года Google сообщил о доступности функции для пользователей Windows в Chrome 146, а расширение на macOS ожидается в одной из следующих версий. Проект анонсирован ещё в апреле 2024 года и разрабатывается как открытый стандарт в рабочей группе W3C вместе с Microsoft.
Механизм устроен так. При входе браузер создаёт пару ключей — открытый и закрытый. Закрытый хранится в защищённом аппаратном модуле: на Windows это TPM, на macOS — Secure Enclave, и извлечь его с компьютера нельзя. Сервер выдаёт короткоживущие cookie только после того, как Chrome докажет, что у него есть этот закрытый ключ. Для каждой сессии создаётся отдельный ключ, а лишние идентификаторы устройства серверу не передаются.
Теперь представим кражу. Инфостилер забрал cookie и отправил его злоумышленнику. Но cookie живёт недолго, а продлить его без закрытого ключа нельзя — а ключ остался в модуле на вашем компьютере. Через короткое время украденный файл превращается в мусор. Google отмечает, что для сессий под защитой DBSC наблюдается значительное снижение случаев кражи сессий; цифры в статье приведены самим Google, независимой проверки я не нашёл.
Что DBSC не решает
Важно не переоценивать. Из описания самого Google следует несколько ограничений. Во-первых, DBSC не мешает программе украсть cookie — он делает его бесполезным спустя короткое время. У злоумышленника остаётся окно, пока cookie ещё действует. Во-вторых, нужен защищённый модуль: для устройств без него программные ключи пока только изучаются. В-третьих, сайт должен сам поддержать протокол: добавить на сервере конечные точки регистрации и обновления сессии. Если ваш сервис этого не сделал, ваша сессия защиту не получит. В-четвёртых, поддержка входа через единый вход (SSO) и привязка к уже существующим ключам вроде аппаратных токенов ещё в разработке.
И главное: DBSC не лечит заражённый компьютер. Пока на нём работает вредоносная программа, она может видеть всё, что вы вводите, и делать запросы изнутри вашей сессии, пока вы онлайн.
Что делать вам
Меры простые и не требуют технических знаний. Обновляйте Chrome и операционную систему: защита появляется именно с новыми версиями. Ставьте программы только с официальных сайтов и из магазинов приложений, не запускайте «взломанные» версии платного софта и файлы из случайных писем.
Если подозреваете заражение, действовать нужно в определённом порядке. Сначала проверьте компьютер антивирусом, лучше с чистого устройства смените пароли и главное — завершите все активные сессии. Во многих сервисах есть пункт «Выйти на всех устройствах»: именно он аннулирует украденные cookie, потому что сервер перестаёт считать сессию действительной. Смены пароля может быть недостаточно, если сервис не сбрасывает старые сессии при его изменении. OWASP советует делать именно так: после выхода или смены прав сессию нужно аннулировать на сервере, а не просто удалять cookie в браузере.
Включите двухфакторную проверку везде, где можно, но понимайте её роль: она защищает от кражи пароля, а не от кражи уже подтверждённой сессии. Для важных сервисов — почты, банков, госуслуг — полезно периодически смотреть список устройств и входов и закрывать незнакомые.
Коротко
Украсть аккаунт без пароля можно, потому что сайт доверяет cookie сессии так же, как вашему входу. Cookie уводят инфостилеры с заражённого компьютера, и двухфакторная проверка тут не спасает. Chrome отвечает в два шага: шифрование cookie на диске и, главное, привязка сессии к устройству через DBSC, которая с Chrome 146 на Windows делает украденный cookie быстро бесполезным. Это работает не везде: нужен защитный модуль и поддержка сайта. Личные правила остаются прежними: обновления, официальный софт, выход со всех устройств при подозрении и чистый компьютер.
Пока нет комментариев