¿Por qué los métodos HTTP PUT y DELETE son inseguros, si realmente lo son? [duplicar]

PUT y DELETE no son intrínsecamente inseguros, se usan sin problemas en muchos servicios REST , por ejemplo.

En mi práctica, el principal problema relacionado con estos verbos HTTP (aparte de los problemas comunes de autenticación y autorización) era que los operadores del servidor no eran conscientes de su existencia, lo que introduce la posibilidad de que Manipulación de verbos HTTP . En resumen, esto significa que el control de acceso se implementó en base a una lista negra de verbos HTTP, pero faltan algunos verbos menos conocidos en esta lista que permiten la omisión del control de acceso.

Me gustaría señalar que muchos servidores web implementan sus propios verbos HTTP personalizados (a veces sin documentar), por lo que este tipo de "Control de acceso basado en verbos" no parece ser una buena idea de todos modos.

Los métodos HTTP tienen poco que ver con la seguridad en sí mismos. Un método como DELETE /users/1 también podría implementarse fácilmente como POST /users/1/delete o incluso GET /users/1/delete (los GET nunca deberían tener efectos secundarios, pero eso no impide que algunos desarrolladores lo hagan).

Por lo tanto, debe tratarlos de manera similar a cualquier otro método HTTP. Los GET no deberían cambiar el estado del servidor, por lo que normalmente solo necesitaría verificar que el cliente tenga acceso de lectura al recurso solicitado. Los PUT se deben usar para actualizar un recurso totalmente en el lugar (aunque a menudo también se usan de manera similar al verbo PATCH), por lo que debe asegurarse de que el cliente tenga los privilegios para hacerlo. Del mismo modo, DELETE debe enviarse para solicitar que se elimine un recurso. Por lo tanto, querrá asegurarse de que un usuario tenga permiso para hacerlo.

En resumen: trate los verbos como descriptores del tipo de acción que el usuario desea realizar. Autentíquelos y autorícelos a realizar estas acciones según lo requieran los parámetros de seguridad de su aplicación en particular.

De la guía de pruebas de OWASP:

  

Algunos de estos métodos pueden representar un riesgo de seguridad para una web   aplicación, ya que permiten a un atacante modificar los archivos almacenados en   El servidor web y, en algunos escenarios, roban las credenciales de   Usuarios legítimos. Más específicamente, los métodos que deberían ser   deshabilitados son los siguientes:

     

• PUT: este método permite que un cliente cargue nuevos archivos en el servidor web. Un atacante puede explotarlo cargando archivos maliciosos
    (por ejemplo, un archivo asp que ejecuta comandos invocando cmd.exe), o por   simplemente utilizando el servidor de la víctima como un repositorio de archivos
  

Dicho esto, en realidad hay dos cosas que debes cuidar.

• Si desea permitir que estos usuarios creen nuevo contenido, asegúrese de que solo lo permite para usuarios autenticados de confianza. Estos usuarios debe confiarse en la medida en que les permita tener una Cuenta FTP.
• Si les permites modificar el contenido existente, asegúrate de restringirlo de tal forma que solo puedan sobrescribir ciertos recursos existentes y nada más .

También asegúrate de estar usando SSL / TLS.

para los registros: RFC 2616 Protocolo de transferencia de hipertexto HTTP / 1.1 / Sección de método

una SOLICITUD es una solicitud de un cliente al servidor y no dice mucho sobre lo que el servidor hará con esa solicitud; Los posibles métodos no tienen que implementarse a nivel de servidor.

así que si vas a myserver.com y pides "ELIMINAR / blah", myserver.com simplemente dirá: "gracias, señor, y que tengas un buen día".

9.6 PUT

  

El método PUT solicita que la entidad adjunta se almacene bajo el URI de solicitud suministrado.

9.7 BORRAR

  

El método DELETE solicita que el servidor de origen elimine el recurso identificado por el URI de solicitud. Este método PUEDE ser anulado por intervención humana (u otros medios) en el servidor de origen. No se puede garantizar al cliente que la operación se ha llevado a cabo, incluso si el código de estado devuelto por el servidor de origen indica que la acción se ha completado con éxito