Rack - это модульный интерфейс веб-сервера Ruby. До версий 2.2.23, 3.1.21 и 3.2.6 Rack::Static#applicable_rules оценивает несколько типов h…
Rack - это модульный интерфейс веб-сервера Ruby. До версий 2.2.23, 3.1.21 и 3.2.6 Rack::Static#applicable_rules оценивает несколько типов header_rules по сравнению с необработанным URL-кодированным PATH_INFO, в то время как основной путь подачи файлов расшифровывается до того, как файл будет подан. В результате запрос на закодированный URL-адресом вариант статического пути может служить тому же файлу без заголовков, которые должны были применять header_rules. В развертываниях, которые полагаются на Rack::Static для прикрепления заголовков ответов, имеющих референты безопасности, к статному контенту, это может позволить злоумышленнику обойти эти заголовки, запросив закодированную форму пути. Эта проблема была исправлена в версиях 2.2.23, 3.1.21, и 3.2.6.
Продукт проверяет входные данные до их канонизации, что не позволяет обнаружить данные, становящиеся недопустимыми после шага канонизации.
https://cwe.mitre.org/data/definitions/180.html →Открыть в коллекции CWE →Некоторые API удаляют определённые ведущие символы из строки параметров. Злоумышленник может намеренно вставлять ведущие «фантомные» символы (дополнительные символы, не влияющие на корректность запроса на уровне API), которые позволяют входным данным пройти фильтры и тем самым обрабатываются API целевого ресурса. Это происходит, когда целевой API принимает входные данные в нескольких синтаксических формах и интерпретирует их семантически одинаково, тогда как фильтр не учитывает полный спектр синтаксических форм, допустимых для целевого API.
https://capec.mitre.org/data/definitions/3.html →Открыть в коллекции CAPEC →Злоумышленник может передавать Unicode-строку компоненту системы, не поддерживающему Unicode, и использовать её для обхода фильтра или сбоя классифицирующего механизма при правильной интерпретации запроса. Это может позволить злоумышленнику передать вредоносные данные через фильтр содержимого и/или вызвать некорректную маршрутизацию запроса приложением.
https://capec.mitre.org/data/definitions/71.html →Открыть в коллекции CAPEC →Данная атака использует обратный слеш в альтернативных кодировках. Злоумышленник может использовать обратный слеш в качестве первого символа, вынуждая парсер считать следующий символ специальным. Это называется экранированием. Используя данный приём, злоумышленник пытается эксплуатировать альтернативные способы кодирования одного и того же символа, что создаёт проблемы для фильтров и открывает пути для атак.
https://capec.mitre.org/data/definitions/78.html →Открыть в коллекции CAPEC →Данная атака направлена на кодирование символов слеша. Злоумышленник пытается эксплуатировать распространённые проблемы фильтрации, связанные с использованием символов слеша, для получения доступа к ресурсам на целевом хосте. Системы на основе каталогов, такие как файловые системы и базы данных, как правило, используют символ слеша для обозначения перехода между каталогами или другими контейнерными компонентами. По неоднозначным историческим причинам ПК (и, как следствие, ОС Microsoft) используют обратный слеш, тогда как мир UNIX традиционно применяет прямой слеш. Шизофренический результат таков, что многие MS-системы обязаны понимать обе формы слеша. Это предоставляет злоумышленнику множество возможностей для обнаружения и использования распространённых проблем фильтрации. Цель данного шаблона — обнаружить серверное программное обеспечение, применяющее фильтры только к одному варианту, но не другому.
https://capec.mitre.org/data/definitions/79.html →Открыть в коллекции CAPEC →Данная атака является специфическим вариантом использования альтернативных кодировок для обхода логики проверки. Атака использует возможность кодирования потенциально опасного ввода в UTF-8 и передачи его приложениям, не ожидающим или неспособным эффективно проверять данный стандарт кодирования, что затрудняет фильтрацию ввода. UTF-8 (8-битный формат преобразования UCS/Unicode) — это кодировка переменной длины для Unicode. Корректные символы UTF-8 имеют длину от одного до четырёх байтов. Однако в ранних версиях спецификации UTF-8 содержались ошибки (в ряде случаев допускались расширенные символы). Кодировщики UTF-8 должны использовать «как можно более короткое» кодирование, однако наивные декодеры могут принимать кодирования длиннее необходимого. В соответствии с RFC 3629, особенно тонкая форма данной атаки может быть проведена против парсера, выполняющего критически важные для безопасности проверки корректности в отношении UTF-8-кодированного вида ввода, но интерпретирующего определённые недопустимые последовательности октетов как символы.
https://capec.mitre.org/data/definitions/80.html →Открыть в коллекции CAPEC →Злоумышленник эксплуатирует возможность кодирования потенциально опасных входных данных или содержимого, используемых приложениями, таким образом, что приложения оказываются не в состоянии проверять данное кодирование надлежащим образом.
https://capec.mitre.org/data/definitions/267.html →Открыть в коллекции CAPEC →| Продукт | Вендор | Статус |
|---|---|---|
| Отслеживается | ||
| ruby-rack | Отслеживается | |
| rack | * | Отслеживается |