Разработчики плагинов и тем: вот что вы можете узнать из уязвимости безопасности нашего SDK
Опубликовано: 2019-03-02Эта неделя была довольно напряженной для нашей команды, так как нам пришлось столкнуться с уязвимостью в системе безопасности. Безопасность является для нас главным приоритетом, и это первая серьезная уязвимость, обнаруженная в нашем SDK за четыре года. К сожалению, как и в случае с любым программным обеспечением, разработчики тоже люди, поэтому ошибки случаются, независимо от того, являетесь ли вы независимым разработчиком, магазином тем из 20 человек или Google. Цель этой статьи — прежде всего обеспечить прозрачность, а также дать вам представление о том, как мы справились с инцидентом, и что вы можете извлечь из этого.
В понедельник, 25 февраля 2019 г., мы получили электронное письмо в службу поддержки от полезного разработчика, который наткнулся на проблему GitHub в репозитории WooCommerce. Проблема была создана представителем небольшой хостинговой компании, которая заметила подозрительную активность на своих серверах. Представитель включил соответствующие журналы действий, которые указали на две потенциальные атаки, и одна из них была нацелена на плагин, работающий с Freemius SDK.
Поскольку мы очень серьезно относимся к безопасности, мы немедленно провели тщательное расследование и подтвердили, что уязвимость действительно была в нашем SDK.
Из-за серьезности уязвимости мы сразу же начали работу над исправлением. Всего через несколько часов мы выпустили исправленный тег и уведомили всех разработчиков, использующих уязвимую версию SDK, о необходимости как можно скорее обновить SDK во всех своих продуктах. Мы также обновили исходную проблему GitHub, чтобы сообщить о ней команде WooCommerce (проблему GH мы удалили через несколько часов, чтобы уменьшить воздействие).
Чтобы смягчить воздействие и дать всем льготный период для обновления до исправленной версии, мы попросили разработчиков о двух вещах:
(a) Если это обновление безопасности будет включено в ваш журнал изменений, используйте только общие формулировки, такие как «Исправление безопасности».
(b) Даже после обновления и выпуска исправленных версий не сообщайте об этой проблеме в течение следующих 30 дней, чтобы у всех наших партнеров и их пользователей было достаточно времени для обновления.
Всего через день веб-сайт, посвященный уязвимостям плагинов (намеренно не ссылаясь на них и не упоминая их названия), опубликовал сообщение об уязвимости, включая информацию о том, как ее использовать, и назвал несколько уязвимых плагинов. Это застало нас врасплох, поскольку мы только что уведомили разработчиков плагинов и тем о проблеме менее чем за 24 часа до этого. Они не связывались с нами и не следовали рыночной практике ответственного раскрытия информации , которую мы считаем довольно безответственной и неэтичной.
Я обратился к ним с просьбой временно отменить публикацию отчета, чтобы уменьшить воздействие и дать нашим разработчикам и их пользователям возможность обновиться до исправленных версий, прежде чем он привлечет нежелательное внимание со стороны большего числа хакеров. Но человек, с которым я общался, который никогда не раскрывал своего имени (я спросил их), имеет свою праведную идеологию и, похоже, здравый смысл их не очень-то привлекает. Я пытался объяснить проблемную ситуацию и повышенный риск, которому они подвергают многих разработчиков и пользователей, но мои усилия остались без внимания, и я понял, что обмен электронной почтой был пустой тратой времени.
Поскольку сообщество наших разработчиков обновляло свои плагины и темы для недавно выпущенного исправленного SDK, мы обнаружили две проблемы:
- Несколько разработчиков не получили наше уведомление по электронной почте, потому что они зарегистрировались на Freemius с адресом электронной почты, который они не проверяют.
- Мы намеренно не помечали исправленный тег GitHub как официальный выпуск, чтобы не привлекать внимания. Однако мы узнали, что разработчики, которые использовали Composer для обновления своих библиотек, не получали последнее обновление, потому что packgist извлекает только выпуски, если явно не указан тег.
Чтобы преодолеть эти проблемы:
- Поскольку уязвимость уже была опубликована, два дня назад мы пометили исправленную версию как официальный выпуск, чтобы разработчики, использующие packgist, могли ее обновить.
- Сегодня утром мы разослали еще одну порцию сообщений разработчикам, которые еще не обновили SDK для всех своих продуктов. На этот раз мы отправили сообщения в их официальные каналы поддержки, чтобы увеличить шансы на то, что все получат сообщения должным образом.
Несмотря на то, что мы хотели отложить публикацию этой уязвимости как минимум на две недели, мы получили дополнительный запрос от WP Tavern с просьбой внести свой вклад, прежде чем они опубликовали свою собственную статью на эту тему, которая стала соломинкой, которая сломала клавиатуру разработчика.
Ошибки, которые мы совершили, и чему вы можете на них научиться
Оглядываясь назад на инцидент, мы допустили несколько ошибок, которых можно было бы легко избежать и которые значительно облегчили бы всем жизнь.
Перейдите в беззвучный режим и предупредите только тех, кому нужно знать
Поскольку мы так стремились исправить проблему как можно скорее, я лично совершил ошибку «новичка», которая слишком рано привлекла нежелательное внимание. Я пошел дальше и зафиксировал исправление в репозитории GitHub, который мы используем для управления SDK. Мало того, что репозиторий общедоступен, я еще объяснил исправление и использовал в нем слово «безопасность».
Лучшим подходом было создать частную/закрытую версию репозитория, исправить там проблему безопасности и предоставить ее только соответствующим разработчикам, а не делать ее общедоступной. Это не привлекло бы внимания «охотников за уязвимостями».
Не тратьте свою энергию на «троллей безопасности»
Второй ошибкой была попытка взаимодействия с компанией, стоящей за сайтом, опубликовавшим уязвимость. Это была пустая трата времени и энергии, и это только вызвало еще больший антагонизм, который закончился еще одним постом об уязвимости. Я бы сказал, что хорошим показателем, позволяющим решить, стоит ли вам связываться с автором поста, который подвергает риску пользователей вашего плагина или темы, является наличие имени за постом/веб-сайтом/компанией. Если они прячутся за доверенными лицами и ведут себя иррационально, шанс, что вы сможете их вразумить, практически нулевой.
Так что мой совет — переходите в беззвучный режим и сообщайте об уязвимости только тем людям, которые должны знать об уязвимости. В случае плагина/темы это ваши пользователи. Это также хорошая возможность подчеркнуть важность сбора электронных писем ваших пользователей. Если у вас нет возможности общаться с пользователями в частном порядке, у вас нет эффективного способа уведомлять их в частном порядке о проблемах безопасности.
Текущий статус инцидента
Более 60% разработчиков, использующих наш SDK, уже обновились до исправленной версии. Кроме того, SDK поставляется со специальным механизмом, который позволяет нескольким поддерживаемым Freemius плагинам или темам, установленным на одном и том же веб-сайте WordPress, использовать новейшую версию SDK, если один из продуктов уже обновлен. Так что это хорошо.
Тем не менее, есть еще много уязвимых сайтов. Вот почему я не упомянул никаких технических подробностей ни о самой уязвимости, ни о уязвимых продуктах. Мы по-прежнему хотим предложить нашим разработчикам возможность исправлять свои продукты и позволять их пользователям обновляться до безопасных версий.
Как снизить риски безопасности в вашем плагине/теме WordPress?
Если у вас нет никакого опыта в области безопасности, погуглите «лучшие практики веб-безопасности», и вы найдете массу статей и практических рекомендаций. Прочтите несколько из них, чтобы быть в курсе современных и типичных потенциальных рисков и ошибок. Помните об этом в процессе разработки и тестирования. Другой хорошей практикой является проведение периодических аудитов безопасности путем найма исследователя безопасности. Это будет стоить несколько сотен долларов, но если вы полагаетесь на свой продукт как на основной источник дохода, это не проблема.
К сожалению, как и в нашем случае, плохие вещи все еще могут случиться. Несмотря на то, что у нас очень хороший опыт в области безопасности, мы проводим тщательную проверку кода и работаем с опытным исследователем безопасности из сообщества HackerOne, тем не менее, эта уязвимость все еще не раскрыта. 😔
Я думаю, что одна из причин, по которой это произошло, заключается в том, что уязвимый код фактически был добавлен в крайние случаи отладки и не является частью основных функций SDK. Так что, если здесь есть урок, обращайтесь с любой частью кода вашего продукта одинаково, независимо от того, является ли она частью фактической бизнес-логики или чем-то еще.
Резюме
Проблемы безопасности неизбежны в мире программного обеспечения. Нравится нам/вам это или нет, но однажды у вашего плагина или темы возникнет проблема с безопасностью. Проблема может быть в вашем коде, используемой вами библиотеке/фреймворке, основном методе WordPress, который дает неожиданные результаты, и многих других сценариях.
Когда это произойдет (я надеюсь, что этого не произойдет), не напрягайтесь (мы определенно это сделали) и действуйте импульсивно — это только нанесет больше вреда. Составьте методологический план восстановления, уведомите затронутые стороны и будьте рядом , чтобы помочь своим пользователям защитить свои сайты. Все знают, что проблемы с безопасностью случаются, важнее то, как вы справляетесь с ситуацией.
С учетом сказанного, от имени всей команды Freemius мы искренне приносим извинения за неудобства и будем здесь в течение всех выходных, чтобы предложить поддержку, совет или любую другую помощь, связанную с проблемой. А для наших новых пользователей я знаю, насколько важно первое впечатление, и оно точно не очень хорошее. Я надеюсь, что вы дадите Freemius еще один шанс и со временем увидите удивительные функции, которые мы предлагаем для ваших плагинов и тем WordPress.