Personnellement, j'essaie d'écrire du code ASP.NET sécurisé. Cependant, je suis devenu assez paranoïaque à propos du code que j'écris, car je travaillais pour un Registrar (cibles de haute fraude). Existe-t-il des fonctions ASP.NET que je devrais examiner avec un examen extrême (autre que l'accès SQL - j'en connais assez pour ne pas faire de SQL dynamique).Quelles commandes ASP.NET peuvent entraîner un code non sécurisé?
Ceci est un excellent article MSDN: Security Practices: ASP.NET 2.0 Security Practices at a Glance.
Extrait:
Comment éviter cross site scripting
entrée Valider et encode la sortie. Limitez les entrées en les validant pour le type, la longueur, le format et la plage . Utilisez la méthode HttpUtility.HtmlEncode pour sortie de codage si elle contient l'entrée de l'utilisateur, telle que l'entrée du formulaire champs, chaînes de requête et cookies ou provenant d'autres sources, telles que des bases de données. Ne faites jamais que renvoyer l'entrée à l'utilisateur sans valider et/ou encoder les données . L'exemple suivant montre comment pour coder un champ de formulaire.
Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));Si vous retournez les chaînes d'URL qui contiennent entrée au client, utilisez la méthode HttpUtility.UrlEncode pour encoder ces chaînes d'URL, comme indiqué ici.
Response.Write(HttpUtility.UrlEncode(urlString));Si vous avez des pages qui ont besoin d'accepter une gamme d'éléments HTML, tels que par une sorte de riche saisie de texte champ, vous devez désactiver la validation de la demande ASP.NET pour la page.
Activer erreurs personnalisées pour garder vos erreurs
<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
entrée utilisateur Ne faites jamais confiance. Ne supposez jamais que la validation côté client empêchera les mauvaises données d'entrée. Assurez-vous toujours que ValidateRequest = "true" et EnableEventValidation = "true" dans votre fichier web.config:
Merci Mitch! J'apprécie votre réponse, cependant ... la réponse que vous avez donnée me porte à croire que c'est une contre-mesure pour le code SQL non échappé ou pour le code non-DB. Raison d'être que tout est basé sur le stockage d'entrée des utilisateurs. En outre, les choses URLEncoding ont tendance à "sur-encoder" dans mon expérience, car elles doivent s'abonner à des règles d'encodage d'URL (très strictes). Aussi, avec ASP.NET j'essaye d'éviter toute Response.Writes. Je trouve que les contrôles de code ASP.NET-infront donnent une meilleure conscience structurelle à mon HTML. Je vous donnerai +1 cependant, parce que vous êtes techniquement valide :) – Thunder3