¿El bloqueo de http HEAD, TRACE, DELETE O TRACK es una característica de seguridad válida? [duplicar]

1

¿Bloquear las solicitudes de http HEAD nos ayuda a consolidar las reglas de seguridad para un servidor web Apache o esta restricción sería exagerada?

¿Qué tipo de vulnerabilidad puede ser explotada por HEAD method ?

Pruebas:

lynx --dump --head http://www.terra.com.br
  

HTTP / 1.1 200 OK Servidor: nginx Fecha: miércoles, 16 de julio de 2014 14:44:35 GMT   Tipo de contenido: texto / html; conjunto de caracteres = UTF-8 Longitud de contenido: 0 Conexión:   cerrar Varíe: Accept-Encoding X-Cache-Status: HIT Content-Language:   pt-BR X-Ua-Level: Set-Cookie: prisma = WEB-20; ruta = /;   domain = .terra.com.br Set-Cookie: prisma = WEB-20; ruta = /;   domain = .terra.com.br Edad: 0 Vary: Accept-Encoding, X-UA-Device,   X-prisma X-Device-Type: web X-Xact-Hosts: montador = 1sh X-Xact-Uuid:   be9ef8c3-163a-40af-8472-0982226424e1 Compatible con X-Ua: IE = Edge   Control de caché: no-caché X-Ua-Dispositivo: Lynx / 2.8.8rel.2 libwww-FM / 2.14   SSL-MM / 1.4.1 OpenSSL / 1.0.1g Set-Cookie:   X-XAct-ID = da20bbf3-3a14-4d86-a23b-6fe36f5adae9; Dominio = terra.com.br;   expira = miércoles, 31 de diciembre de 2036 00:00:00 GMT; Ruta = / Set-Cookie:   novo_portal = 1; Dominio = terra.com.br; expira = Mon, 01 Sep 2014 00: 00: 0 0   GMT; Ruta = /

$ lynx --dump --head http://www.myserver.com.br
  

HTTP / 1.1 403 Fecha prohibida: miércoles, 16 de julio de 2014 14:44:44 Servidor GMT:   Apache Modificado por última vez: martes, 01 de abril de 2014 05:28:27 GMT Rangos de aceptación:   bytes Content-Length: 4874 Vary: Accept-Encoding, User-Agent   Conexión: cierre Tipo de contenido: texto / html

ACTUALIZADO :

¿La respuesta del método GET también es aplicable a los métodos TRACE, DELETE OR TRACK ?

Apache conf:

RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]
RewriteRule .? - [F]
    
pregunta gpupo 16.07.2014 - 16:32
fuente

2 respuestas

3

"¿Hacer X mejora la seguridad de mi sistema?" - esta es una mala manera de abordar estos problemas.

"¿Hacer X mejora la seguridad de mi sistema lo suficiente como para justificar los costos?" - es la pregunta correcta para hacer.

¿El bloqueo de las solicitudes HEAD mejora la seguridad? Sí, en torno al .01%. Las fallas en el código que maneja las solicitudes HEAD serían más difíciles (o imposibles) de alcanzar con las solicitudes.

Pero ... los costos de bloquear las solicitudes HEAD superan los beneficios en la mayoría de los casos. El aumento del tráfico a sus servidores, el tiempo de implementación, la desaceleración de la solución de problemas, etc. Realizar un cambio como este no es un gran problema, pero si realiza 50 cambios que demoran 30 minutos y minimiza su riesgo en un .01%, entonces ha gastado 24 horas para una mejora del .5%. Probablemente hay mejores usos para tu tiempo.

    
respondido por el u2702 16.07.2014 - 18:18
fuente
-1

El uso del comando HEAD en telnet contra un servidor web le permite a un posible atacante realizar un reconocimiento contra su servidor web.

Entre otras cosas, la respuesta puede revelar qué servidor web está utilizando y qué tecnologías, como PHP o ASP, posiblemente con números de versión. El atacante podría usar esto para ir y hacer alguna enumeración, que es el proceso de hacer coincidir productos y versiones con vulnerabilidades conocidas.

Por lo tanto, no puede explotar directamente una vulnerabilidad con una solicitud HEAD, pero puede proporcionar información valiosa a un atacante.

No estoy seguro de que detener las solicitudes HEAD sea realmente posible, ya que esto es algo que un navegador necesitará hacer para recuperar contenido web. Una mejor alternativa sería modificar los archivos de configuración para asegurarse de que no informen los números de versión.

    
respondido por el TimC 16.07.2014 - 16:38
fuente

Lea otras preguntas en las etiquetas