2009-04-03 8 views
3

Je crée une interface utilisateur de programme Asp.Net dans laquelle les utilisateurs peuvent parcourir et modifier des informations dans une base de données. Pour cette raison, ils doivent être en mesure d'utiliser toutes les formes de caractères, mais j'ai toujours besoin de garder le programme HTML et SQL lui-même sécurisé. Pour cette raison, j'utilise une méthode auto-construite qui remplace les caractères dangereux tels que '<' etc avec leurs codes html alors qu'ils sont manipulés en dehors d'une zone de texte (émis sur le chargement de la page afin qu'ils n'aient aucune fonctionnalité dans Là).Asp.Net Validaterequest False

Maintenant mon dilemme: Pour être en mesure de le faire, je dois désactiver le paramètre Validaterequest selon le sujet, le programme émettra une plainte. Quelles sont les conséquences possibles de la mise à False?

La requête SQL est parametirized déjà, et je filtrer les marques suivantes seulement:

& # < > " ’ % @ = 

Question: Je suis quitte le programme ouvert pour les menaces, même si je manipule les caractères ci-dessus? Fondamentalement, il s'agit d'une application intranet où seulement quelques personnes pourront accéder au programme. Néanmoins, les informations auxquelles il accède sont assez importantes, de sorte que même les mésaventures involontaires devraient être évitées. Je n'ai littéralement aucune idée de ce que fait Validaterequest.

Modifier: Très bien, merci pour les réponses. Je vais aller avec ça alors comme initialement prévu.

Répondre

4

Les choses principales Validate Request recherchent sont <et> caractères, pour vous empêcher d'ouvrir votre site aux utilisateurs malveillants d'affichage de script et/ou HTML à votre site.

Si vous êtes satisfait du code que vous avez supprimé le balisage HTML, ou si vous n'affichez pas les données sauvegardées sur le site Web sans traitement, alors cela devrait fonctionner.

2

La validation de la saisie utilisateur en remplaçant les caractères spéciaux entraîne généralement plus de problèmes et ne résout pas vraiment le problème. Tout dépend de ce que l'utilisateur entrée, parfois ils ont besoin des caractères spéciaux comme

& # < > " ’ % @ = 

penser à des utilisateurs avertis peuvent toujours utiliser xp_ commande ou même utiliser la fonction CONVERT() pour faire un ASCII/attaque automatisée binaire. Tant que vous avez paramétré toutes les entrées, ça devrait aller.

1

Je pense que le problème ne concerne pas seulement les attaques par injection SQL, mais aussi les attaques par Cross Site Scripting et JS. Pour éviter cela, vous ne pouvez pas compter uniquement sur des requêtes paramétrées, vous devriez faire une "sanitisation" du code html que l'utilisateur envoie! peut-être un outil comme html bien rangé pourrait aider.

Questions connexes