Небезопасные HTTP-методы включены - как отключить

Мы запускаем рациональное сканирование приложения на нашем URL-адресе приложения, и оно возвращается со следующим результатом:

Кажется, что веб-сервер настроен на разрешение одного (или нескольких) следующих HTTP-методов (глаголы) - УДАЛИТЬ - ПОИСК - КОПИРОВАТЬ - ПЕРЕЕХАТЬ - ПРОФФИНГ - PROPPATCH - MKCOL - ЗАМОК - UNLOCK - PUT

Чтобы исправить это, я добавил RewriteRule, чтобы запретить любой из этих методов. Теперь, когда я тестирую вручную, я получаю код ответа 403:

curl -X PUT https://someurl.com/somecontext/somepage.xhtml

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /somecontext/somepage.xhtml
on this server.</p>
</body></html>

Но рациональное сканирование приложений по-прежнему показывает это как проблему. Кто-нибудь сталкивался с той же проблемой. Этот URL-адрес отправляется на бэкэнд tomcat через AJP. Поблагодарите решение за это.

PS: у меня были Limit и Limit. Помните, но я не уверен, что он заблокирует запросы, которые идут через mod_proxy или mod_jk

ОТВЕТЫ

Ответ 1

Простое решение, которое работало в конце

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* - [R=405,L]

Это позволяет сканировать приложение счастливо (и меня также)

Ответ 2

Я подозреваю, что Apache отправляет запрос OPTIONS (который извлекает список потенциально поддерживаемых методов) Tomcat. Затем вы получаете стандартную реализацию HttpServlet doOptions, которая, по-видимому, возвращает заголовок Allow с TRACE в нем.

Вы можете переопределить doOptions, чтобы удалить TRACE из этого вводящего в заблуждение списка, например, чтобы соответствовать Apache:

response.setHeader("Allow", "OPTIONS, GET, HEAD, POST");

Или вы можете просто заблокировать OPTIONS целиком, если вы уверены, что вам никогда не понадобятся какие-либо другие его функции (например, CORS pre-flighting). Кстати, вы также можете использовать Limit вместе с mod_access, чтобы ограничить доступ к требуемым методам, вместо того, чтобы перетаскивать цепочку обработки mod_rewrite.

Или: если вы уверены, что на самом деле у вас нет TRACE или каких-либо других нежелательных методов, вы можете просто игнорировать это открытие. AppScan пытается предупредить вас, что похоже, что могут быть некоторые опасные методы, но на самом деле он не обнаружил уязвимость как таковую. Использование методов OPTIONS return, которые на самом деле не работают, нежелательно, но это не настоящая проблема безопасности.

Ответ 3

Сначала мы установили conf в httpd.conf в Apache, чтобы отключить уязвимые HTTP-методы [TRACE | TRACK | PUT | DELETE | CONNECT | OPTIONS], и это не сработало для нас:

    RewriteEngine on

    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|PUT|DELETE|CONNECT|OPTIONS)

    RewriteRule .* - [F]

Теперь мы установили ниже правило и его работу:

 Order allow,deny

 Allow from all

 <LimitExcept POST GET>

       Deny from all

 </LimitExcept>

Ответ 4

Я думаю, что AppScan и все сканеры, в этом случае, используют директиву OPTIONS, чтобы узнать активированные методы. Вероятно, вам нужно добавить это в правило rewrite.

Лучше всего подумать, чтобы пройти вашу документацию и полностью отключить эти методы.

Cheers, Зак