😳 CFOR: Уязвимость GitHub
🛡 GitHub — популярная платформа для управления кодом, но не все задумываются о том, как она хранит данные. Одним из рисков является уязвимость CFOR (Cross Fork Object Reference), которая позволяет получить доступ к данным, которые должны быть скрыты или удалены.
🔍 Что такое CFOR? Это возможность получить доступ к данным из одного форка репозитория через другой, даже если исходный форк был удалён или является приватным. Похожая на IDOR (Insecure Direct Object Reference) уязвимость, позволяет злоумышленникам использовать хэши коммитов для доступа к данным.
📂 Три сценария уязвимости CFOR:
1. Доступ к данным из удалённых форков: Даже после удаления форка коммиты остаются доступными через исходный репозиторий при наличии хэша коммита.
2. Доступ к данным из удалённых репозиториев: При удалении репозитория, данные остаются доступными через существующие форки.
3. Доступ к данным из приватных репозиториев: При публикации приватного репозитория его данные могут остаться доступными в публичной версии, несмотря на приватные форки.
❓ Почему это возможно? GitHub хранит данные в сети репозиториев, где удаление репозитория или форка не приводит к физическому удалению данных, а лишь удаляет ссылки на них в интерфейсе. Таким образом, зная хэш коммита, можно получить прямой доступ к этим данным.
🔍 Как ищут хэши коммитов?
- Брутфорс: GitHub использует короткие SHA-1 хэши, которые можно подобрать.
- API событий: Публичный API GitHub может содержать хэши коммитов.
- Архивы событий: Сторонние сервисы архивируют события GitHub, где могут быть хэши.
💡Данные, закоммиченные в публичный репозиторий, могут остаться доступными навсегда. Надёжный способ защиты — регулярная ротация ключей.
Stay secure and read SecureTechTalks 📚
#GitHub #Кибербезопасность #SecureTechTalks #CFOR #IDOR #ИнформационнаяБезопасность
🛡 GitHub — популярная платформа для управления кодом, но не все задумываются о том, как она хранит данные. Одним из рисков является уязвимость CFOR (Cross Fork Object Reference), которая позволяет получить доступ к данным, которые должны быть скрыты или удалены.
🔍 Что такое CFOR? Это возможность получить доступ к данным из одного форка репозитория через другой, даже если исходный форк был удалён или является приватным. Похожая на IDOR (Insecure Direct Object Reference) уязвимость, позволяет злоумышленникам использовать хэши коммитов для доступа к данным.
📂 Три сценария уязвимости CFOR:
1. Доступ к данным из удалённых форков: Даже после удаления форка коммиты остаются доступными через исходный репозиторий при наличии хэша коммита.
2. Доступ к данным из удалённых репозиториев: При удалении репозитория, данные остаются доступными через существующие форки.
3. Доступ к данным из приватных репозиториев: При публикации приватного репозитория его данные могут остаться доступными в публичной версии, несмотря на приватные форки.
❓ Почему это возможно? GitHub хранит данные в сети репозиториев, где удаление репозитория или форка не приводит к физическому удалению данных, а лишь удаляет ссылки на них в интерфейсе. Таким образом, зная хэш коммита, можно получить прямой доступ к этим данным.
🔍 Как ищут хэши коммитов?
- Брутфорс: GitHub использует короткие SHA-1 хэши, которые можно подобрать.
- API событий: Публичный API GitHub может содержать хэши коммитов.
- Архивы событий: Сторонние сервисы архивируют события GitHub, где могут быть хэши.
💡Данные, закоммиченные в публичный репозиторий, могут остаться доступными навсегда. Надёжный способ защиты — регулярная ротация ключей.
Stay secure and read SecureTechTalks 📚
#GitHub #Кибербезопасность #SecureTechTalks #CFOR #IDOR #ИнформационнаяБезопасность
💻 Что такое уязвимости IDOR и как их эксплуатировать?
IDOR (Insecure Direct Object Reference) — это уязвимость, возникающая при неправильной проверке доступа к объектам данных в веб-приложениях или API. Злоумышленники могут напрямую обращаться к данным без должных прав, если приложение не проверяет владельца объекта. Такие данные могут быть любыми: от записей в базе данных до файлов на сервере.
🔑 Как возникают уязвимости IDOR? Часто уязвимость появляется, когда разработчики используют предсказуемые идентификаторы, например, числовые значения. Если веб-приложение позволяет пользователям взаимодействовать с этими идентификаторами без должной проверки, можно получить доступ к данным, которые должны быть закрыты.
⚙️ Как выявить уязвимость IDOR? Для поиска таких уязвимостей важно проверять, как веб-приложение обрабатывает идентификаторы объектов. Тестирование следует проводить не только для основных функций, но и для менее очевидных компонентов, например, автосохранения или черновиков.
🛠 Эксплуатация IDOR-уязвимостей Один из основных методов эксплуатации — изменение предсказуемого идентификатора. Например, замена числового значения на другое может позволить злоумышленнику получить доступ к чужим данным. Дополнительно можно использовать методы загрязнения параметров, JSON globbing или менять метод запроса для обхода проверок доступа.
📊 Вторичные уязвимости сложнее обнаружить, так как они возникают, когда идентификатор сохраняется для последующего использования. Примером может служить задача экспорта данных, когда идентификатор сохраняется и позже используется для генерации отчёта без дополнительных проверок прав доступа.
🚨 Несмотря на то, что IDOR-уязвимости могут показаться простыми для обнаружения, они часто требуют глубокого анализа и нестандартных подходов.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #IDOR #уязвимости #SecureTechTalks #багбаунти #обфускация
IDOR (Insecure Direct Object Reference) — это уязвимость, возникающая при неправильной проверке доступа к объектам данных в веб-приложениях или API. Злоумышленники могут напрямую обращаться к данным без должных прав, если приложение не проверяет владельца объекта. Такие данные могут быть любыми: от записей в базе данных до файлов на сервере.
🔑 Как возникают уязвимости IDOR? Часто уязвимость появляется, когда разработчики используют предсказуемые идентификаторы, например, числовые значения. Если веб-приложение позволяет пользователям взаимодействовать с этими идентификаторами без должной проверки, можно получить доступ к данным, которые должны быть закрыты.
⚙️ Как выявить уязвимость IDOR? Для поиска таких уязвимостей важно проверять, как веб-приложение обрабатывает идентификаторы объектов. Тестирование следует проводить не только для основных функций, но и для менее очевидных компонентов, например, автосохранения или черновиков.
🛠 Эксплуатация IDOR-уязвимостей Один из основных методов эксплуатации — изменение предсказуемого идентификатора. Например, замена числового значения на другое может позволить злоумышленнику получить доступ к чужим данным. Дополнительно можно использовать методы загрязнения параметров, JSON globbing или менять метод запроса для обхода проверок доступа.
📊 Вторичные уязвимости сложнее обнаружить, так как они возникают, когда идентификатор сохраняется для последующего использования. Примером может служить задача экспорта данных, когда идентификатор сохраняется и позже используется для генерации отчёта без дополнительных проверок прав доступа.
🚨 Несмотря на то, что IDOR-уязвимости могут показаться простыми для обнаружения, они часто требуют глубокого анализа и нестандартных подходов.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #IDOR #уязвимости #SecureTechTalks #багбаунти #обфускация
❤1😢1