https://opennet.ru/openforum/vsluhforumID3/134384.html Компания Truffle Security опубликовала сценарии атак на несколько типовых приёмов работы с репозиториями на GitHub, позволяющие извлечь данные из удалённых репозиториев, у которых имеются публичные форки или которые были созданы как форки...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61605<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#38 Sat, 27 Jul 2024 18:28:21 GMT Очень даже реальный случай: с частного репозитория лилась потоком метаинформация типа "новый коммит + заголовок" на радость публике в канал Discord. В один прекрасный день один из коммитов был тестово-пентестовым. "Немного" раскрыл удавшуюся шалость в отношении auth сервера одной из дочерних компаний Microsoft. На самом деле много раскрыл, правда кипишь поднялся не по этой причине.<br><br>А тут же получается бывший публичный проект + непубличный форк + коммит = раскрытие информации. Коммиты либо 6-12 хексов запечатываются как build id или, как они показали, перебором. А все почему? Не проверяется принадлежность коммита к репозиторию ему создавшему, потому что объектное хранилище значит одно, а их ПО не утруждает себя ведением состояния и прав, и проверкой доступа.<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#35 Fri, 26 Jul 2024 20:09:58 GMT Если цель не работать, а привлекать любых соблазнившизся коммитеров - тогда да.<br>В остальном всё с ног на голову: ценность не в коде, который ты собрался писать, а в чужой платформе, куда ты собрался все выкладывать.<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#34 Fri, 26 Jul 2024 13:44:51 GMT Для оптимизации хранения же. Ты ещё скажи спасибо, что там глобальной дедупликации нет, что все репозитории не являются implicitly форком одного и того же репозитория и что любой файл нельзя получить просто по хэшу.<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#33 Fri, 26 Jul 2024 13:42:48 GMT &gt;Если нечаяно выложили логины/пароли, то их надо срочно менять, а не надеяться, что никто прочитать не успел.<br><br>А если кто-то в репозиторий по ошибке закоммитил секретную документацию, полученную от партнёров? Ждать, пока партнёр засудит, или всё же снести?<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#32 Fri, 26 Jul 2024 09:34:13 GMT Вы сами выложили данные на сервера гита, а теперь беспокоитесь, что они могу "утечь"?<br>Лол.<br>Ну так все проблемы гита из за - "би дезигн".<br>Зачем они эти обязательные форки оригинального репа, перед моим коммитом внедрили?<br>Теперь пожинают плоды.<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#31 Thu, 25 Jul 2024 21:40:30 GMT Уязвимость с выложенными паролями бредовая какая-то. Если нечаяно выложили логины/пароли, то их надо срочно менять, а не надеяться, что никто прочитать не успел.<br><br>Остальные "уязвимости" тоже уязвимости только в чьем-то воображении, кроме пожалуй доступа к приватной части репозитория, которая осталась закрытой после раскрытия другой части.<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#30 Thu, 25 Jul 2024 21:27:08 GMT После удаления в апстриме, вас вежливо попросят следовать тому же принципу. Если вы не пойдёте на встречу, то вас будут судить. Только уже тролли))<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#29 Thu, 25 Jul 2024 20:15:18 GMT А еще можно было просто склонировать репозиторий до того как удалили.. и да, там оно волшебным образом не удалится, когда у оригинальном репозитории чтото там удалят.<br><br>ахтунг, я открыл новую уязвимость!<br> https://opennet.ru/openforum/vsluhforumID3/134384.html#27 Thu, 25 Jul 2024 18:25:08 GMT &gt; Компания удалила репозиторий через который была утечка, но ключи по-прежнему остались доступны для извлечения через обращения по хэшу коммита в репозиториях с форками. <br><br>Если колбоса из бутерброда упала на пол и её успели поднять за 5 сек, то не считается что упала. Можно просто отряхнуть и вложить назад в бутер .. и подать клиенту на стол.<br>