Исследователь нашёл на GitHub случайно загруженные пользователями cookie-файлы из Firefox Статьи редакции

С помощью данных можно заходить на сайты под чужими логинами без пароля.

  • Через специальный поисковый запрос на GitHub можно найти данные cookies.sqlite пользователей Firefox, он выдаёт 4,5 тысячи результатов, рассказал британский эксперт Эйдан Марлин профильному изданию The Register. Марлин считает, что разработчики сами случайно загрузили свои данные вместе с другими в хранилище GitHub.
  • Марлин рассказал об ошибке в службу поддержки сервиса. Там пояснили, что «учётные данные, предоставленные пользователями сервиса, не входят в программу по поиску уязвимостей Bug Bounty». За поиск ошибок по программе пользователям платят деньги.
  • Через чужие cookies мошенники могут под разными логинами заходить на сайты, сбросить пароли и завладеть аккаунтами, говорят опрошенные изданием эксперты. По данным StatCounter, в октябре Mozilla Firefox пользовались 4,45% россиян.
0
38 комментариев
Написать комментарий...
Борат Язь

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

Ответить
Развернуть ветку
Юрий Б.

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

Вот информация для желающих разобраться, остальные пройдут мимо.

https://nakedsecurity.sophos.com/2021/11/18/github-cookie-leakage-thousands-of-firefox-cookie-files-uploaded-by-mistake/amp/

UPD: исходная новость на The Register

https://www.theregister.com/2021/11/18/firefox_cookies_github/

Ответить
Развернуть ветку
Andrei Apanasik

Да просто новость из ничего. "Пользователи по ошибке залили секьюрные данные".

Ответить
Развернуть ветку
Юрий Б.

UPD: исходная новость на The Register

https://www.theregister.com/2021/11/18/firefox_cookies_github/

Ответить
Развернуть ветку
Artem Petrenkov

Как-то так:
https://github.com/search?p=2&q=filename%3Acookies.sqlite&type=Code

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Маратка Тотсамый

У меня знакомый так попал, случайно логин пароль на серваки Амазона выложил, в гитхабе ,естественно этим воспользовались )))

Ответить
Развернуть ветку
Andrey Gordeev

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

В GitHub ответили исследователю, что «учётные данные, предоставленные пользователями сервиса, не входят в сферу охвата программы по поиску уязвимостей»

Причем тут вообще гитхаб?! В данном случае он использовался как хостинг файлов.
А журналист Ъ вообще не разбирается:

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

Кто они? Пользователи выложили свои кукисы на гитхаб? Или гитхаб выложил их куки🤦‍♂️

Ответить
Развернуть ветку
Artem Petrenkov
журналист
вообще не разбирается

Это тавтология :)

Ответить
Развернуть ветку
Andrei Apanasik

Люди вечно заливают креды/пароли/ключи. Это даже не взлом. В чём новость то? )

Ответить
Развернуть ветку
morgan

жирный плюс. сам так однажды спалил connection string от mongodb.

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

Ответить
Развернуть ветку
Alexey Smirnov

Жирный плюс, лично находил валидные апи-ключи к криптобиржам, позволяющие даже сделать вывод... (Взял и вернул немного для подтверждения концепта, сообщил хозяину, но вообще конечно диву даюсь) Там поле непаханное для таких "расследований"

Ответить
Развернуть ветку
Andrei Apanasik

Хорошо хоть в .env были, а то я порой встречаю, как в код зашивают.

Ответить
Развернуть ветку
Евгений Трофимов

Это ладно, у меня как-то фраза от кошелька с несколькими тысячами $ в публичном форке месяц пролежала. А чувак, который ее увидел, не увел деньги, а написал мне)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Влад Айнштейн

Батл не по фактам(

Ответить
Развернуть ветку
Влад Айнштейн

Если что, это осуждение к тому что в статье вообще нету никаких фактов.

Ответить
Развернуть ветку
blogerok

chrome - i love you

Ответить
Развернуть ветку
Влад Айнштейн

Причём тут хром?
Куки хранят все браузеры, а хром делает это самым ненадежным способом…

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Gre Li

Классика же: выкладка персональных данных в репозиторий.

Ответить
Развернуть ветку
Aleksandr Zapevalin

Папку с Selenium выкладывают

Ответить
Развернуть ветку
Vasya Aksyonov

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Алексей Винокуров

Например, у гитлаба можно случайно выложить собственные файлы .htpasswd и .htaccess и они уедут при публикации в gitlab pages. При этом работать не будут, а по прямой ссылке их можно скачать.

Я писал в поддержку, что имеет смысл их всё-таки скрывать, но для гитлаба это, оказывается, не является уязвимостью. Не благодарите.

Ответить
Развернуть ветку
Artem Petrenkov

Потому что это не проблема гита и репозитория — зачастую htaccess действительно нужно коммитить, например, в веб-приложениях: https://github.com/laravel/laravel/blob/8.x/public/.htaccess

В крайнем случае можно глобальный gitignore настроить.

Ответить
Развернуть ветку
Алексей Винокуров

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

Ответить
Развернуть ветку
Artem Petrenkov

Смотрите, вот я беру стандартный git, коммичу .htaccess и .htpasswd, затем пушу это всё в gitlab в публичный реп. Затем любой другой пользователь может склонировать его себе опять-таки через git. Если gitlab просто не будет показывать "опасные" файлы, то уязвимость никуда не денется.

Ответить
Развернуть ветку
Алексей Винокуров

Дело в том, что сами репы могут быть не публичными, а вот авто сборка и публикация на gitlab pages вытащит туда нежелательное. Я именно об этом. А так-то можно и свой env с рутовым доступом закинуть — "удобно" же, обновился и все сразу работает без настроек.

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

Ответить
Развернуть ветку
Artem Petrenkov

От pages ожидается стандартное поведение сервера Apache?

Ответить
Развернуть ветку
Алексей Винокуров

Я сам так на грабли наступил, когда на моем сервере апач работал как и ожидалось, а на pages — нет. Сначала настроил и потом уже стал разбираться почему не работает.

Ответить
Развернуть ветку
Artem Petrenkov

Скажите, откуда на GitLab Pages должен взяться Apache?

Если вы решили использовать его на своём локальном GitLab, то он будет работать только как reverse proxy, он не будет сам контролировать директории.

Ответить
Развернуть ветку
Алексей Винокуров

Так на pages его и нет. А весь деплой — это просто переписать статику из каталога web в public. Соответственно, туда же уехали и htaccess с htpasswd.

Ответить
Развернуть ветку
ei-grad

Как тут на vc токсично, куда ни плюнь - попадешь в эксперта по безопасности или короля багбаунти, которые как минимум в каждом своем проекте юзают vault, а то и dotfiles складывают в libastral.

Спасибо за статью, вроде про cookies.sqlite ещё не было. Тема с неосознанным коммитом секретов актуальна всегда, не лишним будет про нее напомнить.

Ответить
Развернуть ветку
morgan

точка gitignore в помощь

Ответить
Развернуть ветку
Artem Petrenkov

Тому, кто коммитит home, это не поможет.

Ответить
Развернуть ветку
ei-grad

Пока что помогает. Но больше помогает просматривать глазами каждый коммит в любом проекте, не важно dotfiles это или нет.

Ответить
Развернуть ветку
Oko Lenmi

Почему именно внимание на Firefox? На других браузерах эта фишка не сработает?

Ответить
Развернуть ветку
35 комментариев
Раскрывать всегда