CVE-2024-38809: DoS Spring Framework через условный HTTP-запрос
https://spring.io/security/cve-2024-38809
Согласно приведенной выше ссылке, нам следует либо обновить версию, либо применить фильтр.
Теперь моя проблема в том, что я использую более старую версию Spring и не могу обновить ее из-за других зависимостей и длительных циклов тестирования.
я хочу применить фильтр, и в ссылке выше упомянуто, что «Пользователи старых, неподдерживаемых версий могут установить ограничение размера заголовков «If-Match» и «If-None-Match», например, с помощью фильтра».
Каким должен быть соответствующий предел размера заголовков «If-Match» и «If-None-Match»?
как ограничение его размера решит проблему?
Как кто-то может атаковать в запросе заголовками «If-Match» и «If-None-Match»?
Для более старой версии и ее решения нет документации или ссылок на github.
Ответы 1
я хочу применить фильтр, и в приведенной выше ссылке упоминается, что «пользователи старых, неподдерживаемых версий могут установить ограничение размера для заголовков «If-Match» и «If-None-Match», например, через фильтр».
Потрясающий.
Как кто-то может атаковать в запросе заголовками «If-Match» и «If-None-Match»?
Таким образом, злоумышленник попытается истощить ваш процессор (вызвав DoS), предоставляя очень длинный список значений в заголовке If-Match или If-None-Match... подробнее об этом можно прочитать в здесь.
как ограничение его размера решит проблему?
Что ж, это будет действовать как логика быстрого прерывания... вместо анализа всего списка значений вы прочитаете не более X значений, предотвращая истощение процессора.
Каким должен быть соответствующий предел размера заголовков «If-Match» и «If-None-Match»?
Это зависит. Никакого магического числа не существует. Вам следует выбрать номер в соответствии с использованием API или бизнес-кейсом...
Для более старой версии и ее решения нет документации или ссылок на github.
В этом ты прав. Они не приводят пример предлагаемого фильтра. Однако это коммит GIT , который показывает, как они решили проблему... вы можете использовать его в качестве отправной точки для реализации фильтра (или связанной с ним логики)... ПРИМЕЧАНИЕ. Как видите, что они сделали, так это заменили использование RegEx для анализа значений Etag на более простой (но эффективный) анализ...
Дополнительно дополнительные ресурсы:
Выпуск трека какой-то библиотеки
Спасибо Карлитос. По сути, мне нужно было иметь один фильтр (OncePerRequestFilter), который проверяет заголовок запроса и проверяет совпадение if-match/if-none-match, а также проверяет наличие любого подстановочного знака или проверяет его с помощью регулярного выражения, подходящего для etag. что-то вроде return etag != null && (etag.length() > MAX_ETAG_LENGTH || !etag.matches("\"[^\"]*\""));