Исправление / скрытие уязвимостей на основе пути в WordPress

Question

У меня есть сайт WordPress, которым я управляю. Недавно я получил сканирование безопасности уязвимостей Qualys (сканирование без аутентификации), в котором было обнаружено большое количество «уязвимостей на основе пути». Почти все перечисленные пути следуют этому формату:

https://www.example.com/search/SomeString

https://www.example.com/search/1/feed/rss2

Вот некоторые примеры:

https://www.example.com/search/errors

https://www.example.com/search/adminhttps://www.example.com/search/bin

Когда я перехожу к этим URL-адресам, я получаю соответствующий ответ на странице поиска, например, «Поиск для администратора не дал результатов».

Но если я перейду на https://www.example.com/search/ без строкового параметра, я получу ошибку 404 (настраиваемая страница ошибок), в которой говорится, что страница не может быть найдена. Все это работает так, как я и ожидал. Никакие конфиденциальные данные / страницы не отображаются.

Пример вывода Qualys:

150004 URL-адрес уязвимости на основе пути:https://www.example.com/search/1/feed/rss2/ Вывод № 8346060(130736429) Подтвержденная серьезность уязвимости - Уровень 2 Уникальный номер отредактирован Дата обнаружения раскрытия пути к группе 22 марта 2021 г. 18:16GMT-0400 CWE CWE-22 OWASP A5 Нарушение управления доступом WASC WASC-15 НЕПРАВИЛЬНАЯ КОНФИГУРАЦИЯ ПРИЛОЖЕНИЯ WASC-16 ИНДЕКСИРОВАНИЕ КАТАЛОГА WASC-17 НЕПРАВИЛЬНЫЕ РАЗРЕШЕНИЯ ФАЙЛОВОЙ СИСТЕМЫ База CVSS V3 5.3 CVSS V3 Temporal5CVSS V3 Вектор атаки

Подробности Угроза На веб-сервере обнаружен потенциально конфиденциальный файл, каталог или список каталогов.

Воздействие . Содержимое этого файла или каталога может раскрывать конфиденциальную информацию.

Решение Убедитесь, что доступ к этому файлу или каталогу разрешен. При необходимости удалите его или примените к нему контроль доступа.

Параметр информации для обнаружения Никаких параметров для обнаружения информации не требуется. Аутентификация. Чтобы обнаружить эту уязвимость, аутентификация не требуется. Путь доступа Вот путь, по которому сканер достигает уязвимого URL: https://www.example.comhttps://www.example.com/?s=1

Полезные нагрузки

       #1
#1 Request
GET https://www.example.com/search/tools/
Referer: https://www.example.com
Cookie: [removed in case its sensitive];
caosLocalGa= [removed in case its sensitive];
Host: https://www.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1

Safari / 605.1.15 Принять: /

Судя по выводам, это ложное срабатывание. Но мой ИТ-директор настаивает на том, чтобы я доказал это как таковое. Во-первых, есть ли какие-либо документы по этому поводу, которые могут быть полезны? Во-вторых, знает ли кто-нибудь об обновлениях WP, которые могли бы скрыть / удалить эти результаты?

Answer 1

(Я бы прокомментировал, но моя репутация недостаточно высока).

Я могу частично ответить на этот вопрос, поскольку сейчас веду ту же битву с другим веб-приложением. Если вы запустите запрос в браузере с включенными инструментами разработчика, готов поспорить, вы увидите, что код ответа от сервера - 200, даже если он на самом деле выполняет перенаправление.

Сканер видит, что код ответа в порядке, и, исходя из этого, запрос был успешным, как и тогда, когда на самом деле этого не произошло. При «тихом» перенаправлении необходимо указать другой код ответа.