7
votes

Sécuriser la liste de contrôle d'applications ASP.NET MVC

Je recherche un ensemble de directives ou une liste de contrôle que vous pouvez accéder à la sécurisation d'un site Web public ASP.NET MVC. Je veux juste m'assurer que je ne fais aucun des problèmes évidents et bien connus lors du déploiement d'un site Web.

Merci.


0 commentaires

4 Réponses :


1
votes

i un peu faire ce qui suit;

  1. séparer mes préoccupations. Administrer Dossier d'administration, etc.
  2. [Autoriser] sur toutes les actions qui exiger que vous soyez connecté.
  3. html.encode tous les champs de saisie de données.
  4. ActionResResult crée ([BIND (PREFIX = "", Exclude = "id")] mymodel NewModelObject) <== Exclure les identifiants qui peuvent être utilisés dans une attaque

    Autre que cela ...


0 commentaires

5
votes
  1. comme toujours, assurez-vous de bien vous approprié Encode Sortie - Notez que je suis ici disant codé et non Htmlencode. Si vous émettez contenu sur HTML alors vous voulez utiliser html.encode - cependant si vous êtes sortie à JavaScript puis vous Voulez-vous utiliser un encodage JavaScript une fonction. - Cela vous aidera à faire des scripts de sites croisés (XSS)
  2. Utilisez les aides qui aident à l'encontre des attaques du CSRF lorsque cela est nécessaire (ou peut-être tout au monde)
  3. En fonction de la manière dont vous accédez à votre stockage de données, s'il s'agit d'une base de données SQL, n'oubliez pas de vous protéger contre des injections SQL, que ce soit par des requêtes paramétrées, des procédures stockées, Linq ou sur quoi avez-vous?
  4. Lorsque vous testez - Assurez-vous que vos données de test contiennent une sortie Dodgy (Stuff où un échec à appeler HTML.enCode se révélerait facilement, peut-être via alerte ("Attaque XSS ! "); XSS ici! , Ideme va pour des trucs injectés à JavaScript, faites des erreurs apparaître!)
  5. Lorsque la liaison du modèle Utilisez une approche blanchissante pour les propriétés afin que les utilisateurs ne puissent pas rendre les propriétés de liaison à la liaison qui ne sont pas destinées à être liées!

4 commentaires

J'aime le point 4. Je ne pense pas assez de personnes qui s'appuient sur des testeurs pour faire ces sortes de tests.


Heh Me aussi, assez judicieusement, c'est le genre de chose qui me vint à l'esprit quand je devais penser à quel conseil je donnerais aux autres - je peux maintenant voir que j'ai besoin de faire une réflexion de moi-même sur une partie de cette ...


Oui, je regarde tous ces commentaires pensant que je dois faire exactement la même chose. :)


Heh tu viens de faire ma nuit - content de savoir que je ne suis pas le seul!



1
votes

Les mesures générales ASP.NET

  1. SET DEBUG = FALSE IN WEB.CONFIG
  2. Activer l'erreur personnalisée
  3. crypter vos cookies
  4. Valider toutes les entrées
  5. Activer la validation de la demande
  6. encoder votre sortie

0 commentaires

1
votes

n'utilisez pas la valeur par défaut obtenir sur actions sauf absolument nécessaire. Par exemple, si vous avez un deleteuser action qui n'a pas de [accepter desverbs (httpverbs.post)] dessus, il peut être appelé via xxx < / Pre>

qui sera appelé par «Vues» de quiconque l'image.


4 commentaires

IMO Si un pirate informatique peut injecter une étiquette IMG dans une page, il peut ne pas être difficile pour lui d'injecter JS qui fera un poste à l'URL de suppression. Qu'en penses-tu?


Oui, c'est pourquoi vous suivez les conseils de @ griegs et [Autoriser] des choses sensibles aussi :). [Autoriser] seul ne fonctionnera pas, car un utilisateur peut être connecté (à la plupart des applications) sans visionner la page.


Hmm, je l'ai eu, exposer à obtenir la demande peut conduire à Cross Domain XSRF à travers le domaine.


Ouais comme mentionné que vous voulez certainement combiner ceci (comme dans la nécessité d'un poste, d'une suppression ou d'un autre en-tête que d'obtenir) avec les aides anti-CSRF - en plus de cela, il s'agit d'un conseil solide.