Предупреждения Apache и флаг UnsafeAllow3F

Вопрос или проблема

Мы недавно обновили Apache, и теперь я вижу много предупреждений, таких как это, когда Apache возвращает 403 в ответ на закодированные URL:

AH: Опасный URL с %3f URL переписан без UnsafeAllow3F, реферер: http://www.google.com

А вот запись в журнале доступа:

156.59.61.233 [www.example.com] - - [22/Sep/2024:18:43:38 -0400] "GET /index.php%3Froute%3Dproduct/product/download%26product_id%3D2038496%26download_id%3D10131 HTTP/1.1" 403 4072 "http://www.google.com" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.104 Safari/537.36 Core/1.53.4882.400 QQBrowser/9.7.13059.400"

IP выглядит как сингапурский, и хотя URL на самом деле действителен при декодировании, я ломаю голову над тем, почему он был направлен с Google.

Есть ли хоть какая-нибудь вероятность, что это легитимный трафик, который действительно исходит от Google? Или они просто подделывают реферер?

Я пытаюсь принять решение о том, следует ли включать флаг UnsafeAllow3F в нашей конфигурации хоста, так как это новинка для меня. Я не вижу особого вреда в конечной точке, к которой они пытаются обратиться, но мне нужна перспектива о том, почему и как происходит такой трафик.

Ответ или решение

Ваша проблема связана с тем, что обновление Apache привело к появлению предупреждений о "некорректных URL", где Apache отклоняет запросы с закодированными символами, такими как %3f, что соответствует символу ?. Давайте разберёмся подробнее с этим вопросом и как решить вашу проблему.

Понимание предупреждений Apache и флага UnsafeAllow3F

Предупреждение AH: Unsafe URL with %3f URL rewritten without UnsafeAllow3F указывает на то, что Apache обнаружил потенциально небезопасный URL. Символ ? используется в URL для разделения адреса на основную часть и строку запроса, и его закодировка в %3f в данном случае может трактоваться как попытка манипуляции с запросом. Таким образом, Apache блокирует такие запросы по умолчанию, чтобы предотвратить возможные уязвимости.

Флаг UnsafeAllow3F можно включить в конфигурации Apache для разрешения обработки таких URL, однако следует сделать это с осторожностью. Это может открыть ваш сервер для определённых видов атак, и поэтому его применение требует тщательного анализа.

Легитимность трафика

Что касается вашего вопроса о легитимности трафика, который, как вы считаете, может происходить из Google:

  1. Спуффинг реферера: Возможно, что запросы осуществляются с подделанным реферером. Некоторые боты или вредоносные программы могут имитировать запросы, исходящие от популярных сайтов, таких как Google, чтобы скрыть свою истинную природу.

  2. Проблемы с поисковым индексированием: В редких случаях поисковые роботы могут ошибочно индексировать закодированные URL, что приводит к таким запросам.

  3. Легитимный трафик: Вероятность того, что такая URL-адресация напрямую связана с реальными пользователями, мала. Но не исключено, что некоторые легитимные сервисы или приложения могут использовать подобные закодированные ссылки.

Рекомендации

  1. Анализ логов: Проверьте другие записи логов, чтобы определить, присутствует ли подобный трафик из других источников или это единичный случай. Также поищите паттерны поведения IP-адресов.

  2. Не включайте UnsafeAllow3F до окончательной проверки: Включение UnsafeAllow3F может быть обосновано, только если вы уверены, что ваш веб-приложение обработает такие URL безопасно. Лучше сначала диагностировать и убедиться в корректности запросов.

  3. Рассмотрите использование WAF (Web Application Firewall): Это может помочь фильтровать ненадежные запросы, прежде чем они достигнут вашего приложения.

  4. Имейте в виду безопасность: Обязательно проведите аудит вашего кода и архитектуры на предмет других возможных уязвимостей, которые могут быть связаны с неправильной обработкой входящих запросов.

Заключение

Рекомендуется провести тщательный анализ и использовать более безопасные методы для обработки запросов, чем просто включение флага UnsafeAllow3F. Если у вас есть сомнения в легитимности трафика, лучше рассмотреть варианты борьбы с потенциальными атаками, прежде чем вносить изменения в конфигурацию вашего сервера.

Оцените материал
Добавить комментарий

Капча загружается...