Quelles sont les meilleures pratiques pour sécuriser la section d'administration d'un site Web? [fermé]

J'aimerais savoir ce que les gens considèrent comme les meilleures pratiques pour sécuriser les sections d'administration des sites Web, en particulier du point de vue de l'authentification / de l'accès.

Bien sûr, il y a des choses évidentes, telles que l'utilisation de SSL et la journalisation de tous les accès, mais je me demande où au-dessus de ces étapes de base les gens considèrent que la barre est définie.

Par exemple:

• Comptez-vous simplement sur le même mécanisme d'authentification que celui 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 rendre la section d'administration non découverte? (ou rejetez-vous toute la chose `` obscurité '')

Jusqu'à présent, les suggestions des répondants incluent:

• Introduisez une pause artificielle côté serveur dans chaque vérification de mot de passe administrateur pour éviter les attaques par force brute [Developer Art]
• Utilisez des pages de connexion distinctes pour les utilisateurs et les administrateurs utilisant la même table de base de données (pour empêcher XSRF et le vol de session d'accorder l'accès aux zones d'administration) [Thief Master]
• Pensez également à ajouter l'authentification native du serveur Web à la zone d'administration (par exemple via .htaccess) [Thief Master]
• Pensez à bloquer l'adresse IP des utilisateurs après un certain nombre d'échecs de tentatives de connexion administrateur [Thief Master]
• Ajouter un captcha après l'échec des tentatives de connexion administrateur [Thief Master]
• Fournir des mécanismes tout aussi puissants (en utilisant les techniques ci-dessus) pour les utilisateurs et les administrateurs (par exemple, ne pas traiter les administrateurs spécialement) [Lo'oris]
• Considérez l'authentification de deuxième niveau (par exemple, les certificats clients, les cartes à puce, l'espace de cartes, etc.) [JoeGeeky]
• N'autorisez l'accès que depuis des adresses IP / domaines de confiance, ajoutez une vérification au pipeline HTTP de base (via par exemple HttpModules) si possible. [JoeGeeky]
• [ASP.NET] Verrouiller IPrincipal & Principal (les rendre immuables et non énumérables) [JoeGeeky]
• Federate Rights Elevation - par exemple, envoyez 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 les rôles, définissez des droits pour des actions indicatives par administrateur [JoeGeeky]
• Limitez la création d'administrateurs - par exemple, les administrateurs ne peuvent pas modifier ou créer d'autres comptes d'administrateur. Utilisez pour cela un client «superadmin» verrouillé. [JoeGeeky]
• Considérez les certificats SSL côté client ou les télécommandes de type RSA (jetons électroniques) [Daniel Papasian]
• Si vous utilisez des cookies pour l'authentification, utilisez des cookies séparés pour les pages d'administration et normales, en mettant par exemple la section d'administration sur un domaine différent. [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 des tickets d'authentification / session lors du déplacement entre les contextes d'administration / d'utilisation normale du site Web [Richard JP Le Guen]

Ce sont toutes de bonnes réponses ... J'aime généralement ajouter quelques couches supplémentaires pour mes sections administratives. Bien que j'aie utilisé quelques variantes sur un thème, elles incluent généralement l'un des éléments suivants:

• Authentification de deuxième niveau : cela peut inclure les certificats clients (ex. X509 certificats), les cartes à puce, les espaces de cartes, etc.
• Restrictions de domaine / IP : dans ce cas, seuls les clients provenant de domaines approuvés / vérifiables; comme 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 de confiance afin que leur session soit vérifiable et est 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 des modules HTTP, ce qui empêchera votre application de recevoir des requêtes si les contrôles de sécurité ne sont pas satisfaits.
• Autorisation IPrincipal et principale verrouillée : La création de principes personnalisés est une pratique courante, même si une erreur courante est de les rendre modifiables et / ou des droits énumérables. Bien que ce ne soit pas seulement un problème d'administration, c'est plus important car c'est ici 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 directeur.
• Fédérer l'élévation des droits : lorsqu'un compte reçoit un certain nombre de droits, tous les administrateurs et le responsable de la sécurité sont immédiatement informés par e-mail. Cela garantit que si un attaquant élève des droits, nous le savons immédiatement. Ces droits tournent généralement autour des droits privilégiés, des droits de voir des informations protégées par la confidentialité et / ou des informations financières (par exemple les cartes de crédit).
• Émettez des droits avec parcimonie, 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 entourer de vrais comportements fonctionnels. Les approches typiques de la sécurité basée sur les rôles (RBS) ont tendance à avoir une mentalité de groupe . Du point de 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 (par exemple, créer un utilisateur, autoriser l'utilisateur, élever / révoquer les droits d'accès, etc.)). Cela peut avoir un peu plus de frais généraux en termes d'administration, mais cela vous donne la flexibilité de n'attribuer que les droits qui sont réellement nécessaires au plus grand groupe d'administrateurs. Si l'accès est compromis au moins, ils peuvent ne pas obtenir tous les droits. J'aime envelopper cela dans les autorisations CAS (Code Access Security) prises 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 gérer la modification d'autres comptes d'administrateur ou faire d'un utilisateur un administrateur. Cela ne peut être fait que via 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 les administrateurs, par exemple un forum, j'utiliserais des connexions séparées qui utilisent la même base de données d'utilisateurs. Cela garantit que XSRF et le vol de session ne permettront pas à l'attaquant d'accéder aux zones administratives.

De plus, si la section admin se trouve dans un sous-répertoire séparé, sécuriser celui-ci avec l'authentification du serveur Web (.htaccess dans Apache par exemple) peut être une bonne idée - alors quelqu'un a besoin à la fois de ce mot de passe et du mot de passe utilisateur.

Obscurcir le chemin d'administration n'apporte presque aucun gain de sécurité - si quelqu'un connaît des données de connexion valides, il est probablement également capable de trouver le chemin de l'outil d'administration puisqu'il l'a hameçonné ou vous a enregistré au clavier ou l'a obtenu via l'ingénierie sociale (ce qui révélerait probablement le chemin, aussi).

Une protection par force brute telle que le blocage de l'adresse IP de l'utilisateur après 3 échecs de connexion ou la demande d'un CAPTCHA après un échec de connexion (pas pour la première connexion car c'est juste extrêmement ennuyeux pour les utilisateurs légitimes) peut également être utile.

• Je rejette l'obscurité
• Utiliser deux systèmes d'authentification au lieu d'un est excessif
• La pause artificielle entre les tentatives doit également être faite pour les utilisateurs
• Le blocage des adresses IP des tentatives infructueuses doit également être effectué pour les utilisateurs
• Les utilisateurs doivent également utiliser des mots de passe forts
• Si vous considérez les captcha comme corrects, devinez quoi, vous pouvez également les utiliser pour les utilisateurs

Oui, après l'avoir écrite, je me rends compte que cette réponse pourrait se résumer comme un "rien de spécial pour la connexion administrateur, ce sont toutes des fonctionnalités de sécurité qui devraient être utilisées pour toute connexion".

Si vous n'utilisez qu'un seul identifiant pour les utilisateurs qui ont à la fois des privilèges d'utilisateur normal et des privilèges d'administrateur, régénérez leur identifiant de session (que ce soit dans un cookie, un paramètre GET ou autre ...) en cas de changement de niveau de privilège ... à tout le moins.

Donc, si je me connecte, fais un tas de trucs utilisateur normaux, puis visite une page d'administration, régénère mon ID de session. Si je passe ensuite d'une ou plusieurs pages d'administration à une page utilisateur normale, régénère à nouveau mon identifiant.

Ayez un bon mot de passe administrateur.

Pas "123456"mais une séquence de lettres, de chiffres et de 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 éviter les attaques par force brute.

Voici quelques autres éléments à considérer:

1. Une option à considérer, en particulier si vous gérez les ordinateurs de l'administrateur ou s'ils sont techniquement compétents, consiste à utiliser quelque chose basé sur des certificats SSL pour l'authentification client. Les télécommandes RSA et autres peuvent également être utilisées pour plus de sécurité.
2. Si vous utilisez des cookies - peut-être pour un jeton d'authentification / de 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 posés à votre site en volant des cookies, soit par compromis de couche 1/2 ou XSS. Cela peut être fait facilement en faisant en sorte que la partie admin soit sur un nom d'hôte ou un domaine différent et en définissant le drapeau sécurisé avec le cookie.
3. La restriction par IP peut également être intelligente, et si vous avez des utilisateurs sur Internet, vous pouvez toujours le faire, s'il existe un VPN de confiance auquel ils peuvent adhérer.

Nous utilisons Windows Authenticationpour l'accès administrateur. C'est le moyen le plus pratique de protéger les zones d'administration tout en gardant l'authentification distincte de ce qui s'applique aux utilisateurs finaux en général. L'administrateur système gère les informations d'identification d'accès de l'utilisateur Admin et applique les stratégies de mot de passe sur le compte d'utilisateur de domaine.

La manière stricte est d'avoir deux "fermes" différentes complètes comprenant des bases de données, des serveurs et tout et de déplacer les données d'une ferme à l'autre. La plupart des systèmes modernes à grande échelle utilisent cette approche (Vignette, SharePoint, etc.). Il est normalement désigné comme ayant différentes étapes «étape d'édition» -> «étape de prévisualisation» -> «étape de livraison». Cette méthode vous permet de traiter le contenu / la configuration 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 base de données mais uniquement votre section admin disponible sur les serveurs "édition". Je veux dire, ne placez que les scripts / fichiers d'édition sur le serveur d'édition.

Naturellement, l'étape d'édition ne devrait être disponible que sur un intranet local et / ou en utilisant un VPN.

Cela peut sembler un peu exagéré et peut ne pas être 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 d'administrateur forts» sont bien, mais laissez votre administrateur ouvert à toutes sortes d'attraits intelligents.

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 connexion. (Ils dépenseront probablement plus de ressources sur la sécurité d'authentification que vous)

• Enregistrez les modifications et mettez à jour les valeurs dans la base de données. De cette façon, vous pouvez annuler les modifications de l'utilisateur X ou entre les dates X et Y.

Je n'ai remarqué que personne mentionnait le stockage / la validation du mot de passe administrateur. Veuillez s'il vous plaît ne pas stocker le PW en texte brut, et de préférence pas même quelque chose qui peut être inversé - utilisez quelque chose comme un hachage MD5 salé pour qu'au moins si quelqu'un récupère le "mot de passe" stocké, il n'a pas quelque chose de terriblement utile, à moins qu'ils n'aient également votre plan de sel.

Ajoutez un champ de mot de passe et une question de sécurité que l'administrateur saura, par exemple quel était le nom de votre première petite amie, ou aléatoirement les questions à chaque fois que vous consultez le panneau d'administration.

Peut-être pourriez-vous toujours mettre la section 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 hah.

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

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

Quand c'est le cas, le champ du nom d'utilisateur et du mot de passe apparaîtra.