La seguridad en los métodos HTTP

Según describe el estándar HTTP 1.1, existen 28 métodos (o verbos) para la comunicación mediante el protocolo HTTP. Aunque muchos son desconocidos para la mayoría de usuarios (y administradores de sistemas) por no ser de uso habitual, existe un riesgo potencial si el administrador del servidor web no los tiene controlados. Veamos algunas técnicas comunes.

Entre los métodos más comunes, definidos en el RFC 2616, se encuentran:

• GET: El método más común en la navegación web. Devuelve un código de respuesta y las cabeceras asociadas. Incluye el documento solicitado (habitualmente una página) en el cuerpo del mensaje.
• HEAD: Idéntico al anterior, con la salvedad de que no devuelve el documento en el cuerpo de la respuesta. Se utiliza para extraer información sobre el documento solicitado o comprobar si existe sin necesidad de enviar y recibir el documento como tal.
• POST: Pensado para publicar la información contenida en el cuerpo de la petición en el recurso donde se envía esa petición. La información que se publica y la forma de hacerlo depende completamente del servidor y el recurso. Hoy, el uso que se le da a este método es el de paso de parámetros de cliente a servidor (en muchas ocasiones para ficheros). La respuesta por parte del servidor es la misma que para una petición GET.
• TRACE: Implementa la función de eco para los mensajes HTTP. El servidor responde en el cuerpo del mensaje con la misma petición que el cliente ha realizado. Se utiliza para comprobar que las peticiones son recibidas correctamente. Su finalidad es la de depuración.
• OPTIONS: Este método presenta las opciones que el recurso o servidor dispone o requiere. De esto se puede obtener información como por ejemplo los métodos permitidos (en la cabecera ALLOW). 
• CONNECT: Utilizado para crear la comunicación con un proxy HTTP (SSL).
• PUT: Mediante este método es posible almacenar el documento que se envía como cuerpo de la petición en el propio servidor (físicamente en disco). Si el recurso al que se hace referencia en la petición no existe se creará y si existe se sobrescribirá.
• DELETE: Al igual que el método PUT, este verbo afecta directamente al recurso al que se hace la petición. Tiene la capacidad de eliminar el elemento y dejar al servidor sin ese recurso. 

El resto de verbos (menos usados) son PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK (RFC 2518), VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY (RFC 3253), ORDERPATCH (RFC 3648) y ACL (RFC 3744).

PUT y DELETE

A primera vista, dos de estos métodos pueden resultar críticos en el entorno web donde se encuentren habilitados. Tanto PUT como DELETE permiten interactuar directamente con recursos legítimos del sistema. El primero para crearlos (por ejemplo una web shell para controlar el servidor, o fichero modificado para conseguir desfigurar alguna web legítima) y el segundo para eliminar archivos o activos de, por ejemplo, una compañía. Encontrarse este tipo de configuración en servidores en producción no es demasiado común, pero aun hoy no es extraño localizarlos. Para demostrarlo, basta con hacer consultas avanzadas sobre los motores de búsqueda, o basarse en las respuestas a las peticiones OPTIONS.

Ejemplo de petición y respuesta OPTIONS usando el complemento RestClient de Firefox

Este método devuelve información del servidor, pero esta información no tiene que ser ni completa, ni veraz. En ocasiones se mostrará una cabecera ALLOW con métodos HTTP permitidos, lo que no quiere decir que estos métodos estén implementados. Es decir, a pesar de que el verbo OPTIONS indique que se admite un método concreto, al utilizar este método es muy posible que retorne un código de error, ya sea de no implementado (501), no encontrado (404), etcétera.

Ejemplo de volcado del paquete de petición y respuesta con verbo OPTIONS

Y en otras ocasiones ocurrirá lo contrario, la cabecera ALLOW de la petición OPTIONS no mostrará métodos que realmente están permitidos e implementados… aunque luego es posible su ejecución. En resumen, no se deben descartar los métodos que no estén reflejados en esa cabecera.

TRACE y ataques XST

Además de PUT y DELETE (peligrosos si no se tienen completamente controlados) no hay que olvidar el método TRACE, en principio «inofensivo».

Ejemplo de volcado del paquete de envío y respuesta con verbo TRACE

Como ya se observa en la imagen, este método devuelve como cuerpo las cabeceras de la petición del cliente, incluyendo la cabecera Cookie que (según entornos) puede resultar crítica si existe una sesión establecida con el servidor. La combinación de este verbo HTTP con un fallo «Cross Site Scripting» en la aplicación web puede acabar en un robo de sesión de usuario, incluso si las Cookies han sido establecidas como HttpOnly. Este ataque es conocido como «Cross Site Tracing» o XST.

El ataque consiste en, cuando se inyecta código JavaScript explotando la vulnerabilidad XSS, realizar una petición con el método TRACE al propio servidor y enviar el cuerpo de esta respuesta al propio atacante por la vía que sea más cómoda. El contenido devuelto incluirá la cabecera Cookie con sus valores, tenga el flag que tenga. Un ejemplo de código JavaScript que es posible inyectar se muestra en la imagen siguiente, aunque en vez de enviar la respuesta a un servidor propiedad del atacante, se muestra en un mensaje «alert» como prueba de concepto.

Ejemplo de código JavaScript para inyectar y explotar un fallo XST

Aunque lo cierto es que hoy los navegadores más modernos ya bloquean este tipo de peticiones para evitar específicamente este ataque. Pero tampoco hay que olvidar que existen otras alternativas a JavaScript para realizar peticiones TRACE como Flash, Applets Java, etcétera. Con ellos se puede llegar a conseguir el mismo resultado eludiendo los bloqueos del navegador.

Desde el punto de vista del servidor, la manera obvia de evitar estos problemas es, cómo no, reducir la superficie de ataque deshabilitando aquellos métodos que no sean útiles para el entorno concreto, y controlar exhaustivamente los que sí se estén utilizando. Faast, el servicio de pentesting persistente, monitoriza este tipo de configuraciones en los servidores web y analiza cualquier método HTTP inseguro que pueda estar habilitado o implementado.