L'injection SQL est toujours un sujet brûlant, en particulier en matière de sécurité Web. À cet égard, je suis intéressé par les étapes à suivre pour empêcher l'injection SQL dans une application Web? En plus de ces étapes normales, y a-t-il autre chose que les gens font au-delà de la normale pour l'empêcher?
Déjà de très bonnes réponses à cette question, mais j'aimerais en mentionner quelques-unes:
Ceci est uniquement à des fins de prévention et je n'ai pas pris durcissement du serveur sql en compte. Il existe cependant de nombreuses similitudes.
Des défenses supplémentaires au cas où vous seriez déjà vulnérable à l'injection seraient:
Instructions préparées, requêtes paramétrées, échappant à toutes les entrées utilisateur, pour un bon début, voir http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet.
La principale défense est de n'utiliser que des API qui échappent en toute sécurité aux requêtes de base de données - on les appelle généralement des instructions paramétrées ou préparées. Celles-ci ne peuvent pas être utilisées dans tous les cas (par exemple lorsqu'un identifiant SQL tel que le nom de la table ou de la colonne est fourni au moment de l'exécution), mais c'est la meilleure approche dans la mesure du possible (la majorité des cas).
Remarque - cela peut conduire à l'insertion de données nuisibles dans la base de données, alors soyez conscient de cela lorsque vous utilisez ces données ailleurs dans l'application
La deuxième défense consiste à adopter une approche de fuite . Il s'agit de l'approche «remplacer un guillemet simple par deux guillemets». Si vous devez procéder de cette manière, vous devez échapper à chaque caractère potentiellement dangereux , ce qui signifie plus que des guillemets simples dans certains cas. Je vous conseillerais d'utiliser une bibliothèque de niveau supérieur telle que OWASP ESAPI si possible pour le faire pour vous, ou de lire attentivement la feuille de triche d'injection SQL OWASP (référencée ci-dessus).
La principale étape pour protéger l'application Web contre l'injection SQL est de nettoyer correctement tout utilisateur. input (en particulier l'entrée utilisée dans les requêtes SQL). Dans certains langages / frameworks, il existe des méthodes standard pour gérer ces valeurs - par exemple en utilisant des requêtes paramétrées au lieu de composer la requête en joignant des valeurs de chaîne.
Du côté des développeurs Web, il faut attirer l'attention sur ce que Weber a déjà mentionné.
De plus, un pare-feu de base de données pourrait être mis en place, comme GreenSQL: http://www.greensql.net/. Cela fonctionne comme un proxy entre votre application et l'entrée utilisateur, surveille ce qui doit être transmis, etc. Cependant, cela entraîne un temps de réponse accru.
J'enseigne la sécurité informatique dans les écoles polytechniques. Souvent, pour les étudiants, ils ont une certaine confusion sur les termes utilisés pour l'injection SQL, alors laissez-moi essayer de clarifier.
Dans le contexte d'une application Web comme Facebook,
L'injection SQL se produit lorsque le l'utilisateur Web normal entre le code SQL dans les champs de données Par exemple,
'OR' 1 '=' 1 dans les zones de texte d'un formulaire de connexion. La meilleure personne pour empêcher l'injection SQL, c'est le développeur Web, alias la personne chargée d'écrire le code de l'application Web pour lire / écrire des données dans la base de données.
Le moyen le plus simple d'empêcher l'injection SQL par le développeur Web est d'utiliser requêtes paramétrées.
Les instructions préparées et les requêtes paramétrées signifient la même chose.
J'utiliserai les requêtes paramétrées à partir de maintenant.
Les requêtes paramétrées se réfèrent à la manière dont le code SQL est défini pour la première fois, puis les données sont placées dans les paramètres appropriés.
Par exemple dans .Net
Mettre à jour le jeu ʻusers` set ` name` = @name où ʻid` = @id les paramètres @name et @id sont les données. Le reste est le code SQL.
Gardez à l'esprit que les requêtes paramétrées sont généralement mais pas toujours effectuées au niveau du code de l'application Web.
Il y a 2 façons d'écrire des requêtes paramétrées.
Donc dans un certain sens, oui , les procédures stockées sont une forme de requêtes paramétrées.
Il existe d'autres moyens d'empêcher l'injection SQL en échappant des caractères spéciaux comme des guillemets simples. Par exemple, en PHP, vous pouvez utiliser mysql_real_escape_string qui met essentiellement des barres obliques avant les guillemets simples.
Ce n'est pas idéal à cause de problèmes avec% et soulignement pour l'opérateur LIKE dans certaines bases de données comme MySQL. voir ce pdf pour plus de détails.
Pour faire court, toutes les options suggérées concernent la désinfection (nettoyage) des entrées utilisateur pour nettoyer le code SQL.
Le meilleur moyen est d'utiliser des requêtes paramétrées en fonction du langage de programmation utilisé.
Fin de l'histoire.
Utilisez des API d'accès aux données décentes qui permettent de faire facilement ce qu'il faut, en toute sécurité.
Voici ActiveRecord v3:
# basic usage @ user = User. où (: username = > 'joe@example.com'). first # avec un fragment de chaîne SQL, mais en utilisant des paramètres @ projects = @ user.projects.where ('status =?', params [: status])