L'utilisateur ne peut pas naviguer vers la page Web via l'interface utilisateur en raison des autorisations, mais il peut accéder à la page en collant l'URL. Comment puis-je me protéger contre cela?
Dans mon application, les utilisateurs ont certains rôles qui ont des autorisations. Ces autorisations déterminent quels éléments d'interface utilisateur sont disponibles pour eux sur l'écran d'accueil. De nombreux éléments sont liés à d'autres pages, que de nombreux utilisateurs ne peuvent pas voir car leurs autorisations ne leur permettent pas d'accéder à cette page Web.
Par exemple, un bouton appelé button1 des liens vers une page aléatoire de l'application, disons http://www.example.com/example.jsp. L'utilisateur John a cependant des permissions qui ne lui permettent pas de voir button1. Par conséquent, John ne peut pas aller à http://www.example.com/example.jsp.
Le problème que j'ai, c'est que si je suis connecté en tant que John et que je colle cette URL, cela m'amènera à la page.
C'est évidemment un énorme risque pour la sécurité si un attaquant obtient l'URL d'une page administrateur par exemple. Alors, comment puis-je me protéger contre cela? Dois-je vérifier l'utilisateur pour chaque page, vérifier les autorisations et m'assurer qu'il est autorisé à y être?
Il y a des centaines de pages dans cette application et cela semble très redondant et pas efficace d'inclure du code sur chaque page pour le faire. Existe-t-il un moyen plus simple de le faire que la méthode que je viens de mentionner?
Dois-je vérifier l'utilisateur pour chaque page?
Absolument. Non seulement chaque page, mais chaque demande adressée à une ressource privilégiée, par exemple POST demande de mise à jour des données, suppression, affichage, etc., etc. Il ne s'agit pas seulement de visualiser les pages, il s'agit de contrôler qui peut faire quoi sur votre système.
Il semble que tout votre système d'authentification et d'autorisations soit rompu dans son implémentation actuelle. Les étapes pour y remédier sont trop larges pour cette seule réponse. Il vaudrait la peine de faire une recherche générale sur ce forum et le réseau plus large pour trouver des solutions adaptées à votre framework (JSP, ASP.Net, PHP, etc.). La plupart des frameworks ont des fonctionnalités prêtes à l'emploi pour résoudre ce problème.
Un bon début serait ce guide de haut niveau de l'OWASP: Operational Security: Administrative Interfaces .
La réponse rapide est oui, comme vous l'avez compris. Mais ce n'est pas nécessairement l'énorme travail auquel vous pensez. (L'ensemble de la sécurité peut être important, mais ce n'est qu'une partie de celui-ci). Vous avez des problèmes bien plus graves que cela.
Pourquoi est-ce important
TOUT ce que vous créez sera frappé par des tentatives de le casser. Quelqu'un sera curieux. Quelqu'un fera quelque chose que vous n'attendiez pas et qui défie votre pensée. Quelqu'un sera curieux, malveillant ou fouineur.
Vous devez également tenir pour acquis que votre logiciel/application web sera testé durement par des outils automatisés. Les serveurs avec un portail en ligne (de presque n'importe quel type) sont découverts par les pirates dans les dizaines de minutes suivant leur première connexion, et commencent à être sondés pour l'un des milliers d'éventuelles défaillances ou oublis de sécurité. Cela signifie qu'ils sonderont ce qui se passe exactement "en arrière-plan", ainsi que tout manquement détectable qui peut être exploité (dans la validation des données, la validation de cross-scripting, l'injection SQL ou binaire, le piratage JavaScript, le back-end lui-même, ce qui des faiblesses peuvent survenir en forçant quelque chose à l'échec, quelles données peuvent être exposées ...).
Votre ou vos serveurs Web seront sondés de cette façon, en permanence, pour tout code Web possible et les défaillances principales, par des centaines sinon des milliers d'outils automatisés. C'est aussi bien que les humains et les utilisateurs, pas à la place de.
Préféreriez-vous que ce soit loin dans la route et porté à votre attention avec force par les critiques, les médias et les utilisateurs irrités, ou qu'il ait entraîné une responsabilité? Ou préférez-vous le réparer?
Comment le résoudre
Ce n'est pas un travail énorme dans un sens. Vous créez un cadre de sécurité, puis chaque page l'importe ou l'utilise. Les concepts pour le faire ne sont pas difficiles et sont bien documentés. Le nombre de pages n'est donc pas très important.
La partie difficile du travail est que la sécurité est difficile . Votre vrai problème est que, du fait que ces problèmes existent et que vous posez ces questions, vous n'en savez pas assez pour espérer le faire sans aide. Sérieusement. Vous. Faire. Ne pas.
Je ne sais pas quelle est la taille de votre équipe ou vos ressources. Vous en avez besoin - et vous n'avez probablement aucun espoir de le faire sans aide extérieure.
Ma vraie préoccupation ici
Cela dit, ma véritable préoccupation n'est pas l'application Web. C'est l'état d'esprit que cette question suggère.
Imaginez que j'envisage d'acheter ou d'utiliser votre application.
Cela n'aide pas, ou ne rassure pas le lecteur, que vous considérez apparemment la sécurité comme une réflexion après coup, une perturbation de votre travail ou un inconvénient à réparer par la suite (ou si vous ne comprenez pas suffisamment que jusqu'à présent vous l'avez traitée de cette façon) , et peut-être que les problèmes sont des choses qui sont vraiment des bases, comme le codage correct d'une URL de bouton.
La sécurité est votre travail, car quelle que soit la technicité du produit/service et quels que soient ses utilisateurs, votre réel le produit est la confiance et l'assurance que vous répondrez à mes besoins et ne me causerez pas une catastrophe majeure.
Je suis censé faire confiance à votre application avec mes données? Pour l'instant, et je suis désolé de le dire, je pense que je pourrais aussi bien le publier moi-même sur Google+. Oui c'est est "si mauvais" une situation et une impression, et non ce n'est pas exagéré pour l'effet.
Je suis désolé.
Maintenant, si votre application est bonne, impliquez quelqu'un d'autre.
Vous devez cocher le niveau autorisation utilisateur pour chaque demande (GET, POST, PUT, DELETE). La navigation vers une page, comme dans votre cas, est une requête GET. Un utilisateur ne devrait pas non plus pouvoir envoyer une demande sans autorisation.
Maintenant, si vous devez ajouter le code sur chaque page de votre application dépend de votre infrastructure d'application. Par exemple, certains frameworks (Laravel, Express.JS) vous permettent de regrouper des routes et d'appliquer un filtre à chaque demande pour cette route, et c'est là que vous mettez les vérifications. Pour les applications en PHP simple, vous auriez besoin d'avoir le code sur chaque page, vous pouvez utiliser l'instruction "include" pour minimiser la répétition du bloc entier de votre code.
Cela a déjà été dit, mais, oui, vous devez vérifier vos informations d'identification d'utilisateur sur chaque page. Si votre site utilise PHP, par exemple, la façon la plus simple de le faire est d'enregistrer l'utilisateur connecté et son niveau de privilège dans les variables de session, puis effectuez une vérification de ces variables de session au début du code. Ceux-ci sont effacés à la déconnexion (si vous avez créé une logique de déconnexion pour effacer ces variables) ou au délai d'expiration de la session (le délai d'expiration peut être défini, mais je pense que la valeur par défaut est 5 minutes d'inactivité), donc un utilisateur non autorisé ne devrait pas être en mesure d'accéder une feuille. D'autres technologies auront une manipulation similaire.
Je ne veux vraiment pas paraître condescendant quand je dis cela, alors j'espère que vous ne le voyez pas sous cet angle, mais c'est une sorte d'information de pain et de beurre. Si vous ne l'avez pas appris d'une manière ou d'une autre dans vos auto-études, je vous suggère fortement d'en prendre note et de lire un peu plus en profondeur sur ce sujet particulier, car c'est très important. Vous le ferez encore et encore pour toute application similaire du genre.
Prenez note qu'il existe différentes façons de le faire de manière simple et efficace, et une suggestion personnelle de ma part serait de vous entraîner à le coder dans votre propre logique afin de bien comprendre comment cela fonctionne, avant d'essayer d'utiliser un cadre. Testez-le par rapport à plusieurs méthodes d'accès, et une fois que vous êtes satisfait, vous pouvez voir comment les différents cadres exécutent la gestion des sessions utilisateur.
[~ # ~] edit [~ # ~] : Je mets ceci sur un commentaire ci-dessous, mais c'est en fait une bonne ressource pour OP également : https://www.w3schools.com/php/php_sessions.asp
L'utilisateur ne doit pas pouvoir accéder à la page, qu'il tape l'adresse ou clique sur le lien.
Une solution générique à votre problème consiste à utiliser une approche de contrôle d'accès basé sur les rôles (RBAC). Créez différents groupes et affectez des utilisateurs de privilèges égaux au groupe correspondant. De même, regroupez les pages Web et autres ressources dans différents dossiers; chacun appartenant à un groupe spécifique. J'avais utilisé chgrp (groupe de changement) pour y parvenir sur un système exécutant Linux embarqué avec un serveur Web léger. La même chose peut être obtenue dans le serveur Web Apache en plaçant un fichier .htaccess et en refusant l'accès comme indiqué sur Stack Overflow .
Pour les éléments de l'interface utilisateur, vous devrez créer différentes pages (ou masquer les éléments en vérifiant les groupes). Vous devrez identifier l'utilisateur (se connecter et déterminer son groupe correspondant), puis afficher les pages Web en fonction des privilèges de l'utilisateur.
Juste une petite suggestion sur l'implémentation, car vous aviez des inquiétudes à propos de 100s de pages. Par exemple, dans ASP.NET MVC, vous pouvez créer un filtre global ou une page "de base" dont tous les autres pourraient hériter.
Ensuite, le code, qui est situé au centre, pourrait vérifier le contexte/la session de l'utilisateur et le comparer à une liste de droits/autorisations/ou d'appartenance à un groupe pour la page actuelle (peut-être une structure de données sur chaque page ou une recherche de base de données basée sur le nom de la page, etc.).
Les autres réponses ont été très générales, donc je vais ajouter ceci parce que JSP pages ont été mentionnées, donc je pense que je peux supposer que vous travaillez en Java.
En tant que tel, vous pouvez très probablement utiliser Filtres pour faire exécuter du code chaque fois qu'une demande est adressée à l'application. Si vous utilisez un cadre de sécurité comme Spring , vous pouvez configurer les URL accessibles et par qui.