2009-05-21 9 views
1

Comment gérez-vous l'entrée de l'utilisateur (unicode) dont vous avez besoin pour être limité à un certain ensemble de valeurs, et vous voulez réduire le risque pour les applications que vous transmettez les données à plus tard dans la ligne. Par exemple, si je devais stocker les données dans SQL, je voudrais supprimer toute chance d'une injection SQL. Si je devais l'envoyer via le protocole HTTP, je voudrais m'assurer qu'il ne déforme pas la requête, etc.Comment gérer des données erronées?

Je suppose que je demande s'il existe une méthode générique pour la désinfection des données?

Répondre

1

Chaque interface a ses propres problèmes en matière de moyens de compromettre le système. Si vous voulez jouer en toute sécurité, vous devrez adapter les validations aux problèmes et/ou aux menaces qui sont pertinents dans le contexte actuel.

Si une certaine zone de texte dans une interface utilisateur doit être utilisée pour l'entrée numérique, assurez-vous que l'utilisateur ne peut pas taper (ou coller) quoi que ce soit de non numérique. Si un certain contrôle est utilisé pour collecter une date de l'utilisateur, validez que la valeur donnée est bien une date valide (peut-être qu'elle devrait même tomber dans une certaine plage, validez-la aussi).

Assurez-vous d'encoder tout ce qui est passé en tant que valeur de chaîne de requête dans une requête http. Utilisez les procédures stockées et transmettez les valeurs en tant que paramètres.

Et ainsi de suite. Il n'y a pas de repas gratuit, malheureusement.

+0

Je pense que pour résumer cette réponse, (1) assurez-vous que les données que vous obtenez d'un utilisateur est valide lorsque vous l'obtenez (par exemple, les nombres); et (2) encoder des données quand vous allez l'embarquer/l'afficher/l'envoyer, ainsi vous connaissez les exigences du format (par exemple, urlencode dans les URLs, requêtes paramétrées dans SQL, & -codage dans html) –

0

En cas d'enregistrement dans la base de données, c'est très simple. Utilisez simplement des paramètres (objets DbParameter) - ils vous protégeront de l'injection SQL et ajouteront des symboles d'échappement si nécessaire.

Le code peut ressembler à ceci:

OleDbConnection cn = new OleDbConnection(strConn); 
cn.Open(); 
strSQL = "INSERT INTO customers (Name) VALUES (@Name)"; 
OleDbCommand cmd = new OleDbCommand(strSQL, cn); 
cmd.Parameters.Add("@Name", "John O'Brian"); 
cmd.ExecuteNonQuery();
0

Comme nightcoder a suggéré, les paramètres sont la façon d'éviter l'injection SQL. Si vous utilisez SQL, pensez à utiliser l'espace de noms SqlClient car il est plus efficace que son homologue OleDb et a été créé spécifiquement pour SQL Server 7 et versions ultérieures.

En utilisant exemple ci-dessus de nightcoder:

SqlConnection cn = new SqlConnection(strConn); 
cn.Open(); 
strSQL = "INSERT INTO customers (Name) VALUES (@Name)"; 
SqlCommand cmd = new SqlCommand(strSQL, cn); 
cmd.Parameters.Add(new SqlParameter("@Name", SqlDbType.Varchar)).Value = "John O'Brian"; 
cmd.ExecuteNonQuery(); 

Quelque chose à garder à l'esprit à propos de l'espace de noms SqlClient est que si vous écrivez pour les systèmes plus anciens (Win98), il peut y avoir des problèmes de compatibilité, ce qui OldDBxxx mieux choix.

À la votre!

Questions connexes