Selon le rapport OWASP Top Ten de 2021, un document de référence reconnu dans le domaine de la sécurité des applications web, les injections SQL arrivent en troisième position des risques les plus critiques. Ce rapport, disponible sur OWASP Top 10: Injection, souligne la gravité de cette menace et la nécessité de mettre en place des mesures de protection efficaces.
.png)
Une injection SQL se produit lorsqu'un attaquant malveillant parvient à insérer du code SQL non autorisé dans une requête envoyée à une base de données. Ce code, dissimulé au sein des entrées utilisateur, peut alors être exécuté par la base de données, provoquant des actions indésirables comme le vol de données confidentielles, la modification ou la suppression d'informations sensibles, ou encore la perturbation du fonctionnement de l'application.
Que doit-on rechercher pour empêcher l’injection SQL ?
Une application est vulnérable aux attaques lorsque :
- Les données fournies par l'utilisateur ne sont pas validées, filtrées ou nettoyées par l'application.
- Les requêtes dynamiques ou les appels non paramétrés sans échappement sensible au contexte sont utilisés directement dans l'interpréteur.
- Les données hostiles sont utilisées dans les paramètres de recherche de mappage objet-relationnel (ORM) pour extraire des enregistrements supplémentaires et sensibles.
- Les données hostiles sont directement utilisées ou concaténées. Le SQL ou la commande contient la structure et les données malveillantes dans les requêtes dynamiques, les commandes ou les procédures stockées.
Les injections les plus courantes sont SQL, NoSQL, commande OS, mappage objet-relationnel (ORM), LDAP et Expression Language (EL) ou Object Graph Navigation Library (OGNL). Le concept est identique pour tous les interpréteurs.
Avant de plonger dans les techniques de prévention, il est crucial de comprendre comment les injections SQL fonctionnent.
Les attaquants peuvent exploiter des entrées utilisateur non validées pour injecter du code SQL malveillant dans une requête. Par exemple, si un utilisateur peut saisir une valeur dans un champ de recherche et que cette valeur est directement insérée dans une requête SQL sans validation (par exemple, set query = "SELECT * FROM Company.Accounts WHERE custID="_custID), un attaquant pourrait entrer une chaîne de caractères comme "1 union select * from Company.Accounts pour obtenir des détails sur tous les comptes.
Heureusement, InterSystems IRIS fournit plusieurs mécanismes pour prévenir les injections SQL :
- Utilisation de paramètres préparés. Les paramètres préparés sont l'une des méthodes les plus efficaces pour prévenir les injections SQL. Ils séparent la structure de la requête des valeurs d'entrée, empêchant les attaquants d'injecter du code SQL malveillant. Par example le code
SET statement = ##class(%SQL.Statement).%New()
DO statement.%Prepare("SELECT * FROM Library.Book where ID = ?")
SET rs = statement.%Execute("3 union select * from library.Book")
DO rs.%Display()ne retournera rien.
.png)
Tandis que
SET statement = ##class(%SQL.Statement).%New()
DO statement.%Prepare("SELECT * FROM Library.Book where ID = ?")
SET rs = statement.%Execute("3")
DO rs.%Display()retournera l'info :
.png)
- Validation des entrées utilisateur. Valider les entrées utilisateur avant de les insérer dans des requêtes SQL est une autre mesure importante de prévention. Utilisez des expressions régulières ou des fonctions de validation appropriées pour vérifier la validité des données. Par exemple, si on utilise le code postal comme paramètre de la requête, on doit vérifier qu'il ne contient que des caractères numériques et qu'il comporte 5 caractères en general:
SET statement = ##class(%SQL.Statement).%New()
DO statement.%Prepare("SELECT * FROM Post.Address WHERE ZIP = ?")
READ "Enter ZIP code: ", zip
if zip?5N {
SET rs = statement.%Execute(zip)
DO rs.%Display()
}Ce code retournera
.png)
- Utilisation de patterns dans les descriptions de class. Il est proche du point précédent, mais permet de vérifier l'entrée lors de l'ajout de nouvelles instances.
- Filtrage des caractères spéciaux
- Filtrer les caractères spéciaux qui peuvent être utilisés pour injecter du code SQL peut également aider à prévenir les attaques. Utilisez des fonctions de filtrage appropriées pour supprimer ou échapper aux caractères potentiellement dangereux.
- Utilisation de procédures stockées
- Les procédures stockées sont des objets de base de données qui encapsulent un ensemble d'instructions SQL. En utilisant des procédures stockées, vous pouvez centraliser la logique de votre application et réduire le risque d'injections SQL.
- Mise à jour régulière des composants logiciels
- Assurez-vous de mettre à jour régulièrement InterSystems IRIS et les composants logiciels connexes pour bénéficier des derniers correctifs de sécurité.
Pour conclure, les injections SQL sont une menace sérieuse pour la sécurité des applications Web. En suivant les méthodes de prévention décrites dans cet article, vous pouvez réduire considérablement le risque d'attaques d'injection SQL dans vos applications InterSystems IRIS. Il est important de combiner plusieurs techniques de prévention pour obtenir une protection maximale.
Open Exchange
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)