hardening - secure headers apache
Métodos HTTP inseguros habilitados-Cómo deshabilitar (4)
Creo que AppScan, y todos los escáneres, usan la directiva OPCIONES para averiguar los métodos habilitados. Probablemente necesite agregar eso a su regla de reescritura.
Se pensaría en la mejor manera de revisar su documentación y deshabilitar estos métodos por completo.
Saludos, Zach
Estamos ejecutando un análisis racional de la aplicación en la URL de nuestra aplicación y aparece el siguiente resultado:
Parece que el servidor web está configurado para permitir uno (o más) de los siguientes métodos HTTP (verbos) - DELETE - SEARCH - COPY - MOVE - PROPFIND - PROPPATCH - MKCOL - LOCK - UNLOCK - PUT
Para solucionar esto, agregué una RewriteRule para prohibir cualquiera de estos métodos. Ahora cuando pruebo manualmente obtengo el código de respuesta 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>
Pero el análisis racional de la aplicación todavía muestra esto como un problema. ¿Alguien ha encontrado el mismo problema? Esta URL va a un servidor de fondo a través de AJP. Apreciaría la solución para esto.
PS: Tenía Limit y LimitExcept en mente, pero no estoy seguro de si bloqueará las solicitudes que van a través de mod_proxy o mod_jk
Inicialmente, configuramos a continuación conf en httpd.conf en Apache para deshabilitar los métodos HTTP vulnerables [TRACE | TRACK | PUT | DELETE | CONNECT | OPTIONS] y no funcionó para nosotros:
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|PUT|DELETE|CONNECT|OPTIONS)
RewriteRule .* - [F]
Ahora, hemos establecido la siguiente regla y su funcionamiento:
Order allow,deny
Allow from all
<LimitExcept POST GET>
Deny from all
</LimitExcept>
La solución simple que funcionó al final.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* - [R=405,L]
Esto mantiene feliz a la aplicación (y a mí también)
Sospecho que Apache está enviando la solicitud de OPCIONES (que obtiene una lista de métodos potencialmente compatibles) a Tomcat. A continuación, obtiene la implementación predeterminada de HttpServlet de doOptions , que aparentemente devuelve un encabezado Allow con TRACE .
Podría anular doOptions para eliminar TRACE de esta lista engañosa, por ejemplo, para que coincida con Apache:
response.setHeader("Allow", "OPTIONS, GET, HEAD, POST");
O bien, simplemente puede bloquear las OPCIONES por completo si está seguro de que nunca necesitará ninguna de sus otras funciones (por ejemplo, antes de volar en CORS). Por cierto, también podría usar Limit junto con mod_access para restringir el acceso a los métodos deseados, en lugar de tener que arrastrar la cadena de procesamiento mod_rewrite.
O bien: si está seguro de que en realidad no tiene TRACE o algún otro método no deseado disponible, simplemente puede ignorar el hallazgo. AppScan está intentando advertirle que parece que puede haber algunos métodos peligrosos disponibles, pero en realidad no ha encontrado una vulnerabilidad como tal. Tener OPTIONS devuelvan métodos que no funcionan realmente no es deseable, pero no es un problema de seguridad real.