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

En el mundo real, ¿por qué necesitamos implementar seguridad a nivel de método?

Tenemos una aplicación web o una aplicación de escritorio, donde el usuario accede a la interfaz de usuario (y, por lo tanto, directamente no puede acceder al método).

Entonces, ¿dónde aparecen los métodos de acceso directamente aquí?

editar: hago esta pregunta porque estoy experimentando con la seguridad de primavera y veo que autorizo ​​a los usuarios a acceder a métodos.

algo como :

 @ROLE_ADMIN
public void update() {
      //update
}

En una aplicación diseñada correctamente, el backend y la interfaz están desconectados. El sistema de seguridad del backend no puede asumir que una interfaz específica manejará la seguridad correctamente, por lo que debe manejarla por sí mismo.

Supongo que está hablando sobre el acceso basado en roles a las acciones en un controlador. Es decir, en una arquitectura MVC, cada método en una Controllerclase es una acción separada. La mayoría de los frameworks 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 a nivel de clase y se requeriría el rol correspondiente para cada acción en ese controlador.

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

• Es conveniente agrupar todas las acciones alrededor de 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 credenciales / roles diferentes necesarios para las acciones Crear / Actualizar / Eliminar que tienen para las acciones Leer.
• Si todas las acciones de la cuenta de usuario están en un controlador, desea permitir que cualquiera inicie sesión, pero solo ciertas personas creen cuentas nuevas o asignen roles.

Nos guste o no, cuando Ruby on Rails llegó a las ondas hace unos años, casi todos los marcos 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 centrada, por lo que una sobrecarga de clase completa es exagerada. Asignar un método en un controlador a la acción de una página realmente tenía mucho sentido. Solo sepa que muchas personas necesitan un control detallado 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 en que sea más conveniente o lógico tener permisos en el nivel de método, considere un caso en el que diferentes usuarios puedan 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 , que trajo el ejemplo de que Tomcat y muchos otros contenedores de Servlets tenían un error que no reconocía correctamente "../", cuando estaba codificado en unicode, de una manera que una prueba de igual 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 se codifica 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ás hablando de métodos públicos, privados y protegidos aquí?

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

Supongamos que entrego una biblioteca, luego soy libre de entregar más tarde una versión diferente de la biblioteca y cambiar cosas marcadas como privadas tanto como quiera. 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 esté accediendo a él directamente. Claro, en teoría es su culpa por no usar la API documentada. Pero el cliente lo percibirá como mi culpa que mi actualización de software haya roto su software. No quieren excusas, quieren que lo arreglen. Pero si no dejo que tengan acceso para comenzar, entonces mi API es exactamente los métodos públicos que pretendía ser mi API y se evita el problema.

La segunda cosa más probable de la que podría estar hablando es el modelo de seguridad de Java. Si está hablando de eso, la razón por la que existe es que la visión original para Java involucraba a personas que enviaban applets posiblemente no confiables para trabajar 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 applets maliciosos. Por lo tanto, la amenaza de seguridad de la que preocuparse y protegerse es que los applets no confiables intenten interactuar con otro software que pueda estar cargado.