it-swarm-es.com

Cómo explotar los métodos HTTP

Muchos escáneres de seguridad como nikto , nessus , nmap y w3af a veces muestran que ciertos métodos HTTP como HEAD, GET , POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, etc. son vulnerables a los ataques.

¿Qué hacen estos encabezados y cómo pueden ser explotados?

Estoy buscando algo más creativo que exploits comunes como POST o GET inyecciones (por ejemplo, campos cambiados). Me ayudaría a entender si su respuesta me mostró un breve ejemplo del uso normal de el encabezado en comparación con una técnica de explotación de un encabezado.

58
Digital fire

Algunos de estos métodos son típicamente peligrosos de exponer, y algunos son simplemente extraños en un entorno de producción, lo que podría considerarse una superficie de ataque adicional. Aún así, vale la pena apagarlos también, ya que probablemente no los necesite:

  • HEAD, GET, POST, CONNECT: estos son completamente seguros, al menos en lo que respecta al método HTTP. Por supuesto, la solicitud en sí misma puede tener parámetros maliciosos, pero eso está separado del Método ... estos son típicamente (tenga en cuenta la excepción a continuación) los únicos que deben habilitarse.
  • PUT, DELETE: como mencionó @Justin, estos métodos fueron originalmente diseñados como operaciones de administración de archivos.
    Algunos servidores web todavía los admiten en su formato original. Es decir, puede cambiar o eliminar archivos del sistema de archivos del servidor, arbitrariamente. Obviamente, si estos están habilitados, te abre a algunos ataques peligrosos.
    Los permisos de acceso a los archivos deben ser ¡muy estrictamente limitados, si DEBE tener estos métodos habilitados. Pero no debería, de todos modos, hoy en día, hay scripts simples que puede usar (si este es un sitio web estático, si es una aplicación real, solo codifíquelo usted mismo) para admitir esta función si la necesita.
    NOTA: Un escenario válido para habilitar estos métodos (PUT y DELETE) es si está desarrollando una API o servicio estrictamente RESTful ; sin embargo, en este caso el método sería manejado por su código de aplicación y no por el servidor web.

  • OPCIONES: este es un método de diagnóstico, que devuelve un mensaje útil principalmente para la depuración y similares. Este mensaje básicamente informa, sorprendentemente, qué métodos HTTP están activos en el servidor web. En realidad, esto rara vez se usa hoy en día con fines legítimos, pero le otorga a un atacante potencial un ¡poco poco de ayuda: puede considerarse un atajo para encontrar otro agujero.
    Ahora, esto en sí mismo no es realmente una vulnerabilidad; pero dado que no tiene un uso real, solo afecta la superficie de ataque, e idealmente debería deshabilitarse.
    NOTA: A pesar de lo anterior, el método OPTIONS IS se usa para varios fines legítimos hoy en día, por ejemplo, algunas REST APIs requieren una solicitud OPTIONS, CORS requiere solicitudes previas al vuelo, etc. Así que definitivamente hay escenarios en los que las OPCIONES deberían estar habilitadas, pero el valor predeterminado debería estar "deshabilitado a menos que sea necesario".

  • TRACE: este es el sorprendente ... Una vez más, un método de diagnóstico (como mencionó @Jeff), que devuelve en el cuerpo de la respuesta, la solicitud HTTP completa. Esto incluye el cuerpo de la solicitud, pero también los encabezados de la solicitud, incluidos, p. cookies, encabezados de autorización y más.
    No es demasiado sorprendente, esto puede ser usado de manera sustancial, como el ataque clásico Cross-Site Tracing (XST) , en el que se puede utilizar un vector XSS para recuperar cookies HttpOnly, encabezados de autorización, y tal. Esto debería ¡definitivamente estar deshabilitado.

  • Otro conjunto de métodos merece mencionar: TODOS LOS DEMÁS . Para algunos servidores web, para habilitar/deshabilitar/restringir ciertos métodos HTTP, los establece explícitamente de una forma u otra en el archivo de configuración. Sin embargo, si no se establece ningún valor predeterminado, puede ser posible "inyectar" métodos adicionales, evitando ciertos controles de acceso que el servidor web puede haber implementado (mal). Ver por ejemplo más información sobre OWASP .

46
AviD

Usando el método PUT, puede cargar cualquier archivo en el servidor. Esto se puede utilizar para realizar Cross Site Scripting (XSS). Hoy, he realizado este ataque, respondiendo aquí con mi experiencia. Cómo se hace esto se explica a continuación.

PUT /XSS.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.myblog.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
(Input your XSS script here) 

El servidor responde con un código de estado 201 que dice "el archivo se creó con éxito".

HTTP/1.1 201 Created
Date: Mon, 05 May 2014 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

Ahora podemos intentar acceder a este archivo XSS.html cargado en el navegador. Tan pronto como acceda a esta página, aparecerá una ventana emergente XSS.

Del mismo modo, esto también se puede explotar para realizar la Inyección de comandos, aunque todavía no lo he intentado. Si la aplicación usa XML, también se puede realizar un ataque de entidad externa XML. No he hecho esto también todavía. El ataque transversal del directorio también puede ser posible.

4
Dan Rad

La advertencia principal sobre TRACE es que está diseñado para separar el enrutamiento de una solicitud HTTP de forma similar a cómo traceroute debe separar el enrutamiento de un paquete. La diferencia clave es que el comando TRACE implica operaciones en el backend y divulgación de lo que se ha recibido. Esto podría ser un problema si su front-end proporciona claves API o algo similar a su backend.

Consulte RFC 2616 para obtener más información sobre TRACE, así como explicaciones sobre otros encabezados.

3
Jeff Ferland