¿Por qué necesitamos seguridad a nivel de método?

En una aplicación adecuadamente diseñada, el backend y el frontend están desconectados. El sistema de seguridad backend no puede asumir que ningún frontend específico manejará la seguridad correctamente, por lo que tiene que manejarlo por sí mismo.

Supongo que está hablando de acceso basado en roles a acciones en un controlador. Es decir. en una arquitectura MVC, cada método en una clase Controller es una acción separada. La mayoría de los marcos MVC que he usado me permiten asignar privilegios tanto a nivel de método como a nivel de clase. Eso significaría que puedo aplicar un atributo / anotación en el nivel de clase y el rol correspondiente sería necesario para cada acción en ese controlador.

Respecto a un control más detallado para el acceso basado en roles, considere esto:

• Es conveniente agrupar todas las acciones en torno a un recurso. Es decir. sus acciones Crear / Leer / Actualizar / Eliminar (CRUD) para artículos, cuentas, etc. Esto hace que las API de estilo REST sean más fáciles de escribir y mantener.
• Muchos sistemas tienen diferentes credenciales / roles requeridos para las acciones Crear / Actualizar / Eliminar que para las acciones de Lectura.
• Si todas las acciones de la cuenta de usuario están en un controlador, desea permitir que cualquier persona inicie sesión, pero solo ciertas personas pueden crear nuevas cuentas o asignar roles.

Te guste o no, cuando Ruby on Rails llegó al aire hace unos años, casi todos los marcos de MVC copiaron su enfoque de diseño fundamental. Solía ser que las acciones eran clases separadas, pero la lógica de acción tiende a ser pequeña y enfocada, por lo que una sobrecarga de clase completa es una exageración. La asignación de un método en un controlador a la acción de una página realmente tenía mucho sentido. Solo tenga en cuenta que muchas personas necesitan un control preciso sobre qué roles pueden realizar qué funciones.

La seguridad a nivel de método es útil por dos razones principales:

• como otra capa de seguridad (además de otras capas)

• en los casos donde es más conveniente o lógico tener permisos en el nivel de método considere un caso en el que diferentes usuarios pueden realizar las mismas acciones "directas" (por lo que la seguridad del cliente no es relevante). pero en algunos casos, su acción puede desencadenar un comportamiento que desea limitar; en este caso, la seguridad a nivel de método puede ser una solución relevante.

Mike Wiesner recordó en esta presentación de SpringSource, Introducción a Spring Security 3 / 3.1 , dio el ejemplo que Tomcat y muchos otros contenedores de Servlets tenían un error que fallaba en reconocer correctamente "../", cuando se codificaba en Unicode, de manera que una prueba de igual a simple fallaría en Java, pero se traduciría al directorio superior en el sistema de archivos .

La seguridad es difícil, múltiples niveles de seguridad, mejorarán las posibilidades de bloquear los intentos de elusión. Dado que la seguridad a nivel de método está codificada directamente dentro de la clase, después del aumento de AOP, cuando llame al método, siempre llamará al control de seguridad antes.

Supongo que está hablando de métodos públicos, privados y protegidos aquí.

Si es así, entonces no existen por razones de seguridad. Existen con el propósito de facilitar o garantizar que el software esté correctamente modularizado. (Si tienen éxito en eso, es un debate que dejaré para otros. Sin embargo, esa es la visión de para qué sirven).

Supongamos que entrego una biblioteca, luego tengo la libertad de entregar una versión diferente de la biblioteca y cambiar las cosas marcadas como privadas tanto como deseo. Por el contrario, si no hubiera marcado esas cosas como privadas, entonces no podría cambiar ninguna parte interna de mi software porque alguien, en algún lugar, probablemente acceda a él directamente. Claro, en teoría es su culpa por no usar la API documentada. Pero el cliente lo percibirá como culpa mía de que mi actualización de software rompió su software. No quieren excusas, quieren que las arreglen. Pero, para empezar, si no les dejo acceso, mi API es exactamente el método público que pretendía ser mi API y se evita el problema.

La segunda cosa más probable de la que podrías estar hablando es el modelo de seguridad de Java. Si está hablando de eso, entonces la razón por la que existe es que la visión original de Java involucró a personas que envían posiblemente applets que no son de confianza para que trabajen interactivamente dentro de programas de terceros (por ejemplo, navegadores). Por lo tanto, el modelo de seguridad estaba destinado a brindar a los usuarios cierta protección contra los applets maliciosos. Por lo tanto, la amenaza de seguridad de la que preocuparse y de la que debe protegerse son los applets no confiables que intentan interactuar con otro software que podría estar cargado.