Chrome будет шифровать данные пользователя

Chrome будет шифровать данные пользователя

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

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

Например, в Chromium и Chrome куки хранятся в файле, который называется Cookies и представляет собой обычную базу данных SQLite. Ее можно загрузить в любой редактор SQL, скажем, через расширение SQLite Manager браузера Firefox – и просмотреть все куки в открытом виде. Однако скоро это изменится, пишет Xakep.ru.

Chromium станет первым браузером, который начнет шифровать куки в локальном хранилище. Разработчики свободного браузера приняли патч 24734007, который предусматривает шифрование всех файлов cookies на диске. Через какое-то время патч станет частью всех версий браузера Chrome на настольных компьютерах (в Chrome OS и Android профили пользователя уже сейчас шифруются).

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

По мнению специалистов Google, падение производительности в связи с шифрованием файлов не слишком значительное: под Windows задержка составит около 0,7 миллисекунды.

Шифрование куков осуществляется после авторизации в браузере. Так что если злоумышленник получит доступ к браузеру после авторизации, или он знает главный пароль, то эта мера защиты не сработает.

Если вы пользуетесь программами для сквозного шифрования диска, то отдельное шифрование куков тоже не имеет особого смысла.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

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

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

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

Проверка тоже оказалась поверхностной: агент посмотрел на названия папок верхнего уровня, которые могли сохраняться, пока их содержимое исчезало.

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

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

RSS: Новости на портале Anti-Malware.ru