Pourquoi avons-nous besoin d'une sécurité au niveau de la méthode?

Dans le monde réel, pourquoi devons-nous implémenter la sécurité au niveau des méthodes?

Nous avons soit une application Web, soit une application de bureau, où l'utilisateur accède à l'interface utilisateur (et ne peut donc pas accéder directement à la méthode).

Alors, d'où vient directement l'accès aux méthodes?

edit: Je pose cette question parce que j'expérimente avec la sécurité du printemps, et je vois autoriser les utilisateurs à accéder aux méthodes.

quelque chose comme :

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

Dans une application correctement conçue, le backend et le frontend sont déconnectés. Le système de sécurité du backend ne peut pas supposer qu'un frontend spécifique gérera correctement la sécurité, il doit donc le gérer lui-même.

Je suppose que vous parlez de l'accès basé sur les rôles aux actions dans un contrôleur. C'est-à-dire que dans une architecture MVC, chaque méthode d'une Controllerclasse est une action distincte. La plupart des frameworks MVC que j'ai utilisés me permettent d'attribuer des privilèges au niveau de la méthode et au niveau de la classe. Cela signifierait que je peux appliquer un attribut / annotation au niveau de la classe et le rôle correspondant serait requis pour chaque action dans ce contrôleur.

En ce qui concerne un contrôle plus fin pour l'accès basé sur les rôles, considérez ceci:

• Il est pratique de regrouper toutes les actions autour d'une ressource. C'est-à-dire vos actions CRUD (Créer / Lire / Mettre à jour / Supprimer) pour les articles, les comptes, etc. Cela rend les API de style REST plus faciles à écrire et à gérer.
• De nombreux systèmes ont des informations d'identification / rôles différents requis pour les actions de création / mise à jour / suppression que pour les actions de lecture.
• Si toutes les actions de compte d'utilisateur sont dans un contrôleur, vous souhaitez autoriser n'importe qui à se connecter, mais seulement certaines personnes à créer de nouveaux comptes ou à attribuer des rôles.

Qu'on le veuille ou non, lorsque Ruby on Rails a frappé les ondes il y a quelques années, à peu près tous les frameworks MVC ont copié son approche de conception fondamentale. Auparavant, les actions étaient des classes distinctes, mais la logique d'action a tendance à être petite et concentrée, donc une surcharge de classe complète est exagérée. Mapper une méthode sur un contrôleur à l'action pour une page avait en fait beaucoup de sens. Sachez simplement que de nombreuses personnes ont besoin d'un contrôle précis sur les rôles pouvant exécuter quelles fonctions.

La sécurité au niveau de la méthode est utile pour deux raisons principales:

• comme une autre couche de sécurité (en plus d'autres couches)

• dans les cas où il est plus pratique ou logique d'avoir des autorisations au niveau de la méthode, considérons un cas où différents utilisateurs peuvent effectuer les mêmes actions "directes" (donc la sécurité du client n'est pas pertinente). mais dans certains cas, leur action peut déclencher un comportement que vous souhaitez limiter - dans ce cas, la sécurité au niveau de la méthode peut être une solution pertinente.

Mike Wiesner a rappelé dans cette présentation SpringSource, Introduction to Spring Security 3 / 3.1 , que l'exemple de Tomcat et de nombreux autres conteneurs de servlets comportait un bogue qui ne reconnaissait pas correctement "../", lorsqu'il était codé en unicode, d'une manière qui un simple test égal échouerait en Java, mais se traduirait dans le répertoire supérieur du système de fichiers.

La sécurité est difficile, plusieurs niveaux de sécurité amélioreront les chances de bloquer les tentatives de contournement. Étant donné que la sécurité au niveau de la méthode est directement codée dans la classe, après l'augmentation AOP, lorsque vous appelez la méthode, vous appellerez toujours le contrôle de sécurité avant.

Je suppose que vous parlez ici de méthodes publiques, privées et protégées?

Si oui, alors ils n'existent pas à des fins de sécurité. Ils existent dans le but de faciliter ou de garantir que le logiciel est correctement modularisé. (S'ils réussissent, c'est un débat que je laisserai aux autres. C'est cependant la vision de ce à quoi ils servent.)

Supposons que je livre une bibliothèque, puis je suis libre de livrer plus tard une version différente de la bibliothèque et de changer des choses marquées comme privées autant que je le souhaite. En revanche, si je n'avais pas marqué ce truc comme privé, je ne pourrais pas modifier les composants internes de mon logiciel car quelqu'un, quelque part, y accède probablement directement. Bien sûr, en théorie, c'est leur faute de ne pas utiliser l'API documentée. Mais le client percevra comme ma faute si ma mise à niveau logicielle a cassé leur logiciel. Ils ne veulent pas d'excuses, ils veulent que ce soit réglé. Mais si je ne leur laisse pas l'accès pour commencer, alors mon API est exactement les méthodes publiques que je voulais être mon API et le problème est évité.

La deuxième chose la plus probable dont vous pourriez parler est le modèle de sécurité de Java. Si vous en parlez, la raison pour laquelle cela existe est que la vision originale de Java impliquait des personnes envoyant des applets éventuellement non fiables pour travailler de manière interactive à l'intérieur de programmes tiers (par exemple, les navigateurs). Par conséquent, le modèle de sécurité était censé offrir aux utilisateurs une certaine protection contre les applets malveillantes. Par conséquent, la menace de sécurité à craindre et à protéger contre les applets non fiables essayant d'interagir avec d'autres logiciels qui pourraient être chargés.