Quel est le degré d'assainissement nécessaire pour les services Web qui appellent des procédures stockées ?

Question

Je construis une série de services web en VB.Net

Chacun des services web prend plusieurs valeurs de chaîne, effectue une validation/un traitement, puis appelle une procédure stockée à l'aide de Linq to SQL. Certaines des chaînes contiennent des données utilisateur stockées dans la base de données :

Ces valeurs de chaîne transmises par le service web sont échappées afin d'éviter les guillemets simples, les points-virgules et les différents types d'accolades.

J'appelle la SP en utilisant la méthode datacontext.spname(parameter1, parameter2).

L'objectif est de s'assurer que les services web sont aussi résistants que possible, tout en restant performants.

Ai-je fait suffisamment d'efforts pour prévenir les attaques par injection SQL ?

Answer 1

En général, tout va bien, mais il y a quelques mises en garde :

• Attention aux procs stockées qui utilisent sp_executesql ou exec. Vous pouvez transmettre une requête dans le paramètre et finir par l'exécuter.

• Attention aux sections LIKE des requêtes car elles peuvent être élargies avec % si elles sont assimilées à un paramètre.

• Les champs utilisés dans les pages web peuvent nécessiter un traitement supplémentaire avant d'être envoyés, afin d'éviter les scripts intersites. (dont il faut également se prémunir lors de l'extraction d'informations).

Answer 2

Je sais pertinemment que LINQ to SQL interroge toutes les données envoyées à la base de données via des paramètres SQL, ce qui vous met à l'abri des injections SQL. Je n'en suis pas tout à fait sûr, mais comme LINQ fait abstraction de la procédure stockée, il est très probable qu'il transmette les arguments aux procédures stockées de la même manière.

Qu'est-ce que cela signifie ? Vous n'avez pas à vous soucier de l'assainissement de vos données car LINQ s'en charge. Vous pouvez bien sûr le tester avec une simple attaque de type injection SQL - quelque chose comme une insertion ou une sélection inoffensive.

Answer 3

Si vous utilisez des paramètres, vous n'avez pas besoin d'assainir du tout car les guillemets simples et les autres problèmes d'injection sql sont éliminés pour vous.

C'est probablement une mauvaise idée d'assainir les entrées en fonction des données que vous stockez. Si vous stockez des éléments qui seront intégrés dans une page web et que vous les encodez/assainissez lors de la saisie des données, que se passe-t-il si votre code d'assainissement a un bug ? Vous vous retrouvez avec des données dans la base de données qui causeront des problèmes à la sortie et vous n'avez aucun moyen de les corriger sans une mise à jour de toutes vos données. Il est préférable d'assainir les données au moment de leur sortie, car les corrections apportées au code d'assainissement seront alors appliquées à l'ensemble des données. Vous avez également l'avantage de pouvoir effectuer plus facilement des recherches en SQL si cela vous préoccupe.

Je limiterais le service web à des choses évidentes, les contrôles de nullité et de portée.