Comments 23
Свои проекты перетащил на gitlab. Github остался только для обратной совместимости…
Не думаю, что тут виноват майрософт. У меня к нему давняя нелюбовь, но в последнее время они очень хорошо маскируются под хороших ребят. Прям хочется верить. Даже дико популярный в последнее время vscode чего стоит.
Скорее причина кроется в том, из-за чего собственно гитхаб отошёл майрософту. У них банально не хватало ресурсов ни на какие нововведения и фиксы. А сейчас они много новых плюшек выкатывают. Хотя странно видеть «реовлюционное нововведение» в виде встроенного в клиент гитхаба способа разрешения конфликтов, который уже есть в любой IDE… Но надо же с чего-то начинать, чтобы догонять.
Да и, хотя я пеняю в этом посте на их безопасность, основные важные вещи у них таки покрыты программой bug bounty. Есть у меня ощущение, что более адекватный человек из поддержки понял бы суть проблемы сломавшегося механизма (я думаю, он был, но сломался) — но мне не повезло. Писать ещё один репорт бесполезно, поэтому решил вынести это наружу.
Верно подмечено, однако аналогия некорректна в силу толстых нюансов:
1) У большинства хостингов или выделенные IP, или есть некоторый разброс адресов. Придётся искать конкретные хостинги, которые имеют только один IP. Довольно геморройное занятие.
2) Хостинги не бесплатны, в отличие от репозиториев на гитхабе. Поэтому занятие резко становится менее интересным. Да ещё и надо входить в каждую отдельную панель, закачивать файлы сотней разных способов… Совсем неинтересно.
3) Хостинги не заинтересованы в защите доменов, и не имеют возможности связаться с предыдущим владельцем хостинга. Видимо, гитхаб тоже не заинтересован, что печально, однако средство связи (узнать, у кого было привязано это имя ранее) у них есть.
4) Опять же, можно хотя бы проверять факт, был ли ранее привязан куда-то домен, и на основании этого запрашивать проверочную NS запись.
Формально да. Но в таком случае зачем в руководстве указано ставить именно CNAME своего репозитория? Всё же есть явное ощущение, что в планах было использовать его для аутентификации, благо технически это легко (они и так на этапе привязки проверяют, есть ли CNAME на гитхаб, так что ничего сложнее не станет) — но то ли забыли, то ли сломали.
Причина этому — моё прошлое в качестве айти-безопасника, скажем так, попроще.
Да, это удобно. Это очень удобно — проектики ваши, синхронизация, профиль, все дела.
Но вы никогда не думали о том, что в один прекрасный момент кто-то это всё сломает?
Куда потекут ваши «закрытые» данные?
Поэтому, я считаю, всё, что представляет интеллектуальную ценность, просто обязано храниться на ваших же ресурсах. Физически ваших ресурсах. И устраивайте себе на ваших ресурсах всё, что угодно, сейчас возможностей масса.
А плохо и небезопасно всё то, над чем вы лично не имеете контроля. Будь то страничка в vk, профиль в git, облачко… и так далее. Задумайтесь.
К тому же, когда мы говорим про github, то редко подразумеваем закрытые данные — основной смысл эта площадка имеет при совместной работе над open source. А открытый код никуда не утечёт.
И гитхаб не единственный, кто этим страдает. По сути вся индустрия сейчас движется в таком же направлении, к сожалению. Есть даже тулза tko-subs, которая парсингом ответа сервера проверяет на возможность его (домена) захвата. Можете посмотреть примерный масштаб трагедии (там далеко не все уязвимые сервисы, их гораздо больше): github.com/anshumanbh/tko-subs/blob/master/providers-data.csv
Ну смотря с какой стороны посмотреть. И гитхаб и другие провайдеры не считают это своей уязвимостью, они считают это уязвимостью тех, кто коряво настраивает свои поддомены в их сервисах, даже если это было сделано неявно, как в этой статье. И даже майкрософт тут не причем, это было задолго до него :)
Могу подлить лишь масла в огонь, сказав что та самая тулза tko-subs умеет автоматически захватывать домены (в т.ч. на github pages), если запустить ее с ключом -takeover. То есть, скорее всего, атакующие даже не видят какие именно поддомены захватывают, ведь за них все делает скрипт.
Дело в том, что я хочу привязать к своему домену 3 уровня github-pages, которые репозиторий в организации. И пляски с бубном очень неочевидные :(
Правильный способ:
1. Добавляешь в репо CNAME
2. Добавляешь в DNS домена IP github pages
Неправильный способ:
1. Добавляешь в DNS домена IP github pages
*. Кто-то может добавить CNAME в свой репо быстрее тебя
2. Добавляешь в репо CNAME
Нужно действовать правильным способом, тогда проблем и не будет. А то начнем называть пароли типа 123456 проблемой сервиса, а не пользователя.
Атака на Github Pages с перехватом сайта на вашем домене