Algorithme pour éviter l'injection SQL sur MSSQL Server à partir du code C#?

Question

Quel serait le meilleur moyen d'éviter l'injection SQL sur la plate-forme C# .net.

Veuillez publier une implémentation C# si vous en avez.

Answer 1

Top 10 des choses que nous pouvons faire pour être sûr (Aucun de ceux-ci tout faire.)

1. Adopter l'idée selon laquelle, « Toutes les données sont mal. » Toutes les données, même les données stockées dans la base de données ou sur notre système de fichiers sont suspectes. Pas seulement la saisie de données à partir d'applications en dehors de notre pare-feu comme les chaînes de requête, les champs de formulaire, les cookies, etc. Tout peut être utilisé pour compromettre un système. Ne comptez pas sur la validation côté client de longueurs de champ javascript ou html ou même API Web côté serveur qui utilisent la validation côté client. Utilisez-le pour améliorer la convivialité, mais ne comptez pas sur lui comme seul gardien. Sachez comment les validateurs fournis par les API comme NET fonctionnent. Ne les prenez pas pour acquis. Il y a des façons de les contourner.

2. Effectuez une correspondance positive pour capturer toutes les données au fur et à mesure. Si les données correspondent aux plages de caractères d'une expression régulière, alors c'est bon. Cela empêche les caractères unicodes bizarres dans notre base de données qui pourraient accidentellement délimiter quelque chose en sql ou créer d'autres problèmes comme les attaques Homographic XSS/Phishing. En revanche, la correspondance négative nécessite des listes de tous les mauvais caractères, qui semblent croître tout le temps. C'est une mauvaise approche. La correspondance positive est meilleure. Nous rejetons les mauvaises données, ne les désinfiltrons pas et ne les échappons pas. Dans la mesure du possible, envisagez de filtrer, marquer ou capturer les données de chaîne avec "update", "delete", "drop", "select", "alter", etc. Cela peut ne pas être possible étant donné la nature du chaîne. "1212 Lemondrop Ln", "Waltersburg, PA" et "Table Rock, NE" sont des champs d'adresse valides. Exécuter une analyse quotidienne de toutes les données de la table pour les champs qui correspondent à l'un de ceux-ci pourrait révéler des attaques retardées ou des vulnérabilités. Aussi la journalisation, l'interdiction d'IP, les alertes par email, etc. peuvent être utilisées car les données arrivent.

3. Utilisez les procédures stockées et/ou les requêtes paramétrées autant que possible. Évitez SQL dynamique à la fois dans le code client DB et en SQL. (Évitez les instructions exec avec du code dynamique avec des sections externes dans vos procédures stockées !!!) Le paramétrage va échapper aux terminateurs de chaîne comme l'apostrophe, les longueurs de champs de saisie et la vérification de type. Nous ne pouvons pas toujours compter sur les APIs qui fournissent le paramétrage pour être parfait, mais ils sont écrits par des personnes beaucoup plus conscientes des idiosyncrasies de base de données que la plupart d'entre nous. Assurez-vous qu'aucun code parasite ne se trouve dans un répertoire Web lisible/exécutable à l'échelle mondiale. S'il ne fait pas partie du site actif, archivez-le dans un endroit sûr et supprimez-le de la vue publique. Idem pour les procédures stockées inutilisées.

4. Restez à jour sur les API de base de données. Certaines méthodes d'exécution des instructions SQL dans certaines API ne sont pas aussi sécurisées que d'autres. Stockez les mots de passe en toute sécurité avec un cryptage unidirectionnel. De cette façon, une table de vidage des noms d'utilisateur et mots de passe devrait toujours garder les gens dehors.

5. Renforcez le serveur de toutes les manières habituelles. Par exemple, lorsque cela est possible, accordez le moins de privilèges possible aux tables de base de données. Limitez l'accès aux comptes de base de données du serveur Web strictement aux tables en question. Utilisez en lecture seulement autant que possible. Créez plusieurs comptes qui créent une division entre les droits d'accès du trafic public et interne/de confiance.

6. Capturer les erreurs avec élégance. Cela vaut pour tout le code, pas seulement pour le code qui utilise la base de données. Cependant, les attaques par injection SQL ne reposent que sur des messages d'erreur. Il est donc souhaitable de cacher autant que possible la base de données au public. Toujours écrire du code qui gère les exceptions ou les ensembles de données vides de manière à révéler le moins possible le type de base de données que nous utilisons, les champs dans nos tables ou le type de requêtes que nous exécutons. Enregistrer les erreurs sur le serveur. Même dans le code autre que la base de données, il est préférable de garder le silence sur les composants tiers, les structures de dossiers, les autres services que nous utilisons, etc. Il est essentiel de donner le moins d'informations possible aux utilisateurs malintentionnés.

Et # 11, toujours revisiter/réviser cette liste. Toujours être à jour. Etre pro-actif. Faites-en une priorité et une exigence immédiates, pas une pensée après.

Answer 2

Aucun algorithme n'est nécessaire. N'utilisez simplement pas de concaténation de chaîne pour générer des instructions SQL. Utilisez plutôt la collection SqlCommand.Parameters. Cela fait toutes les échappées nécessaires de valeurs (telles que le remplacement ' avec '') et s'assure que la commande sera en sécurité parce que quelqu'un d'autre (c'est-à-dire Microsoft) a effectué tous les tests.

par exemple. appeler une procédure stockée:

using (var connection = new SqlConnection("...")) 
using (var command = new SqlCommand("MySprocName", connection)) 
{ 
    command.CommandType = CommandType.StoredProcedure; 
    command.Parameters.AddWithValue("@Param1", param1Value); 
    return command.ExecuteReader(); 
} 

Cette technique fonctionne également pour les instructions SQL en ligne, par ex.

var sql = "SELECT * FROM MyTable WHERE MyColumn = @Param1"; 
using (var connection = new SqlConnection("...")) 
using (var command = new SqlCommand(sql, connection)) 
{ 
    command.Parameters.AddWithValue("@Param1", param1Value); 
    return command.ExecuteReader(); 
}