Comment prévenir les injections en ASP / VBScript?

Question

Quels sont les meilleurs moyens (ou du moins les moyens les plus courants) en ASP (VBScript) pour le traitement des entrées? Mes principales préoccupations sont les injections HTML / JavaScript & Amp; Injections SQL. Existe-t-il un équivalent de PHP htmlspecialchars ou addslashes, etc.? Ou dois-je le faire manuellement avec quelque chose comme une fonction de remplacement de chaîne?

Answer 1

La ligne de fond est la suivante:

1. Toujours saisir le code HTML de l'utilisateur avant de l'écrire sur votre page. Server.HTMLEncode() le fait pour vous.
2. Utilisez toujours des requêtes paramétrées pour vous connecter à une base de données. Les objets ÀDODB.Command et ADODB.CommandParameter sont le bon choix ici.
3. Utilisez toujours l'utilitaire URLScan et le verrouillage IIS sur le serveur IIS qui affiche la page, à moins qu'il s'agisse d'une version 6 ou supérieure, qui ne nécessite plus ces outils.

Si vous vous en tenez aux points 1 et 2 servilement , je ne peux penser à rien qui puisse mal tourner.

La plupart des vulnérabilités proviennent d’un encodage incorrect de l’entrée utilisateur ou de la construction de chaînes SQL à partir de celle-ci. Si, pour une raison quelconque, vous arrivez au point où la saisie de l'utilisateur par le codage HTML est un obstacle, vous avez constaté un défaut de conception dans votre application.

Answer 2

J'ajouterais à la liste Tomalaks un autre point.

Évitez d'utiliser la concaténation des valeurs de champ dans le code SQL. Autrement dit, dans certains cas, une procédure stockée peut générer du code SQL dans une chaîne pour une exécution ultérieure. C’est parfait sauf si une valeur de champ textuel est utilisée dans le cadre de sa construction.

Un paramètre de commande peut protéger le code SQL conçu pour entrer une valeur contre le piratage lors de l'exécution de SQL non souhaité, mais il permet à ce SQL non désiré de devenir des données dans la base de données. C'est une vulnérabilité de premier niveau. Une vulnérabilité d'injection de second niveau existe si la valeur du champ est ensuite utilisée dans une concaténation de chaîne SQL au sein d'une procédure stockée.

Une autre considération est qu’il s’agit simplement d’une protection minimale. Tout ce qu'il fait est de rendre les tentatives d'attaque inoffensives. Toutefois, dans de nombreux cas, il peut être préférable d’ajouter à cela un système empêchant toute saisie de données de ce type et / ou altérant les administrateurs d’une éventuelle attaque par injection.

C’est là que la validation des entrées devient importante. Je ne connais aucun outil qui le fasse pour vous, mais quelques expressions régulières simples pourraient vous aider. Par exemple, & Quot; & Lt; \ w + & Quot; détecterait la tentative d’inclusion d’une balise HTML dans le champ.