Quelles sont les meilleures pratiques pour sécuriser la section admin d’un site Web?

J’aimerais savoir ce que les gens considèrent comme les meilleures pratiques pour sécuriser les sections Admin des sites Web, en particulier du sharepoint vue de l’authentification / access.

Bien sûr, il y a des choses évidentes, comme l’utilisation du protocole SSL et la journalisation de tous les access, mais je me demande où, au-delà de ces étapes de base, les utilisateurs considèrent la barre à définir.

Par exemple:

  • Est-ce que vous utilisez uniquement le même mécanisme d’authentification que vous utilisez pour les utilisateurs normaux? Si non, quoi?
  • Exécutez-vous la section Admin dans le même domaine d’application?
  • Quelles mesures prenez-vous pour que la section admin ne soit pas découverte? (ou rejetez-vous toute la chose “obscure”)

Jusqu’à présent, les suggestions des répondeurs incluent:

  • Introduire une pause artificielle côté serveur dans chaque vérification de mot de passe administrateur pour éviter les attaques par force brute
  • Utilisez des pages de connexion séparées pour les utilisateurs et admin en utilisant la même table de firebase database (pour arrêter XSRF et le vol de session en donnant access aux zones admin) [Thief Master]
  • Envisagez également d’append une authentification native du serveur Web à la zone d’administration (par exemple, via .htaccess) [Thief Master]
  • Envisagez de bloquer les utilisateurs IP après un certain nombre de tentatives de connexion admin ayant échoué [Thief Master]
  • Ajouter captcha après échec des tentatives de connexion admin [Thief Master]
  • Fournir des mécanismes tout aussi solides (utilisant les techniques ci-dessus) pour les utilisateurs et les administrateurs (par exemple, ne pas traiter les administrateurs spécialement) [Lo’oris]
  • Envisagez une authentification de second niveau (par exemple, certificates clients, cartes à puce, espace de cartes, etc.) [JoeGeeky]
  • Autoriser uniquement l’access à partir d’IP / Domaines de confiance, append un contrôle au pipeline HTTP de base (via par exemple des modules HTTP) si possible. [JoeGeeky]
  • [ASP.NET] Verrouillez IPrincipal & Principal (rendez-les immuables et non énumérables) [JoeGeeky]
  • Fédérer les droits – par exemple, envoyer un e-mail à d’autres administrateurs lorsque les droits d’un administrateur sont mis à niveau. [JoeGeeky]
  • Envisagez des droits précis pour les administrateurs – par exemple, plutôt que des droits basés sur des rôles, définissez des droits pour les actions indicatives par administrateur [JoeGeeky]
  • Restreindre la création d’administrateurs – par exemple, les administrateurs ne peuvent pas modifier ou créer d’autres comptes d’administrateur. Utilisez un client «superadmin» verrouillé pour cela. [JoeGeeky]
  • Envisagez des certificates SSL côté client ou des porte-clés de type RSA (jetons électroniques) [Daniel Papasian]
  • Si vous utilisez des cookies pour l’authentification, utilisez des cookies séparés pour les pages admin et normales, en plaçant par exemple la section admin sur un autre domaine. [Daniel Papasian]
  • Si possible, envisagez de conserver le site d’administration sur un sous-réseau privé, hors de l’internet public. [John Hartsock]
  • Réémettre les tickets d’authentification / session lors du déplacement entre les contextes d’utilisation admin / normal du site Web [Richard JP Le Guen]

Ce sont toutes de bonnes réponses … J’aime généralement append quelques couches supplémentaires pour mes sections administratives. Bien que j’ai utilisé quelques variantes sur un thème, celles-ci incluent généralement l’un des éléments suivants:

  • Authentification de second niveau : cela peut inclure des certificates clients (ex. X 509 certs), des cartes à puce, un espace de cartes, etc.
  • Ressortingctions de domaine / IP : dans ce cas, seuls les clients provenant de domaines approuvés / vérifiables; tels que les sous-réseaux internes; sont autorisés dans la zone d’administration. Les administrateurs distants passent souvent par des points d’entrée VPN sécurisés afin que leur session soit vérifiable et souvent protégée par des clés RSA. Si vous utilisez ASP.NET, vous pouvez facilement effectuer ces vérifications dans le pipeline HTTP via les modules HTTP, ce qui empêchera votre application de recevoir des demandes si les contrôles de sécurité ne sont pas satisfaits.
  • Autorisation principale et principale bloquée : la création de principes personnalisés est une pratique courante, bien qu’une erreur commune les rend modifiables et / ou des droits énumérables. Bien que ce ne soit pas simplement un problème d’administration, c’est plus important car c’est là que les utilisateurs sont susceptibles d’avoir des droits élevés. Assurez-vous qu’ils sont immuables et non énumérables. De plus, assurez-vous que toutes les évaluations pour l’autorisation sont basées sur le principal.
  • Fédérer les droits d’élévation : lorsqu’un compte reçoit un nombre sélectionné de droits, tous les administrateurs et le responsable de la sécurité sont immédiatement informés par courrier électronique. Cela garantit que si un attaquant élève des droits, nous le soaps immédiatement. Ces droits s’articulent généralement autour de droits privilégiés, de droits d’access à des informations protégées par la confidentialité et / ou d’informations financières (par exemple, des cartes de crédit).
  • Délivrez des droits avec modération, même aux administrateurs : Enfin, et cela peut être un peu plus avancé pour certains magasins. Les droits d’autorisation doivent être aussi discrets que possible et doivent englober les comportements fonctionnels réels. Les approches de sécurité basées sur les rôles (RBS) ont généralement une mentalité de groupe . Du sharepoint vue de la sécurité, ce n’est pas le meilleur modèle. Au lieu de ” Groupes ” comme ” Gestionnaire des utilisateurs “, essayez de le décomposer davantage ( Ex. Créer un utilisateur, Autoriser un utilisateur, Élever / révoquer les droits d’access, etc. ). Cela peut prendre un peu plus de temps en termes d’administration, mais cela vous donne la flexibilité de n’atsortingbuer que des droits réellement nécessaires au groupe d’administrateurs plus important. Si l’access est compromis, au moins, ils peuvent ne pas avoir tous les droits. J’aime envelopper ceci dans les permissions CAS (Code Access Security) sockets en charge par .NET et Java, mais cela dépasse le cadre de cette réponse. Encore une chose … dans une application, les administrateurs ne peuvent pas modifier les autres comptes d’administrateur ou faire des utilisateurs un administrateur. Cela ne peut se faire que par un client verrouillé auquel seules quelques personnes peuvent accéder.

Si le site Web nécessite une connexion à la fois pour les activités régulières et pour les administrateurs, par exemple un forum, j’utiliserai des identifiants distincts qui utilisent la même firebase database d’utilisateurs. Cela garantit que XSRF et le vol de session ne permettront pas à l’attaquant d’accéder aux zones administratives.

En outre, si la section admin se trouve dans un sous-répertoire distinct, il peut être utile de sécuriser celui avec authentification du serveur Web (.htaccess dans Apache par exemple), puis quelqu’un a besoin de ce mot de passe et du mot de passe utilisateur.

Obscurcir le chemin d’administration ne donne quasiment aucun gain de sécurité – si quelqu’un connaît des données de connexion valides, il est probablement aussi capable de trouver le chemin de l’outil d’administration depuis qu’il l’a chemin aussi).

Une protection par force brute, telle que bloquer l’adresse IP de l’utilisateur après trois échecs de connexion ou nécessiter un CAPTCHA après un échec de connexion (pas pour la première connexion car cela est extrêmement ennuyeux pour les utilisateurs légitimes) pourrait également être utile.

  • Je rejette l’obscurité
  • Utiliser deux systèmes d’authentification au lieu d’un seul est excessif
  • La pause artificielle entre les tentatives devrait être faite pour les utilisateurs aussi
  • Le blocage des adresses IP des tentatives échouées devrait également être fait pour les utilisateurs
  • Les mots de passe forts doivent également être utilisés par les utilisateurs
  • Si vous considérez les captchas ok, devinez quoi, vous pourriez aussi les utiliser pour les utilisateurs

Oui, après l’avoir écrit, je me rends compte que cette réponse peut être résumée comme “rien de spécial pour la connexion administrateur, ce sont toutes les fonctions de sécurité qui doivent être utilisées pour toute connexion”.

Si vous n’utilisez qu’un seul identifiant pour les utilisateurs disposant à la fois des privilèges d’utilisateur et des privilèges d’administrateur, regénérez leur identifiant de session (que ce soit dans un cookie ou un paramètre GET ou autre …) en cas de modification du niveau de privilège … au moins.

Donc, si je me connecte, fais un tas de choses normales pour l’utilisateur, puis visite une page d’administration, régénère mon identifiant de session. Si je navigue ensuite depuis une ou plusieurs pages d’administration vers une page utilisateur normale, régénérez à nouveau mon identifiant.

Avoir un bon mot de passe administrateur.

Pas "123456" mais une suite de lettres, chiffres et caractères spéciaux assez longs, disons 15-20 caractères. Comme "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>" .

Ajoutez une pause pour chaque vérification de mot de passe pour empêcher une attaque par force brute.

Voici quelques autres points à considérer:

  1. Une option à envisager, en particulier si vous gérez les ordinateurs de l’administrateur ou si vous êtes techniquement compétent, consiste à utiliser quelque chose basé sur les certificates SSL pour l’authentification du client. Les porte-clés RSA et autres peuvent également être utilisés pour plus de sécurité.
  2. Si vous utilisez des cookies, peut-être pour un jeton d’authentification / session, vous voulez probablement vous assurer que les cookies ne sont envoyés qu’aux pages d’administration. Cela permet d’atténuer les risques liés à votre site en volant des cookies, soit par compromis de couche 1/2, soit par XSS. Cela peut se faire facilement en ayant la partie admin sur un nom d’hôte ou un domaine différent, ainsi qu’en définissant l’indicateur sécurisé avec le cookie.
  3. Restreindre par IP peut être aussi intelligent, et si vous avez des utilisateurs sur Internet, vous pouvez toujours le faire si un VPN de confiance peut être joint.

Nous utilisons l’ Windows Authentication pour l’access administrateur. C’est le moyen le plus pratique de protéger les zones d’administration tout en gardant l’authentification séparée de ce qui s’applique aux utilisateurs finaux généraux. L’administrateur système gère les informations d’identification de l’access de l’utilisateur Admin et applique les stratégies de mot de passe sur le compte d’utilisateur du domaine.

La méthode la plus ssortingcte consiste à avoir deux “fermes” différentes, y compris des bases de données, des serveurs et tout le rest, et à déplacer les données d’une batterie à l’autre. Les systèmes les plus modernes à grande échelle utilisent cette approche (Vignette, SharePoint, etc.). On parle généralement de différentes étapes “édition” -> “aperçu” -> “livraison”. Cette méthode vous permet de traiter le contenu / config de la même manière que vous traitez le code (dev-> qa-> prod).

Si vous êtes moins paranoïaque, vous pouvez avoir une seule firebase database, mais seulement votre section admin est disponible sur les serveurs de “modification”. Je veux dire, seuls les scripts / fichiers d’édition sont placés sur le serveur de assembly.

Naturellement, la phase d’édition ne doit être disponible que sur un intranet local et / ou en utilisant un VPN.

Cela peut sembler exagéré et ne constitue peut-être pas la solution la plus simple pour tous les cas d’utilisation, mais c’est certainement la manière la plus robuste de faire les choses.

Notez que des choses comme “avoir des mots de passe admin forts” sont agréables, mais laissez votre administrateur ouvert à tous les types d’atsortingbuts.

Cela dépend beaucoup du type de données que vous souhaitez protéger (exigences légales et autres).

  • Beaucoup de suggestions concernent l’authentification. Je pense que vous devriez simplement envisager d’utiliser l’authentification OpenId / Facebook comme identifiant. (Ils dépenseront probablement plus de ressources sur la sécurité de l’authentification que vous)

  • Enregistrez les modifications ainsi que la mise à jour des valeurs dans la firebase database. De cette façon, vous pouvez annuler les modifications depuis l’utilisateur X ou entre les dates X et Y.

Je n’ai pas remarqué que quelqu’un mentionne le stockage / validation du mot de passe administrateur. S’il vous plaît s’il vous plaît s’il vous plaît ne stockez pas le PW en texte brut, et même pas quelque chose qui peut être inversé – utilisez quelque chose comme un hash MD5 salé pour que quelqu’un récupère le mot de passe stocké tout ce qui est terriblement utile, à moins qu’ils aient aussi votre projet de sel.

Ajoutez un champ de mot de passe et une question de sécurité que l’administrateur connaîtra, par exemple quel était le nom de votre première petite amie, ou répartissez les questions de manière aléatoire à chaque fois que vous consultez le panneau d’administration.

Peut-être que vous pourriez toujours mettre la section d’administration dans un grand répertoire, par exemple

http://domain.com/sub/sub/sub/sub/sub/index.php

Mais ce n’est pas vraiment bon.

Vous pourriez peut-être inclure une chaîne de requête dans la page d’accueil, par exemple:

http://domain.com/index.php?display=true

Le nom d’utilisateur et le mot de passe apparaissent alors.