Самораспространяющийся JavaScript-червь атаковал Википедию: уроки для веб-разработчиков

hannadev

Недавно самораспространяющийся JavaScript-червь поразил Википедию, вандализировав тысячи страниц. Это произошло на Meta-Wiki платформы Wikimedia, где вредоносный скрипт активировался после двух лет спячки и заразил 3996 страниц, перезаписав common.js у 85 пользователей.

Для веб-разработчиков этот инцидент - важный урок. Он показывает, как уязвимости в 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.
Вандализм: Добавление изображений и внешних скриптов на случайные страницы.

Этап	Описание	Последствия
Активация	Случайный запуск старого скрипта	Один пользователь заражен
Локальное заражение	Инъекция в common.js	85 пользователей пострадали
Глобальное	Перезапись глобального JS	Потенциал для массового заражения
Вандализм	Модификация страниц	3996 страниц изменены

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

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

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

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

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

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

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

Тип атаки	Где выполняется	Масштаб	Пример
Classic XSS	Серверный ввод	Локальный	Форма комментариев
DOM XSS	Клиентский JS	Страница	URL-параметры
User script worm	User JS файлы	Глобальный	Википедия-червь

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

Этот случай учит проверять все пользовательские скрипты. Внедряйте 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/сессии.

Инструмент	Назначение	Преимущества
CSP	Блокировка JS	Простая настройка
Subresource Integrity (SRI)	Хэш скриптов	Защита от tamper
Service Workers	Прокси JS	Контроль загрузки
OWASP ZAP	Сканер	Автообнаружение

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

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

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