Недавно Википедия столкнулась с атакой самораспространяющегося JavaScript-червя. Этот инцидент за 23 минуты заразил тысячи страниц и скрипты десятков редакторов. Разберём, как это произошло и что делать, чтобы ваши приложения не пострадали от похожих угроз.

Такие атаки показывают риски пользовательских скриптов в веб-проектах. Они помогают понять уязвимости и внедрить защиту заранее. В этой статье разберём механизм червя, последствия и практические меры безопасности.

Как работал JavaScript-червь в Википедии

Червь активировался случайно во время проверки безопасности. Старый вредоносный скрипт test.js из русскоязычной Вики запустился в браузере редактора и начал цепную реакцию. Сначала он внедрил загрузчик в персональный файл common.js пользователя, чтобы заражение сохранялось при повторных входах.

Дальше скрипт пытался переписать глобальный MediaWiki:Common.js, который загружается для всех авторизованных пользователей. Это создало петлю: каждый новый редактор, открывший страницу, подхватывал код и распространял его дальше. В результате изменилось около 3996 страниц, добавлялись огромные изображения и скрытые JS-загрузчики. Параллельно правки включали фразы вроде «Закрываем проект».

Wikimedia Foundation ввела режим только чтения, откатила изменения и очистила скрипты. Атака длилась всего 23 минуты, но задела 85 аккаунтов. Это демонстрирует, как простая архитектурная особенность - доверие к пользовательскому JS - превращается в канал для червей.

Вот ключевые шаги распространения:

• Заражение локального common.js: Скрипт переписывает персональный файл пользователя.
• Атака на глобальный MediaWiki:Common.js: Если прав хватает, меняет общий скрипт для всех.
• Автоматическое выполнение: Загружаемый код запускается в браузере редакторов, замыкая цикл.
• Массовые правки страниц: Добавляет скрытый вредоносный контент на случайные статьи.

Почему пользовательские скрипты - слабое звено

В MediaWiki пользовательские JS-файлы вроде common.js выполняются прямо в браузере. Это удобно для кастомизации интерфейса, но открывает дверь для саморазмножающихся угроз. Червь использовал эту фичу: код из trusted источников загружается без проверок и распространяется автоматически.

В других проектах похожие механизмы встречаются в CMS, вики-платформах и даже SPA-приложениях с динамическим JS. Если позволить пользователям или админам внедрять скрипты, риск растёт. Реальные примеры - атаки на Fandom или старые вики-проекты, где вредоносный код жил годами.

Главный риск - цепная реакция: один заражённый аккаунт заражает платформу целиком. Без строгого контроля это приводит к массовому вандализму, краже данных или даже RCE в браузере. Wikimedia признала, что инцидент не затронул основную Википедию, но Meta-Wiki пострадала.

Меры, которые спасли ситуацию:

• Временный локдаун редактирования - остановил распространение.
• Массовый откат правок - вернул страницы в исходное состояние.
• Очистка скриптов - удалили вред из common.js у 85 пользователей.
• Подавление в истории - скрыли вредоносные версии от публичного доступа.

Практические шаги по защите от JS-червей

Чтобы защитить свои приложения, начните с анализа прав доступа. Ограничьте, кто может редактировать глобальные скрипты. Внедрите sandboxing для пользовательского JS - выполняйте его в изолированной среде без доступа к DOM или API.

Используйте Content Security Policy (CSP) для блокировки внешних загрузчиков. Мониторьте изменения в ключевых файлах через логи и алерты. Регулярно сканируйте репозитории на спящий вредоносный код, как test.js, который лежал два года.

CSP- nonce или hash предотвратит инъекции. Для фронтенда добавьте strict-dynamic. Тестируйте на penetration testing с симуляцией червей.

• Ограничьте права: Только admins редактируют глобальные JS.
• Сканируйте код: Регулярно проверяйте на вредоносные паттерны.
• Используйте SRI: Subresource Integrity для внешних скриптов.
• Внедрите rate limiting на правки - замедлит DDoS-подобные атаки.

Уроки из атаки: что улучшить в архитектуре

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

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