Рекомендуем
VPS на Windows и Linux — от 49 ₽ за 7 дней Быстрый запуск сервера на NVMe для сайтов, ботов и других задач.
Выбрать VPS

Ruby on Rails 8.1.4.1 устраняет 21 уязвимость — риск доступа к файлам и обхода защиты приложений

4 ноября 2026 года разработчики Ruby on Rails выпустили обновление безопасности 8.1.4.1, закрывающее уязвимости в загрузке файлов, обработке запросов и пользовательских сессиях. Самая опасная из них получила оценку 9,8 из 10 по шкале CVSS: при определённой конфигурации Active Storage злоумышленник мог читать и записывать файлы на сервере. Изменения затрагивают сайты с пользовательскими загрузками, обратными прокси и хранением сессий в кэше.

Ruby on Rails 8.1.4.1 устраняет 21 уязвимость
Ruby on Rails 8.1.4.1 устраняет 21 уязвимость

Active Storage мог открывать доступ к файлам сервера при загрузке изображений

Одна из самых серьёзных проблем Rails 8.1.4.1 связана с Active Storage — встроенным компонентом для загрузки и обработки файлов. При работе с ImageMagick специально подготовленный файл мог заставить обработчик обращаться к другим файлам на сервере. В официальном бюллетене GHSA-f3w6-w445-fwh9 этой уязвимости присвоен критический уровень опасности и оценка CVSS 9,8.

Проблема затрагивала приложения, которые принимают файлы от недоверенных пользователей и используют ImageMagick через config.active_storage.variant_processor = :mini_magick без достаточных ограничений на доступные обработчики форматов. Подобная настройка, в частности, была стандартной для приложений со старыми настройками Rails (load_defaults 6.1 и ранее). Прикрепления файла могло быть достаточно для запуска опасной обработки: отдельный запрос на создание миниатюры не требовался.

Что мог получить атакующий? Помимо записи произвольных файлов, при использовании дискового хранилища Active Storage возникал риск чтения доступных процессу приложения данных. Среди них — ключ secret_key_base, настройки базы данных и токены внешних сервисов. Утечка таких секретов в определённых условиях способна привести к дальнейшему захвату приложения или связанных систем.

В Rails 8.1.4.1 добавлена политика безопасности ImageMagick, запрещающая ряд опасных обработчиков и механизмов, включая MSL и выполнение через Ghostscript. Политика применяется к вызовам ImageMagick через MiniMagick и дополняет ограничения, уже установленные на сервере. Для приложений с :mini_magick требуется версия гема mini_magick не ниже 5.1: со старой версией приложение может не запуститься после обновления.

Отдельное исправление GHSA-v924-7rp8-4mxh касается имён загружаемых видео, аудио и изображений. Раньше Active Storage передавал внешним программам временный файл с расширением, выбранным загрузившим его человеком. Это позволяло задействовать неподходящий декодер, а в некоторых сборках FFmpeg с поддержкой AviSynth — обработку файла как сценария. Теперь Rails сохраняет расширение для обработки только тогда, когда оно соответствует зарегистрированному типу содержимого; иначе использует временный файл без расширения. Риск здесь зависит от установленных медиабиблиотек и того, принимает ли сайт пользовательские файлы.

Подмена IP-адреса и обход Strong Parameters затрагивали контроль доступа

В ветке Rails 8.1 обнаружили способ подменить IP-адрес клиента при определённой конфигурации обратного прокси. Компонент ActionDispatch::RemoteIp мог довериться HTTP-заголовку Forwarded, переданному самим посетителем, даже если прокси записал настоящий адрес в X-Forwarded-For.

Для сайта, который ограничивает число запросов по IP-адресу, это серьёзный сценарий: злоумышленник потенциально мог обходить лимиты или искажать адреса в журналах. Исправление в 8.1.4.1 сопоставляет значения двух заголовков и при конфликте вызывает IpSpoofAttackError, если включена стандартная проверка подмены адресов. При этом защита зависит и от прокси: если он пропускает пользовательский Forwarded и вообще не задаёт X-Forwarded-For, уязвимая схема может сохраняться.

Другая проблема находилась в Strong Parameters — механизме Rails, который не позволяет автоматически записывать в модель поля, не разрешённые разработчиком. Метод Parameters#each_key, вызванный с блоком, мог возвращать обычный хеш вместо объекта параметров. Если приложение затем передавало результат в массовое присваивание атрибутов, проверка разрешённых полей обходилась. Например, ошибка в коде могла позволить изменить служебный признак доступа. Исправление возвращает объект Parameters с сохранением предусмотренных проверок. Уязвимость проявлялась именно в приложениях, использовавших такую последовательность вызовов; сам Rails её не выполнял.

Исправления сессий и HTML-ответов защищают вход в аккаунт и содержимое страниц

В приложениях с config.session_store :cache_store обнаружили гонку запросов. Один запрос мог завершить сеанс при выходе пользователя, а другой, начавшийся раньше и закончившийся позже, записывал старую сессию обратно в кэш. В результате выход из аккаунта или отзыв сессии на сервере иногда не прекращал её действие. Rails 8.1.4.1 проверяет, существует ли запись сессии перед повторным сохранением, и пропускает запись, если сеанс уже удалён.

Ещё одна проблема возникала при раздаче файлов через прокси-режим Active Storage. Во время смены ключей или формата cookie приложение могло отправить обновлённую сессионную cookie в ответе, допускающем публичное кэширование. Если общий кэш сохранял такой ответ вместе с заголовком Set-Cookie, последующие посетители потенциально могли получить чужую сессию. Патч меняет поведение при обновлении cookie для ответов, в которых сессия должна быть пропущена.

Разработчики также закрыли несколько вариантов XSS в помощниках Action View и отдельную проблему сериализации MessagePack в Active Support для Rails 8.1. XSS — ситуация, когда специально подготовленный ввод может привести к выполнению нежелательного JavaScript в браузере посетителя. Среди остальных исправлений — защита от отказа в обслуживании при обработке некоторых запросов и защита от ошибочного кэширования HTML и JSON в ответах, формат которых зависит от HTTP-заголовков. Последний дефект мог приводить к тому, что общий кэш отдавал клиенту неподходящее представление страницы.

Загрузка в Google Cloud Storage получила проверку размера файла

Для сайтов, использующих прямые загрузки Active Storage в Google Cloud Storage, патч меняет проверку объёма передаваемых данных. Ранее ссылка для загрузки не связывала фактический размер файла с заявленным значением byte_size. Поэтому пользователь мог передать файл крупнее указанного, обойдя ограничения приложения на размер загрузок или квоты.

В исправленных версиях Rails подписывает заголовок x-goog-content-length-range, ограничивающий размер фактической передачи. Здесь есть практическая деталь для совместимости: при загрузке из браузера настройка CORS бакета должна допускать этот заголовок в responseHeader. Без этого после обновления браузерные загрузки могут перестать проходить. Другое исправление Active Storage касается подписи Content-Type при использовании cache_control.

Обновление с Rails 8.1.4 до 8.1.4.1 выполняется в рамках той же ветки фреймворка. В официальном руководстве Rails для перехода между версиями указан способ через изменение ограничения версии в Gemfile, команду bundle update rails и запуск тестов. Для этого выпуска наиболее чувствительные к изменениям места — обработка изображений через MiniMagick, заголовки Forwarded и X-Forwarded-For, браузерные загрузки в GCS и поведение сессий в CacheStore. Rails 8.1 требует Ruby версии 3.2.0 или новее.

Rails 8.0.5.2 вышел одновременно с 8.1.4.1

Параллельно с Rails 8.1.4.1 команда выпустила патч 8.0.5.2 для предыдущей поддерживаемой ветки. Большинство объявленных исправлений относится к обеим версиям, но проблемы с обработкой Forwarded в RemoteIp и сериализатором MessagePack разработчики отдельно обозначили как специфичные для Rails 8.1.

Дата релиза обоих патчей — 4 ноября 2026 года. Согласно официальной политике сопровождения, поддержка безопасности Rails 8.0 заканчивается 7 ноября 2026 года, тогда как ветка 8.1 продолжит получать такие исправления до октября 2027 года. Таким образом, версии 8.1.4.1 и 8.0.5.2 закрывают конкретные ошибки в действующих ветках, но срок дальнейшего получения исправлений у них различается.

Источники

При использовании материалов сайта необходимо указывать ссылку на TGLand.ru. Если вы копируете фрагменты текста в интернете, прямая гиперссылка, доступная для индексации поисковыми системами, должна быть размещена в начале материала.

Вам также может понравиться