Cómo explotar los métodos HTTP

Algunos de estos métodos son generalmente peligrosos de exponer, y algunos son 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 necesites:

• HEAD, GET, POST, CONNECT: son completamente seguros, al menos en lo que respecta al propio método HTTP. Por supuesto, la solicitud en sí puede tener parámetros maliciosos, pero eso está separado del Método ... estos son típicamente (a excepción de la excepción a continuación) los únicos que deberían estar habilitados.

• PUT, DELETE - como mencionó @Justin, estos métodos originalmente fueron 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, de manera arbitraria. 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 usted DEBE tener estos métodos habilitados. Pero no debería, de todos modos, hoy en día, hay scripts simples que puede usar (si se trata de un sitio web estático, si es una aplicación real, simplemente 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 un API o servicio estrictamente RESTful ; sin embargo, en este caso, el método se manejaría con el código de su aplicación, y no con 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 un poco de ayuda a un posible atacante: puede ser considerado un atajo para encontrar otro hoyo.
  Ahora, esto por sí mismo no es realmente una vulnerabilidad; pero como no tiene un uso real, solo afecta a la superficie de ataque, e idealmente debería estar desactivado.
  NOTA: A pesar de lo anterior, el método OPTIONS se usa para varios propósitos legítimos en la actualidad, por ejemplo, algunas API REST 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 aún debería estar "deshabilitado a menos que sea necesario".

• TRACE: este es el sorprendente ... De nuevo, un método de diagnóstico (como lo 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, por ejemplo, Cookies, encabezados de autorización, y más.
  No es demasiado sorprendente, esto se puede usar de manera sustancial, como el ataque clásico Cross-Site Tracing (XST) , donde se puede utilizar un vector XSS para recuperar cookies HttpOnly, encabezados de autorización y demás. Esto debería definitivamente estar deshabilitado.

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

Usando el método PUT, puede cargar cualquier archivo en el servidor. Esto se puede utilizar para realizar secuencias de comandos de sitios cruzados (XSS). Hoy, he realizado este ataque, así que respondo aquí con mi experiencia. A continuación se explica cómo hacer esto.

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ó correctamente".

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, obtendrá una ventana emergente XSS.

Del mismo modo, esto también puede ser explotado para ejecutar la inyección de comandos, aunque todavía no lo he intentado. Si la aplicación utiliza XML, también se puede realizar un ataque de entidad externa XML. He hecho esto también todavía. También puede ser posible un ataque transversal al directorio.

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

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