Для веб-разработчиков этот инцидент - важный урок. Он показывает, как уязвимости в user scripts могут привести к цепной реакции. Разберем, что случилось, и как защитить свои проекты от подобных угроз.

Как червь проник в систему

Червь прятался в скрипте User:Ololoshka562/test.js на русской Википедии с марта 2024 года. Его случайно запустил сотрудник Wikimedia во время проверки user script. Скрипт активировался в браузере авторизованного пользователя и начал само распространение.

Сначала онил вредоносный loader в личный common.js пользователя. Затем попытался перезаписать глобальный MediaWiki:Common.js, который загружается для всех авторизованных посетителей. Если пользователь имел права на редактирование глобального скрипта, цепочка замыкалась - каждый новый посетитель запускал червя заново. Одновременно скрипт вандализировал случайные страницы через Special:Random, добавляя огромную картинку Woodpecker10.jpg и скрытый loader с basemetrika.ru.

Весь процесс занял 23 минуты, но успел затронуть тысячи страниц. Wikimedia ввели read-only режим на два часа, откатили изменения и удалили ссылки на вредоносный код из историй правок.

Вот этапы распространения:

• Активация: Запуск test.js в браузере с правами.
• Локальное заражение: Инъекция в personal common.js.
• Глобальное заражение: Перезапись MediaWiki:Common.js.
• Вандализм: Добавление изображений и внешних скриптов на случайные страницы.

Уязвимости в user scripts и как они эксплуатируются

User scripts в системах вроде MediaWiki - это пользовательские JavaScript-файлы, которые расширяют функционал. Они удобны, но опасны, если не контролировать их выполнение. В случае с Википедией скрипт лежал два года незамеченным, пока не сработал.

Злоумышленники любят такие векторы: они используют авторизованные сессии браузера для правок от имени пользователя. Червь не взламывал сервер - он работал в клиентской среде, эксплуатируя доверие к глобальным скриптам. Это классический client-side XSS через user-generated JS.

Похожие атаки бывали раньше на wiki-проекты. Без строгой модерации user scripts становятся бомбой замедленного действия. Разработчики должны понимать, что любой загружаемый JS может мутировать и распространяться.

Ключевые риски:

• Долгоживущие скрипты: Могут активироваться случайно.
• Глобальные файлы: Один компромисс заражает всех.
• Авторизованные сессии: Браузер делает правки от имени пользователя.
• Внешние loader’ы: Загружают код с подозрительных доменов.

Чтобы оценить угрозу, сравним с обычным XSS:

Уроки безопасности для веб-разработчиков

Этот случай учит проверять все пользовательские скрипты. Внедряйте Content Security Policy (CSP), чтобы блокировать inline JS и внешние источники. Настройте strict-dynamic для динамических скриптов.

Ограничивайте права: не все пользователи должны редактировать глобальные JS. Используйте sandbox для user scripts - выполняйте их в изолированной среде без доступа к DOM или API. Мониторьте изменения в common.js через логи и алерты.

Регулярный аудит - ключ. Сканируйте репозитории на старые скрипты, как test.js. Интегрируйте инструменты вроде ESLint с правилами против self-propagating кода.

Практические меры:

• CSP: Запретите unsafe-inline и eval().
• Sandbox iframes: Для user content.
• Автооткат: Системы revert на подозрительные правки.
• Мониторинг: Логи правок в реальном времени.
• Rate limiting: Ограничьте правки по IP/сессии.

Что взять на вооружение в проектах

Инцидент с Википедией напоминает: клиентский JS - слабое звено в больших платформах. Даже гиганты вроде Wikimedia уязвимы, если user content не под контролем. Стоит пересмотреть подходы к кастомным скриптам.

Остается открытым вопрос: как детектировать dormant угрозы заранее? Инструменты эволюционируют, но человеческий фактор остается. Подумайте, есть ли в вашем коде ‘спящие’ скрипты, ждущие активации.