¿Por qué no debería permitirse el método OPTIONS en un servidor HTTP?

Una parte esencial de la seguridad es reducir la superficie de ataque eliminando cualquier funcionalidad que no sea necesaria. Por lo general, esta es también una funcionalidad que está menos probada y, por lo tanto, podría ser un vector para ataques inesperados. Por ejemplo, puede haber restricciones / autorizaciones en la aplicación web que son específicas para GET, POST y que ignoran cualquier otro método. Por otro lado, parte del código de las aplicaciones puede ignorar el método de solicitud y, por lo tanto, el acceso a los recursos protegidos puede ser posible utilizando métodos de solicitud desprotegidos. Por lo tanto, eliminar OPTIONS, HEAD, TRACE, etc. tiene sentido en caso de que no se utilicen.

Pero, las OPCIONES pueden ser necesarias en relación con CORS para permitir solicitudes de origen cruzado. En este caso, eliminarlo afectaría la funcionalidad y, por lo tanto, no debería eliminarse.

En general, es una mala idea simplemente poner en la lista negra los métodos de solicitud que pueden ser un problema. En su lugar, se debe hacer una lista blanca, es decir, solo se permiten los métodos de solicitud que se sabe que son manejados adecuadamente por la aplicación.

Otros han señalado que desea limitar su superficie de ataque y ser consciente de que algunos sitios Ajax utilizan legítimamente OPCIONES. De todos modos, quería compartir una experiencia reciente contigo.

Habíamos probado un sitio y descubrimos que era vulnerable a la carga de archivos ejecutables. En términos generales, puede cargar un archivo JSP como imagen de perfil, luego ejecutar el archivo JSP y tomar el control del servidor.

El primer intento del cliente en una solución bloqueó la obtención de JSP con una solicitud GET. Sin embargo, descubrimos que todavía era posible ejecutar el JSP utilizando una solicitud de OPCIONES. No obtiene la salida de JSP, pero es fácil codificar la JSP para conectarse nuevamente con un mecanismo fuera de banda.

En este caso, permitir OPCIONES permitió un compromiso del servidor remoto.

R comentó que no es OPCIONES culpable. Eso es verdad, es una mala codificación culpable. Sin embargo, si las OPCIONES se hubieran desactivado de forma general como medida de defensa en profundidad, entonces este sitio no habría sido explotable.