Миллионы сайтов уязвимы к XSS из-за корявой имплементации OAuth

Миллионы сайтов уязвимы к XSS из-за корявой имплементации OAuth

Миллионы сайтов уязвимы к XSS из-за корявой имплементации OAuth

Исследователи из Salt Labs обнародовали разбор нового вектора XSS-атаки (межсайтовый скриптинг), который в теории может угрожать миллионам сайтов по всему миру.

Стоит учитывать, что это не уязвимость в каком-либо продукте, поэтому её нельзя устранить централизованно. Корень проблемы кроется в сочетании веб-кода с популярным приложением OAuth.

Не так давно мы разбирали уязвимости протокола OAuth 2.0 и оценивали, опасно ли аутентифицироваться через профиль в социальных сетях. А в мае на Anti-Malware.ru рассказывали о том, как противостоять растущему числу атак с использованием OAuth-приложений.

В описанном Salt Labs векторе проблема не в самом OAuth, а скорее в его реализации на веб-сайтах. Если администратор ресурса недостаточно качественно имплементировал OAuth (что случается довольно часто), у злоумышленников открывается возможность провести XSS-атаку и получить контроль над аккаунтом.

В отчёте Salt Labs утверждается, что описанная проблема была обнаружена на сайтах таких крупных проектов, как Booking.com, Grammarly и OpenAI. Если администраторы этих ресурсов не смогли должным образом имплементировать OAuth, чего можно ждать от менее значимых веб-сайтов, спрашивают эксперты.

«Если мы продолжим прощупывать разные интернет-проекты, мы гарантированно найдём больше сайтов с этой проблемой. Я убеждён в этом», — пишет Янив Балмас из Salt Labs.

«Для эксплуатации этой бреши мы использовали JavaScript-код, который запускал поток OAuth-аутентификации в новом окне, а затем считывал токен из этого окна».

Google перенаправляет пользователя, но с «секретами» аккаунта в URL, а код JS считывает URL-адрес из новой вкладки и вытаскивает оттуда учётные данные.

Salt Labs создала специальный сканер, с помощью которого владельцы сайтов смогут узнать, уязвимы ли их проекты.

GitHub сделает платными собственные раннеры для Actions

GitHub меняет подход к оплате Actions и готовится брать деньги за то, что раньше было бесплатным. С марта компания начнёт взимать плату за использование собственных раннеров в приватных репозиториях — по $0,002 за минуту работы. Для публичных репозиториев ничего не меняется: там собственные раннеры по-прежнему бесплатны.

Об изменениях GitHub сообщил в блоге, одновременно анонсировав снижение цен на GitHub-раннеры с 1 января. Всё это компания объединяет под лозунгом «более простое ценообразование и лучший опыт работы с GitHub Actions».

Реакция крупных пользователей оказалась ожидаемой. В DevOps-сообществе новость встретили без энтузиазма. Один из пользователей Reddit рассказал, что для его команды новые тарифы означают плюс около $3,5 тыс. в месяц к счёту GitHub — и это при использовании собственных серверов.

В GitHub объясняют решение тем, что собственные раннеры годами фактически пользовались инфраструктурой Actions бесплатно. По словам компании, развитие и поддержка этих сервисов всё это время субсидировались за счёт цен на GitHub раннеры, и теперь расходы хотят «привести в соответствие с фактическим использованием».

При этом GitHub уверяет, что большинство пользователей изменений не почувствует. По оценке компании:

  • 96% клиентов не увидят роста расходов вообще;
  • из оставшихся 4% у 85% затраты даже снизятся;
  • для оставшихся 15% медианный рост составит около $13 в месяц.

Для тех, кто использует самохостные раннеры и хочет заранее понять, во что это выльется, GitHub обновил калькулятор цен, добавив туда новые расчёты.

Тем не менее для крупных команд и корпоративных проектов нововведение может стать поводом пересмотреть CI/CD-процессы — особенно если их раннеры использовались активно именно ради экономии.

RSS: Новости на портале Anti-Malware.ru