Question:
L'utilisateur ne peut pas accéder à la page Web via l'interface utilisateur en raison des autorisations, mais peut accéder à la page en collant l'URL. Comment me protéger contre cela?
Michael
2017-10-10 21:33:32 UTC
view on stackexchange narkive permalink

Dans mon application, les utilisateurs ont certains rôles qui ont des autorisations. Ces autorisations déterminent les éléments de l'interface utilisateur qui leur sont disponibles sur l'écran d'accueil. De nombreux éléments renvoient à 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 liens à une page aléatoire de l'application, disons http://www.example.com/example.jsp . Cependant, l'utilisateur John dispose d'autorisations qui ne lui permettent pas de voir button1 . Par conséquent, John ne peut pas accéder à http://www.example.com/example.jsp.

Le problème que je rencontre est que si je suis connecté en tant que John, et Je colle cette URL, cela me mènera à la page.

Évidemment, c'est un risque énorme 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 peu efficace à inclure code sur chaque page pour ce faire. Y a-t-il un moyen plus simple de faire cela que la méthode que je viens de mentionner?

Je suis curieux de savoir si cela est considéré comme le même problème que "[Navigation forcée] (https://www.owasp.org/index.php/Forced_browsing)"?Cette page la décrit comme la recherche de pages qui n'ont jamais été destinées à être publiques, plutôt que de contourner les vérifications des autorisations des utilisateurs.
@Michael Si l'exécution de code sur chaque page nécessite en fait de modifier chaque page individuellement, vous faites probablement d'autres choses mal également.Si vous ne disposez d'aucune disposition pour les contrôles de sécurité et d'intégrité à l'échelle du site, vous devez l'ajouter le plus tôt possible.Les développeurs ont-ils une formation en sécurité?Il y a des drapeaux rouges partout ici, et réparer les choses que vous trouvez laissera les choses que vous n'avez pas trouvées intactes.
Comme il semble que votre application soit basée sur des servlets, Spring Security vaut la peine d'être examiné (vous n'avez pas besoin d'utiliser Spring pour l'utiliser, même si Spring est génial).
Oui, chaque page et chaque action destructrice et chaque action qui expose des données privées.Ce que vous avez ici s'appelle une "préoccupation transversale"
Les autorisations ne doivent pas être appliquées en masquant simplement les éléments de l'interface utilisateur;) mais avec les réponses, je pense que vous comprenez cela maintenant
J'essaie toujours de changer l'URL pour le plaisir.Quand il n'y a qu'un enable.php, j'essaye disable.php par exemple.
Si vous effectuez actuellement des contrôles de sécurité au niveau du client (ce qui est bien pour éviter les requêtes inutiles au serveur, mais en aucun cas sécurisé), vous pouvez avoir d'autres problèmes de sécurité, comme les injections SQL.Assurez-vous que votre serveur gère correctement toutes les données que votre client lui envoie (et oui, comme tout le monde l'a déjà mentionné, votre serveur doit s'assurer que l'utilisateur actuellement connecté est autorisé à exécuter la requête HTTP actuelle).
Je n'ai lu les mots magiques dans aucune réponse.**Faire.Ne pas.Confiance.Contribution.Déjà.**.
@usr-local-ΕΨΗΕΛΩΝ absolument, cette règle appliquée à fond vous amène un long chemin vers une sécurité raisonnable.
@danbru1211 Je pensais avoir accidentellement pénétré dans un truc de réseautage jusqu'à ce que je réalise que ce n'était qu'une démo du produit que l'entreprise vendait.Le mot de passe «security» était un hachage «md5» côté client, et il était complètement cassé si vous faisiez quelque chose de similaire à ce que vous avez décrit.C'est un excellent moyen d'effectuer des tests de stylet vraiment basiques.
J'ai un script GreaseMonkey qui me permet de voir ** tous les éléments cachés ** sur la page en appuyant sur ** une seule touche **!Imaginez ce que je peux faire sur votre site Web si je prends la peine de lire le code source!
"* Le problème que je rencontre est que si je suis connecté en tant que John *" - Pourquoi pouvez-vous vous connecter à volonté aux comptes des autres?
Implémenter l'interface `javax.servlet.Filter` est ce que vous voulez.Il vous permet de traiter chaque demande.Btw jsp est grossièrement obsolète et à moins qu'il ne s'agisse d'un projet universitaire, vous devez strictement abandonner Java EE et utiliser des frameworks plus modernes qui ont toutes ces nécessités de base intégrées.
Désolé, mais vous semblez ne pas comprendre du tout la sécurité de base des applications Web.Vous devriez jeter un œil au [Top Ten OWASP] (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).
Je suis étonné de voir à quel point cette situation est courante ...
Sept réponses:
Trickycm
2017-10-10 21:43:34 UTC
view on stackexchange narkive permalink

Dois-je vérifier l'utilisateur pour chaque page?

Absolument. Non seulement chaque page, mais chaque demande à une ressource privilégiée, par exemple demande POST pour mettre à jour des données, supprimer, afficher, 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 cassé 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 sur le net 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: Sécurité opérationnelle: interfaces administratives.

Je veux juste répéter parce que votre réponse n'est pas une mince affaire au stade des PO: Oui, c'est absolument la bonne et la seule réponse.Chaque page doit appliquer correctement les règles de sécurité.Il semble que tout ce qui est en place actuellement est la sécurité côté client, qui ne fournit en fait aucune sécurité.Il existe des moyens d'écrire le code afin que vous puissiez facilement appliquer la sécurité sur chaque page, mais il n'y a pas de réponse qui n'implique pas l'application de la sécurité à chaque demande individuelle.Sinon, vous n'avez aucune sécurité.
Pour être un peu plus précis que ce que vous dites Trickycm, idéalement, vous devez trouver une solution unifiée pour gérer à la fois les liens de navigation / bouton / ... et la navigation URL directe.Comme il est unifié, vous avez beaucoup moins de chances d'oublier une chose.Parce que si ce n'est pas le cas, cela signifie que vous devez toujours gérer au moins deux déclinaisons différentes de la même sécurité (note: je l'ai actuellement et j'ai besoin de l'unifier,: 3).
Juste une note: ** Les requêtes AJAX ** sont également des requêtes et ** doivent être vérifiées **.Peu importe que cette demande AJAX particulière ne se produise qu'à partir d'une page qui a déjà vérifié l'utilisateur.Je sais que cela relève de «chaque demande» dans la réponse.juste en s'assurant qu'OP le sait aussi.
Un point supplémentaire: Cette vérification doit être faite ** sur le serveur ** - pas par code javascript qui est exécuté (ou non) sur le client.Un utilisateur malveillant peut éviter d'exécuter le code javascript.
Enfin: utiliser javascript pour masquer les liens auxquels l'utilisateur n'a pas accès est bien - mais c'est une question d'avoir une interface utilisateur agréable, pas de sécurité.
Il pourrait être utile d'inclure le terme «autorisation» quelque part dans cet article, car c'est aussi un terme courant pour décrire la vérification / gestion des autorisations et peut donc être utile dans la recherche.
@MartinBonner Je préférerais "cacher" les liens en PHP - cela pourrait être plus lent, mais si le HTML n'est jamais généré pour ces liens, le client / utilisateur ne serait pas plus sage même s'il parcourait le code source via un navigateurinspecteur.
@psosuna Pourquoi serait-il important que le client / utilisateur puisse trouver les URL?Ils ne peuvent rien faire avec eux.S'ils essaient d'utiliser ces URL, le serveur dira simplement "Désolé, vous n'êtes pas un administrateur".
@immibis par souci de propreté, voire pas du tout.Il se peut qu'il y ait * la seule page * du site qui n'applique pas la sécurité (comme il se doit!) Et que l'adresse de celle-ci peut être découverte lors de l'inspection de la source côté client.Pour atténuer cette possibilité, il vaut mieux ne pas le révéler, non?Mieux vaut prévenir que guérir, dis-je.
@psosuna: [haussement d'épaules] Je me fiche de savoir où vous cachez les liens.Le fait est que cacher les liens n'est pas vraiment une question de sécurité, il s'agit d'un bon UX.(Bien que ce soit un cas où un bon UX n'est certainement pas en conflit avec la sécurité.)
@MartinBonner est totalement d'accord avec vous, mais en général, la sécurité concerne les couches.Et bien que cacher les liens n'est bien sûr pas une sécurité, cela peut aider.S'il y a un bogue quelque part dans la vérification de sécurité, ne pas avoir les liens ajoute encore quelque chose, donc je préfère également ne pas envoyer les données aux clients en premier lieu.(Je le vois comme une autre couche).
À toutes fins utiles, toutes les ressources / demandes que votre serveur n'authentifie pas et n'autorise pas directement doivent être considérées comme publiques.Si vous ne vérifiez pas que la demande X provient d'un utilisateur enregistré avec les autorisations appropriées, la demande X est publique et peut être consultée par n'importe qui, indépendamment de ce que votre interface utilisateur fournira.
Stilez
2017-10-11 22:42:57 UTC
view on stackexchange narkive permalink

La réponse rapide est oui, comme vous l'avez compris. Mais il n'est pas nécessaire que ce soit l'énorme travail auquel vous pensez. (Toute la sécurité peut être importante, mais ce n'est qu'une partie de celle-ci). Vous avez des problèmes bien plus sérieux que cela.

Pourquoi c'est important

TOUT CE que vous créez sera frappé par des tentatives de le casser. Quelqu'un sera curieux. Quelqu'un fera quelque chose auquel vous ne vous attendiez pas et qui défie votre pensée. Quelqu'un sera curieux, malveillant ou curieux.

Vous devez également tenir pour acquis que votre logiciel / application Web sera testé par des outils automatisés . Les serveurs dotés d'un portail en ligne (de presque tous les types) sont découverts par des pirates informatiques dans les dix minutes suivant leur première mise en ligne, et commencent à être interrogés pour détecter l'un des milliers de défaillances ou d'erreurs de sécurité possibles. Cela signifie qu'ils sondent ce qui s'exécute exactement "en coulisse", ainsi que toutes les erreurs détectables qui peuvent être exploitées (dans la validation des données, la validation de script croisé, l'injection SQL ou binaire, le piratage JavaScript, le back-end lui-même, quoi des faiblesses peuvent survenir en forçant quelque chose à échouer, quelles données peuvent être exposées ...).

Votre (vos) serveur (s) Web sera (s) sondé (s) de cette façon, en permanence, pour détecter d'éventuels codes Web et échecs de back-end, par des centaines, voire des milliers d'outils automatisés. C'est aussi bien que les humains et les utilisateurs, pas à la place.

Préférez-vous que ce soit loin sur la route et porté à votre attention avec force par les critiques, les médias et les utilisateurs en colère, ou conduit à la 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 y parvenir ne sont pas difficiles et sont bien documentés. Le nombre de pages n'est donc pas un gros problème.

La partie la plus difficile du travail est que la sécurité est dure . 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 avoir l'espoir de le faire sans aide. Sérieusement. Tu. Faire. Non.

Je ne sais pas quelle est la taille de votre équipe ou vos ressources. Vous en avez besoin - et vous n'avez probablement pas l'espoir de le faire sans une aide extérieure.

Ma vraie préoccupation ici

Cela dit, ma vraie préoccupation n'est pas l'application Web . C'est l'état d'esprit que suggère cette question.

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 un après coup, une interruption de votre travail ou un inconvénient à réparer par la suite (ou vous ne le comprenez pas suffisamment pour que vous ayez traité de cette façon jusqu'à présent), et peut-être que les problèmes sont des choses vraiment basiques, comme coder correctement l'URL d'un bouton .

La sécurité est votre travail, car quelle que soit la qualité technique du produit / service et quels que soient ses utilisateurs, votre vrai produit est la confiance et l'assurance que vous répondrez à mes besoins et ne me causerez pas de catastrophe majeure.

Je suis censé faire confiance à votre application avec mes données? Pour le moment, 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 "si mauvais" une situation et une impression, et non, ce n'est pas une exagération pour l'effet.

Je suis désolé.

Maintenant, si votre application est bonne, impliquez quelqu'un d'autre.

La dernière partie de ceci semble suggérer que les clients décident des produits en fonction de la sécurité.Sauf dans certaines niches très, très spécifiques, ce n'est tout simplement pas vrai et pour un PoV professionnel, c'est une idée horrible de dépenser plus que le strict nécessaire pour des exigences non fonctionnelles telles que la sécurité en tant que startup.Oui, tout le monde ici déteste cet état d'esprit, mais le simple fait demeure que les utilisateurs ne se soucient pas de la sécurité et même s'ils l'ont fait, ils ne pourraient pas juger ce qui est sécurisé et ce qui ne l'est pas (ne le croyez pas? Allez-y et vérifiez lenuméros d'utilisateur de TextSecure / Signal avec WhatsApp)
Vous pensez à l'avance.Pas au départ, non.Mais une fois qu'un problème majeur est connu, oui.Une fois qu'il atteint les critiques - oui.Une fois que les médias sociaux commencent à recevoir des commentaires tels que "Qu'est-ce qui s'est passé et comment cela pourrait-il arriver" par plus d'une ou deux personnes - oui.Les gens ne recherchent pas activement la sécurité, mais ils examinent les avis et la connaissance du public, si c'est là-bas, et ce sera après un certain temps.(Je suis d'accord que ce serait mieux s'ils regardaient en premier, mais si c'est un problème majeur, comme l'indique l'OP, cela deviendra visible assez rapidement - juste à propos du moment où quelque chose cloche et que quelqu'un publie à ce sujet avec colère)
Silencer310
2017-10-11 02:46:02 UTC
view on stackexchange narkive permalink

Vous devez vérifier le niveau de permission utilisateur pour chaque demande (GET, POST, PUT, DELETE). Naviguer vers une page, comme dans votre cas, est une requête GET. Un utilisateur ne devrait pas non plus être en mesure de publier une demande sans autorisation.

Maintenant, si vous devez ajouter le code sur chaque page de votre application dépend de votre framework d'application. Par exemple, certains frameworks (Laravel, Express.JS) vous permettent de regrouper des itinéraires et d'appliquer un filtre à chaque demande pour cet itinéraire, et c'est là que vous effectuez 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.

HEAD ou toute autre [méthodes HTTP étranges] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods), aussi (à moins bien sûr que vous * toujours * bloquez ceux-ci).
psosuna
2017-10-11 04:11:22 UTC
view on stackexchange narkive permalink

Cela a déjà été dit, mais oui, vous devez vérifier vos identifiants d'utilisateur sur chaque page. Si votre site utilise PHP, par exemple, le moyen le plus simple de le faire est de sauvegarder l'utilisateur connecté et son niveau de privilège dans des variables de session, puis de faire une vérification de ces variables de session au début du code. Ceux-ci sont effacés lors de la déconnexion (si vous avez créé une logique de déconnexion pour effacer ces variables) ou du 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 de 5 minutes d'inactivité), donc un utilisateur non autorisé ne devrait pas être en mesure d'accéder une feuille. D'autres technologies auront un traitement 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 ce sont des informations essentielles . Si vous ne l'avez pas appris ou ne l'avez pas rencontré 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 ferez cela maintes et maintes fois 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 que vous compreniez pleinement comment cela fonctionne, avant d'essayer d'utiliser un framework. Testez-le par rapport à plusieurs méthodes d'accès, et une fois que vous êtes satisfait, vous pouvez examiner comment les différents frameworks effectuent la gestion des sessions utilisateur.

EDIT : J'ai mis ceci dans un commentaire ci-dessous, mais c'est en fait une bonne ressource pour OP également: https://www.w3schools.com/ php / php_sessions.asp

Quelles garanties de sécurité PHP fournit-il pour ces variables de session?Sont-ils stockés sur la machine cliente;sinon, comment un client identifie-t-il sa session?Les données côté client sont-elles chiffrées?Existe-t-il des garanties contre le partage des données côté client?
Voici une explication rapide et simple des sessions PHP: https://www.w3schools.com/php/php_sessions.asp.Les informations et les variables de session ne sont pas stockées côté client, mais uniquement côté serveur.Une clé est fournie par le serveur au client.La clé est utilisée pour identifier la session sur laquelle l'utilisateur est en ce moment.
@jpmc26 un aparté supplémentaire: PHP = Hypertext * Pre- * processor.Cela signifie que le code PHP s'exécute côté serveur.Il s'exécute avant le HTML, il y a donc beaucoup de choses qui n'ont pas besoin d'être transmises à la machine de l'utilisateur.C'est pourquoi PHP est une bonne option pour l'authentification, car les données d'entrée peuvent être vérifiées avant qu'une réponse ne soit renvoyée au client.
Oh, je connais assez bien que PHP est une technologie côté serveur.(Je travaille sur des applications Web pour gagner ma vie, mais pas sur PHP.;)) Mais je sais que * quelque chose * doit être stocké côté client pour que la session utilisateur soit identifiable.D'où mes questions sur le chiffrement de ces données et ce que vous avez (pour empêcher le piratage de session ou le partage intentionnel de la clé avec un autre utilisateur).Voir [cette critique] (https://security.stackexchange.com/a/18898/46979), par exemple.Je ne sais pas si cela a changé au cours des 5 dernières années.
@jpmc26 Je pense que la critique est mal ciblée: il s'agit de serveurs partagés mal configurés pour que les utilisateurs puissent accéder aux données de chacun.Plutôt que le chiffrement, la réponse est de placer les sessions dans un répertoire auquel les autres utilisateurs ne peuvent pas accéder;s'il n'y a pas de tel répertoire, ils pourront de toute façon accéder à votre clé de déchiffrement.Cela n'a également rien à voir avec le piratage de session, qui décrit généralement un attaquant volant l'identifiant de session * côté client *;le cryptage n'y aiderait pas non plus.
@jpmc26 Par peur d'aller trop loin du sujet, vous protégez les sessions avec des jetons csrf.Chaque action que vous effectuez actualise le jeton (donc je demande quelque chose avec mon jeton => serveur renvoie un nouveau jeton à utiliser pour la prochaine chose).
Majid Khan
2017-10-10 22:11:12 UTC
view on stackexchange narkive permalink

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 un contrôle d'accès basé sur les rôles ( Approche RBAC). Créez différents groupes et attribuez 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 des éléments par vérification de groupe). Vous devrez identifier l'utilisateur (en le connectant et en déterminant le groupe correspondant), puis afficher les pages Web selon les privilèges de l'utilisateur.

Jester
2017-10-11 02:25:04 UTC
view on stackexchange narkive permalink

Juste une petite suggestion sur la mise en œuvre, car vous aviez des inquiétudes sur des centaines 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 comparez-le à 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.).

Readin
2017-10-14 07:44:13 UTC
view on stackexchange narkive permalink

D'autres réponses ont été très générales, donc j'ajouterai ceci parce que les pages JSP 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 des filtres pour exécuter le code à chaque fois qu'une demande est faite à l'application. Si vous utilisez un cadre de sécurité tel que Spring, vous pouvez configurer des URL accessibles et par qui.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...