2
J'ai un site ASP.NET MVC avec une application d'administration de site privé sécurisée avec l'autorisation ASP.NET SQL. Je dois ajouter un identifiant pour le site public afin de permettre aux visiteurs de s'inscrire à un compte. Je pense que je devrais créer un espace de stockage totalement séparé pour le site public, plutôt que d'étendre la base de données utilisateur existante et de compter sur des rôles pour empêcher les utilisateurs publics de se retrouver dans le back-office. Y a-t-il une raison de ne pas le faire?Devrais-je étendre la sécurité ASP.NET pour un site public?
Hrm, je ne sais pas à ce sujet. Une partie de moi dit, si le site est vulnérable à l'injection SQL, j'ai des problèmes beaucoup plus importants, et c'est juste un contrôle des dégâts. – Paul
@Paul vous devriez essayer d'exploiter les vulnérabilités d'injection sql, et peut-être que cette partie disparaîtra. C'est ce qu'on appelle la défense en profondeur, vous pourriez ne pas être en mesure de trouver tout ce que vous devez planifier pour le pire. C'est pourquoi vous hash mots de passe. Si vous avez correctement configuré vos permissions sql, le plus qu'un attaquant peut obtenir est un select supplémentaire. L'exécution de plusieurs requêtes et l'accès à cmd.exe ne devraient pas être possibles, mais c'est par défaut. – rook
Ah, "Défense en profondeur" est exactement ce que je cherchais. Donc, c'était mon plan original mais maintenant j'ai l'impression que je peux le défendre intelligemment. Après un peu de lecture, il semble que Défense en profondeur se réfère à la protection contre différents vecteurs d'attaque, pas la même attaque pénétrant la première couche de défense. Je dirais que la raison pour laquelle vous hachez les mots de passe est principalement d'empêcher les employés malveillants de voler les comptes des utilisateurs - mais cette même logique fonctionne pour mon cas. – Paul