TL; DR:
¿Existe una razón válida para exigir que un proveedor de software deje de usar los métodos HTTP PUT y DELETE en una aplicación web y use solo GET y POST ? La aplicación usa marcos para lista blanca que permiten rutas y métodos de solicitud
En otras palabras, ¿hay alguna diferencia desde el punto de vista de seguridad en permitir la eliminación de un registro a través de los métodos DELETE o POST sin cambiar el código y las comprobaciones de seguridad?
Pregunta completa
Nuestro cliente configuró su instancia de Tomcat con lo siguiente, de acuerdo con su estándar corporativo:
<security-constraint>
<web-resource-collection>
<web-resource-name>restricted methods</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>CONNECT</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
<auth-constraint />
</security-constraint>
Esto, entre la configuración Http Header Security Filter , hizo que nuestra aplicación se rompiera.
Nuestra aplicación proporciona las mismas características de seguridad del encabezado HTTP en Spring Security. Además, nuestra aplicación es REST, por lo que usamos ampliamente los métodos PUT y DELETE para cargar archivos. En futuras versiones, también planeamos usar websockets (pero desde una búsqueda, no usan CONNECT, que es para proxy).
Nuestro cliente dijo que tendrá que generar una excepción de política en producción para eliminar las líneas ofensivas de la configuración de Tomcat y hacer que la aplicación funcione.
La política de excepciones de seguridad se activa cuando las aplicaciones del proveedor no cumplen con el requisito de seguridad de manera que 1) no se puede solucionar el problema dentro de los horarios y 2) no se encuentra una vulnerabilidad evidente. Las políticas de excepción requieren la aprobación de la alta dirección.
Sin embargo, las excepciones de la política de seguridad requieren que nuestro cliente se comprometa con el proveedor dentro de los 6 meses para "solucionar el problema de seguridad". En un plazo de 6 meses, el proveedor debe proporcionar los costos y los plazos para cumplir con la política de seguridad.
Esto significa que volverán a pedirme una cotización para que la aplicación funcione con el filtrado de métodos HTTP habilitados y el filtro de seguridad de encabezado HTTP.
No quiero hacerles un favor y cambiar todas las llamadas Ajax de los patrones REST a GET / POST solo, ni siquiera por dinero si es posible. En cambio, me gustaría demostrar que su implementación de seguridad no solo es incompatible, sino también redundante, en lo que respecta a las implementaciones de seguridad dentro de la aplicación.
Si establecemos un precedente al hacerle un favor a este cliente con las solicitudes PUT y DELETE, tendremos que enfrentar solicitudes como "ser compatible con mi marco / política / entorno" desde una gran base de clientes (todos los bancos e instituciones financieras) . En el futuro, eso puede ir en contra de nuestra administración de costos.
La pregunta es, como en el TLDR, ¿el uso de los métodos PUT y DELETE solo, independientemente de las características de seguridad de la aplicación, representa un riesgo para la seguridad?
Si se demuestra que el único verbo HTTP no representa un riesgo para la seguridad, podré plantear una política de excepción permanente y confrontar al personal de TI con una sólida argumentación.
Editar
Trabajo en una fábrica de software que implementa la misma instancia de producto en un gran número de clientes y en nuestra nube. Estamos utilizando completamente todas las herramientas que tenemos a bordo, incluido el patrón REST. Estamos planeando emplear HATEOAS, WebSockets, descargas de archivos reanudables y todo lo que la tecnología web nos puede ofrecer para brindar una mejor experiencia. Sí, suena como una línea de marketing. De todos modos, la seguridad sigue siendo una preocupación en nuestros productos.