Share
Attribuer à chaque utilisateur de site Web un compte individuel vous permet d'identifier de manière unique les utilisateurs de votre site Web et de valider qu'ils sont bien ce qu'ils prétendent être. Connaître l'identité d'un utilisateur permet au site Web de changer pour refléter les besoins et les intérêts de chaque utilisateur. Comme les sites Web contiennent normalement plusieurs sections conçues pour des utilisateurs de différents rôles, du grand public aux administrateurs système de haut niveau, vous pouvez également utiliser cette identification pour gérer l'accès aux différentes ressources du site Web dont chaque utilisateur a besoin..
Sur un intranet d'entreprise interne, il peut y avoir des pages contenant des rapports et des données sensibles qui ne doivent être vus que par des départements spécifiques ou des cadres supérieurs et non par tous les employés de l'entreprise. Dans la plupart des cas, seuls certains administrateurs auraient un accès complet au paramètre de modification du site Web, d'autres utilisateurs pouvant éventuellement bénéficier d'une capacité de modification moindre. Dans tous ces cas, nous devons limiter ces options à la plupart des utilisateurs tout en les autorisant à d’autres. L'autorisation vous permet de vous assurer qu'un utilisateur peut accéder à tout ce dont il a besoin sur un site Web et effectuer les tâches souhaitées, sans plus..
Par exemple, sur un site de commerce électronique, vous souhaitez que les clients recherchent des produits, les ajoutent à un panier et les commandent. Une fois la commande passée, ils devraient pouvoir suivre leur commande et éventuellement la modifier avant l'expédition. Cependant, vous pouvez également souhaiter que les nouveaux clients parlent à un agent du service clientèle avant de leur permettre de modifier une commande. En aucun cas, ne voudriez-vous qu'un client puisse afficher, modifier ou annuler les commandes d'autres clients.
En tant que développeur Web, un aspect important de la sécurité d'un site consiste à s'assurer que les utilisateurs n'ont pas accès aux actions qu'ils ne doivent pas effectuer. Les conséquences de ne pas le protéger peuvent être graves.
Regardons un aperçu de l'autorisation et comment l'implémenter dans ASP.NET.
Donner des comptes uniques à des personnes nous permet d’identifier qui accède à notre site Web. Faire confiance au site sait qui est une personne qui est l’authentification et a déjà été discuté.
Une fois que nous connaissons l'utilisateur, nous pouvons personnaliser le site pour cet utilisateur et personnaliser le site Web pour refléter les informations dont nous disposons sur l'utilisateur. Cela peut varier d'aspects simples, tels qu'un site Web indiquant «Bonjour Bill» lorsque je me connecte.
La plupart des sites marchands peuvent enregistrer ma carte de crédit, mon adresse et d'autres informations nécessaires pour passer une commande. Cela signifie que je n'ai pas besoin d'entrer les mêmes informations à chaque fois, ce qui me permet de placer et de commander plus facilement et donc plus de chances de passer commande auprès d'eux. Les sites Web peuvent également aller plus loin en utilisant mon histoire et mes habitudes pour suggérer des produits connexes susceptibles de m'intéresser ou des articles similaires que je pourrais apprécier de lire. Je pourrais également être en mesure de définir des préférences dans les couleurs, les catégories préférées ou d'autres paramètres que le site peut utiliser..
Cela peut offrir des avantages utiles aux utilisateurs du site, mais l'autorisation consiste principalement à utiliser l'identité unique de l'utilisateur pour déterminer les actions que celui-ci peut effectuer. Il permet au site Web de déterminer si un utilisateur doit avoir la possibilité d’accéder à différentes sections d’un site Web, d’être capable d’accéder aux données ou d’apporter des modifications aux données..
L’utilisation de l’identité sera l’objet principal de cet article car nous examinons des méthodes de protection de parties de votre site Web, en mettant l’accent sur ASP.NET..
S'il est possible de fournir des droits et des responsabilités uniques pour chaque utilisateur à un site Web, cela devient rapidement ingérable à mesure que le nombre d'utilisateurs augmente. Rapidement, le risque d'erreur augmente avec chaque nouvel utilisateur ayant besoin d'une configuration personnalisée. Si une modification du site nécessite de nouveaux droits ou paramètres, chaque compte d'utilisateur devra être mis à jour, ce qui nécessitera éventuellement des mises à jour manuelles pour des centaines, voire des milliers de comptes..
Pour cette raison. les utilisateurs sont normalement regroupés avec ceux qui ont des droits ou des besoins similaires. Les groupes sont souvent parfois appelés rôles, car le rôle de l'utilisateur sur un site définit souvent les groupes utilisés. Pour chaque groupe, l'administrateur du site peut définir l'accès et les restrictions au sein de l'application Web..
Vous affectez ensuite des utilisateurs à ces groupes, qui se verront attribuer les droits et restrictions attribués à ce groupe. Les droits peuvent être supprimés simplement en supprimant l'utilisateur du groupe. La plupart des systèmes prennent en charge un utilisateur appartenant à plusieurs groupes en même temps, car un utilisateur peut avoir plusieurs rôles..
Les utilisateurs ayant plusieurs rôles nécessitent une méthode permettant de traiter les cas dans lesquels les paramètres de deux groupes sont en conflit. Prenons par exemple un utilisateur membre de deux groupes. Un groupe permet à l'utilisateur de créer une nouvelle publication de blog et le second refuse cette possibilité à l'utilisateur. Le site Web doit gérer ce conflit de manière cohérente et prévisible. Dans presque tous les cas, la meilleure pratique n'autorise aucun droit par défaut, ajoute uniquement des droits spécifiquement répertoriés et permet de refuser le remplacement d'autres paramètres. Dans ce cas, le groupe qui nie le droit priment le groupe qui refuse l'accès..
Une modification consistant à scinder les utilisateurs en groupes basés sur des rôles consisterait à créer des groupes basés sur l'activité. Dans le premier cas, vous pourriez avoir «auteurs», «éditeurs», «éditeurs», etc. Dans le second cas, vous pourriez avoir des groupes pour «créer un article», «éditer un article», «supprimer un article», «publier un article». Cette méthode donne plus de flexibilité en échange pour gérer plus de groupes.
Votre première préoccupation devrait être de protéger les pages Web sur votre site. Je me concentre sur ASP.NET pour les spécificités de cet article, mais la plupart des frameworks Web utilisent des concepts similaires mais pas les mêmes fichiers et commandes. Selon le système, il existe trois approches pour sécuriser le site Web ASP.NET:
Le routage ASP.NET et les formulaires Web ASP.NET utilisent le web.config fichier pour sécuriser l'accès à la page Web. Une configuration de base pour sécuriser l’accès à une ressource sur un site Web se présentera de la manière suivante:
L'élément location de cet extrait de code XML définit le chemin d'accès au fichier, au dossier ou à la route que nous traitons. Ici, nous spécifions que cela s'applique au adminhome.aspx page spécifiée. Cela pourrait également donner un dossier sur le site et s'appliquer à ce dossier. Si vous ne spécifiez aucun attribut path, les paramètres de configuration s’appliquent au répertoire en cours de cette web.config fichier et tous les répertoires enfants.
le autorisation L'élément contient les paramètres utilisés pour définir qui a accès et qui se voit refuser l'accès à l'objet spécifié dans le chemin élément. Les règles sont vérifiées en commençant par la première règle jusqu'à ce qu'une correspondance soit trouvée. le permettre element spécifie les rôles et / ou les utilisateurs qui se verront accorder l'accès à la ressource. De même le Nier element spécifie les utilisateurs et les rôles qui ne seront pas autorisés à accéder à la ressource.
Dans cet exemple, le
Quelques caractères spéciaux permettent de spécifier des groupes communs. Nous avons vu le * utilisateur ci-dessus, qui spécifie tous les utilisateurs. le ? utilisateur fait référence aux utilisateurs anonymes, c'est-à-dire tout utilisateur qui ne s'est pas connecté actuellement. Vous pouvez spécifier plusieurs utilisateurs et rôles en les séparant par une virgule. Les utilisateurs et les rôles peuvent être mélangés dans la même règle, par exemple:
ASP.NET MVC se concentre sur les contrôleurs et les actions sur ces contrôleurs au lieu de fichiers. Cela modifie la méthode de sécurisation de l'accès à un site ASP.NET MVC. Par défaut, toutes les actions et tous les contrôleurs sont accessibles à tous les utilisateurs, comme dans WebForms. Vous utilisez toujours les mêmes attributs de rôle et d’utilisateur, mais vous ne les définissez plus dans la web.config fichier.
Au lieu de cela, vous appliquez un [Autoriser] attribuer à vos contrôleurs et actions directement. Par exemple, si vous avez un AdminController seuls les membres du rôle admin doivent y accéder. Vous pouvez le faire en ajoutant les utilisateurs et / ou les rôles à la balise. Notez que cela agit comme une permission avec un refus implicite pour tout ce qui n'est pas spécifiquement autorisé.
[Authorize (Roles = "siteadmin")] Classe publique AdminController: Controller …
Le même * et ? Des options pour tous les utilisateurs et les utilisateurs anonymes sont également disponibles pour cet attribut. Vous pouvez appliquer les règles spécifiquement à une action individuelle sur le contrôleur pour limiter uniquement ces actions. Les attributs spécifiés pour une action remplacent ceux spécifiés pour le contrôleur entier..
[Authorize (Roles = "siteadmin")] public ActionResult AdminView () …
Si vous ne spécifiez pas de rôles ou d'utilisateurs avec le [Autoriser] attribut, il autorisera tout utilisateur authentifié à se connecter. Cela vous permet d’autoriser uniquement l’accès aux actions ou aux contrôleurs d’utilisateurs spécifiquement connectés au système..
ASP.NET 4 a ajouté un [AllowAnonymous] attribut qui vous permet de remplacer cela pour une action dans un contrôleur. Vous pouvez le trouver utilisé dans tout nouveau projet Internet ASP.NET MVC par défaut pour gérer l’accès au AccountController manette.
Une fois que vous avez protégé l'accès aux dossiers, fichiers, actions et itinéraires de votre site, vous devez ensuite veiller à garantir un accès correct au sein même du code serveur. Certaines pages sont simples à sécuriser car un seul rôle doit pouvoir y accéder ou les voir et ces utilisateurs ont la possibilité de faire tout ce qui est prévu sur la page..
Pour de nombreuses pages, différents rôles peuvent accéder à la même page, mais ont des droits et des capacités différents une fois sur la page. Dans ces cas, veillez à ne pas afficher de liens vers des actions, des URL ou des fichiers auxquels l'utilisateur actuel n'a pas le droit d'accéder..
Il est inutile de montrer le lien vers la zone d'administration à un utilisateur sans accès administrateur ou à un bouton "Commande de remboursement" pour un utilisateur qui n'a pas cette possibilité. Même si le bouton ou le lien est inactif, il fournit des informations potentielles à un attaquant. Cela peut également semer la confusion chez les utilisateurs légitimes du site. Si le lien est actif, mais demande ensuite une connexion, vous avez fourni à un attaquant une page à cibler, et de nouveau peut-être confondu un utilisateur légitime du site..
Le code serveur situé derrière une page à laquelle accèdent des utilisateurs occupant plusieurs rôles doit toujours valider les droits de l'utilisateur avant d'effectuer une action. Si les administrateurs et les utilisateurs anonymes peuvent accéder à une page, vous devez valider que l'utilisateur occupe un rôle d'administrateur avant d'effectuer des actions que seul le rôle d'administrateur peut effectuer. L'utilisateur peut tenter une action qu'il ne devrait pas être capable d'accomplir en cliquant sur un lien qu'il n'aurait pas dû afficher, par une expérimentation ou par une tentative de piratage délibéré..
Encore une fois, prenez toujours le moins de privilèges et demandez une attribution explicite via l'appartenance à un groupe, des rôles ou d'autres éléments avant d'effectuer des fonctions sécurisées.
Faites également attention si l'action est transmise en tant que paramètre à une page. Prenez une URL qui complète une commande sous la forme de UpdateOrder.aspx? Order = 33 & action = delete. Image un pirate informatique a essayé d'accéder à d'autres actions au hasard jusqu'à sa découverte UpdateOrder.aspx? Order = 33 & action = refund créditerait le montant de la commande sans l'annuler. Ne vous fiez jamais à la dissimulation ou à l'absence d'un lien comme étant le seul mécanisme de défense contre des actions non autorisées..
Bien que l’aspect authentification diffère de l’élément d’autorisation discuté ici, ils sont interdépendants. Tout d'abord, à la session de connexion sont généralement définis avec un délai d'attente dans la configuration. Dans ASP.NET, cela est défini dans le fichier web.config du
Cela définirait le délai d'attente pour un utilisateur à 30 minutes. le glissementExpiration attribut détermine si une demande réinitialise ce compteur à zéro. Avec cela réglé faux, Un utilisateur devra alors se reconnecter toutes les trente minutes, même s'il utilise activement le site pendant tout ce temps..
Soyez également conscient du risque de détournement de session. La plupart des frameworks Web utilisent un identifiant unique pour l'utilisateur une fois authentifié, normalement stocké dans un cookie. Si ce cookie n'est pas protégé d'une manière ou d'une autre, toute personne pouvant visualiser le trafic de l'utilisateur peut utiliser ce cookie pour se faire passer pour l'utilisateur d'origine..
L'extension Firefox de FireSheep l'a démontré et fourni une méthode simple pour effectuer cette interception et cette usurpation d'identité. Vous ne pouvez empêcher cela qu'en utilisant le cryptage SSL de la totalité de la session du navigateur Web ou au moins en protégeant le cookie contenant les données avec le cryptage SSL..
Vous pouvez vous protéger contre cela en utilisant uniquement des cookies SSL pour le jeton d'authentification représentant l'utilisateur connecté. Cela garantit que le cookie n'est envoyé que lorsque la page est accessible via SSL.
En ASP.NET, vous pouvez appliquer cela en définissant la requireSSL = "true" attribuer sur le web.config lors de l'utilisation de l'authentification par formulaires. Pour plus de protection, vous pouvez également définir la web.config définir tous les cookies sur SSL uniquement par défaut.
L'utilisation de sites Web par de nombreux utilisateurs ayant des besoins et des responsabilités différents nécessite des méthodes permettant d'empêcher tout accès non autorisé à des données et à des fonctionnalités sensibles. Vous pouvez utiliser l'identité unique d'un utilisateur pour déterminer les droits de cet utilisateur et les appliquer dans votre application Web..
Vous commencez par vous assurer que les pages et les actions au sein de votre application Web sont limitées aux seuls utilisateurs qui devraient être en mesure de les utiliser..
Pour les pages auxquelles accèdent des utilisateurs dans plusieurs rôles, vous devez vous assurer que l'utilisateur a le droit d'effectuer les actions demandées avant de les exécuter. Etant donné que l'identité de l'utilisateur définit son accès, vous devez également veiller à ce que les autres utilisateurs ne puissent pas emprunter l'identité d'un utilisateur disposant de plus de droits..
La combinaison de ces étapes contribuera grandement à la protection de votre application Web..
Accentsconagua