Préface
Si vous avez lu nos précédents articles , nous abordons dans deux articles les problèmes de sécurité des sites Web et des applications Web. Pour trop d’entreprises, ce n’est qu’après Une faille de sécurité s’est produite qui fait que les meilleures pratiques en matière de sécurité Web deviennent une priorité. Au cours de mes années en tant que professionnel de la sécurité informatique, j’ai constaté maintes et maintes fois à quel point le monde des problèmes de sécurité du développement Web peut être obscur pour beaucoup de programmeurs.dans ce post, nous voulons expliquer le problème d’ injection SQL
Désormais, injection SQL représente désormais une menace sérieuse pour la sécurité Internet pour diverses applications Web dynamiques résidant sur Internet. Ces applications Web pilotent de nombreux processus vitaux dans diverses entreprises basées sur le Web. À mesure que l’utilisation d’Internet pour divers services en ligne se développe, les menaces à la sécurité sur le Web augmentent également. Il existe un besoin universel pour toutes les applications Web dynamiques et ce besoin universel est le besoin de stocker, de récupérer ou de manipuler des informations à partir d’une base de données. La plupart des systèmes qui gèrent les bases de données et leurs exigences, tels que MySQL Server et PostgreSQL, utilisent SQL comme langage. La flexibilité de SQL en fait un langage puissant. Il permet à ses utilisateurs de demander ce qu’il / elle veut sans divulguer aucune information sur la manière dont les données seront récupérées. Cependant, l’utilisation intensive des bases de données SQL a attiré l’attention des pirates. Ils tirent parti d’applications Web mal codées pour attaquer des bases de données. Ils introduisent une requête SQL apparente, via une entrée utilisateur non autorisée, dans l’instruction de demande légitime. Dans cet article, nous avons essayé de présenter une revue complète de tous les différents types d’attaques par injection SQL présentes, ainsi que la détection de telles attaques et les mesures préventives utilisées. Nous avons mis en évidence leurs forces et leurs faiblesses. Une telle classification aiderait d’autres chercheurs à choisir la bonne technique pour des études ultérieures.
LA SECURITE EST LE PARMAMETRE PRINCIPAL
Une approche efficace des menaces à la sécurité Web doit, par définition, être proactive et défensive. À cette fin, cet article vise à susciter un esprit de sécurité, en injectant, espérons-le, au lecteur une bonne dose de paranoïa.
Ce guide met en particulier l’accent sur 10 pièges courants et importants liés à la sécurité Web, y compris des recommandations sur la manière de les atténuer. L’accent est mis sur le Top 10 des vulnérabilités Web identifié par le Projet de sécurité des applications Web ouvertes (OWASP) , une organisation internationale à but non lucratif dont le but est d’améliorer la sécurité des logiciels dans le monde entier.
VULNÉRABILITÉS DE SÉCURITÉ DU SITE WEB LES PLUS COMMUNES
Parmi les plus grandes violations de données et cyber-attaques de la dernière décennie, il est clair que les erreurs marginales et imprudentes ainsi que les défaillances dans la sécurité des sites Web se sont révélées dangereuses. Même les gros joueurs ont subi de lourdes pertes, non seulement sur le plan financier, mais aussi sur le plan des clients, de la confiance, de l’image de marque et de la bonne volonté.
Nous avons compilé la liste des 10 erreurs de sécurité des sites Web les plus dangereuses que vous devez éviter.
1 – INJECTIONS SQL (FLAWS D’INJECTION)
2- SCRIPTAGE DE SITE TRANSVERSAL (XSS)
3. AUTHENTIFICATION CASSÉE ET GESTION DE SESSION
4. ASSUREZ LES RÉFÉRENCES DES OBJETS DIRECTS
5. MISCONFIGURATION DE SECURITE
6. DEMANDE DE FOURNITURE CROISÉE (CSRF)
7- EXPOSEUR DE DONNÉES SENSIBLES
8- CONTRÔLE D’ACCÈS AU NIVEAU DE FONCTION MANQUANT
9- UTILISER DES COMPOSANTS AVEC DES VULNERABILITES CONNUES
10- REDIRECTIONS ET RENVOIS INVALIDES
N’oublie pas:
ANALYSE DE SÉCURITÉ DE SITE WEB IRRÉGULIÈRE OU AUCUN SITE. L’importance d’une analyse régulière de la sécurité des sites Web ne saurait être suffisamment soulignée. Ce n’est que par le biais d’une analyse régulière que nous pourrons trouver les vulnérabilités et les lacunes existantes et, en conséquence, les corriger. Les entreprises commettent souvent l’erreur fondamentale de ne pas analyser leurs sites Web tous les jours et après des modifications majeures des stratégies, des systèmes, etc.
Qu’est-ce que les attaques par injection SQL?
Le Top 10 de l’OWASP répertorie les scripts XSS (Cross-Site Scripting, Injection et Cross-Site Scripting) comme les risques de sécurité les plus courants pour les applications Web. En effet, elles vont de pair car les attaques XSS dépendent d’une attaque par injection réussie. Bien qu’il s’agisse du partenariat le plus évident, Injection ne se limite pas à l’activation de XSS.
L’injection est une classe entière d’attaques reposant sur l’injection de données dans une application Web pour faciliter l’exécution ou l’interprétation de données malveillantes de manière inattendue. Les exemples d’attaques de cette classe incluent les scripts XSS (Cross-Site Scripting), l’injection SQL, l’injection d’en-tête, l’injection de journal et la divulgation du chemin d’accès complet. Je gratte la surface ici.
Cette classe d’attaques est l’épouvantail de tous les programmeurs. Ce sont les attaques les plus courantes et les plus réussies sur Internet en raison de leurs nombreux types, de leur grande surface d’attaque et de la complexité parfois nécessaire pour se protéger de ces attaques. Toutes les applications ont besoin de données quelque part pour fonctionner. Les scripts inter-sites et les réparations d’interface utilisateur sont, en particulier, si courants que je leur ai dédié le chapitre suivant. Ils sont généralement classés séparément des attaques par injection dans leur classe, en raison de leur importance.
OWASP utilise la définition suivante pour les attaques par injection:
Les failles d’injection, telles que l’injection SQL, OS et LDAP, se produisent lorsque des données non fiables sont envoyées à un interpréteur dans le cadre d’une commande ou d’une requête. Les données hostiles de l’attaquant peuvent inciter l’interprète à exécuter des commandes non intentionnelles ou à accéder à des données non autorisées.
Soit dit en passant, les défauts d’injection résultent d’une défaillance classique du filtrage des entrées non fiables. Il peut se produire lorsque vous passez des données non filtrées au serveur SQL (SQL injection), dans le navigateur (XSS – Nous avions parlé de cela avant ), au serveur LDAP (injection LDAP), ou nulle part ailleurs. Le problème ici est que l’attaquant peut injecter des commandes à ces entités, ce qui entraîne une perte de données et le piratage des navigateurs des clients.
Tout ce que votre application reçoit de sources non fiables doit être filtré, de préférence selon une liste blanche. Vous ne devriez presque jamais utiliser une liste noire, car il est très difficile d’éliminer ce droit. Les logiciels antivirus fournissent généralement des exemples stellaires de listes noires défaillantes. La correspondance de modèle ne fonctionne pas.
dans l’autre définition,
L’injection SQL fonctionne en injectant des données dans une application Web, qui est ensuite utilisée dans les requêtes SQL. Les données proviennent généralement d’entrées non fiables telles qu’un formulaire Web. Cependant, il est également possible que les données proviennent d’une autre source, y compris de la base de données elle-même.
Les programmeurs font souvent confiance aux données de leur base de données, estimant qu’elles sont totalement sûres sans se rendre compte qu’elles sont sans danger pour un usage particulier ne signifie pas qu’elles sont sans danger pour tous les autres usages ultérieurs. Les données d’une base de données doivent être traitées comme non fiables, sauf preuve du contraire, par exemple via des processus de validation.
En cas de succès, une injection SQL peut manipuler la requête SQL ciblée pour effectuer une opération de base de données non prévue par le programmeur.
Veuillez considérer la requête suivante:
$ db = new mysqli ( 'localhost', 'nom d'utilisateur', 'mot de passe', ' stocké ');
$ resultat = $ db -> query (
'SELECT * FROM transactions WHERE user_id = '. $ _ POST [ 'user_id'])
Ce qui précède présente plusieurs défauts.
1- Tout d’abord, nous n’avons pas validé le contenu des données POST pour nous assurer qu’il s’agit d’un ID utilisateur valide.
2- Deuxièmement, nous permettons à une source non fiable de nous dire quel utilisateur_id utiliser – un attaquant pourrait définir n’importe quel user_id valide qu’il voudrait. Peut-être que l’id_utilisateur était contenu dans un champ de formulaire caché que nous pensions sûrs car le formulaire Web ne le laisserait pas être modifié (en oubliant que les attaquants peuvent tout soumettre).
3- Troisièmement, nous n’avons pas échappé l’identifiant user_id et ne l’avons pas transmis à la requête en tant que paramètre lié, ce qui permet également à l’attaquant d’injecter des chaînes arbitraires pouvant manipuler la requête SQL étant donné que nous n’avons pas réussi à le valider.
Les trois défaillances ci-dessus sont remarquablement courantes dans les applications Web.
COMMENT SE PROTEGER CONTRE LES ATTAQUES PAR INJECTION SQL
Les canaux d’entrée utilisateur étant le principal vecteur d’attaques par injection SQL, la plupart des méthodes défensives impliquent le contrôle et la validation de la saisie de l’utilisateur pour les modèles d’attaque.
Voici plusieurs mesures pouvant garantir la sécurité des entrées de l’utilisateur.
1-JAMAIS CONFIANCE EN LA SAISIE DE L’UTILISATEUR
La première règle empirique concernant la saisie de l’utilisateur est « ne faites pas confiance et ne vérifiez pas », ce qui signifie que toutes les formes de saisie de l’utilisateur doivent être considérées comme malveillantes, sauf preuve du contraire. Cela ne concerne pas seulement les zones de saisie simples, telles que les zones de texte et les zones de texte, mais également tout le reste: les entrées masquées, les paramètres de chaîne de requête, les cookies et les téléchargements de fichiers.
Le fait que l’interface utilisateur du navigateur ne permette pas à l’utilisateur de manipuler une entrée ne signifie pas qu’elle ne peut pas être falsifiée. Des outils simples tels que Burp Suite activé Les utilisateurs doivent capturer les requêtes HTTP et modifier n’importe quoi, y compris les valeurs de formulaire masquées, avant de les soumettre au serveur. Et si vous pensez être malin en codant vos données en Base64, celles-ci peuvent facilement être décodées, modifiées et recodées par des utilisateurs malveillants.
2-Valider les chaînes d’entrée côté serveur
La validation consiste à s’assurer que le bon type d’entrée est fourni par les utilisateurs et à neutraliser toute commande malveillante potentielle pouvant être intégrée dans la chaîne d’entrée. Par exemple, en PHP, vous pouvez utiliser mysql \ _real \ _escape \ _ string ( ) pour échapper des caractères susceptibles de modifier la nature de la commande SQL.
Une version modifiée du code de connexion mentionné précédemment serait la suivante:
$ con = mysqli_ connect ( "hôte local", "utilisateur", "mot de passe", " db ");
$ username = mysqli_real_escape_ string ( $ con, $ _POST ['nomutilisateur']);
$ password = mysqli_real_escape_ string ( $ con, $ _POST ['password']);
$ sql_command = "select * from users où username = ' ". $ nom d'utilisateur; $ sql_command . = "'AND password ='". $ mot de passe. "'";
Cette simple modification protégerait votre code contre l’attaque présentée en ajoutant un caractère d’échappement (\) devant les guillemets simples ajoutés intentionnellement par l’utilisateur malveillant.
Une note sur la validation:
Si vous avez ajouté des fonctions de validation côté client, bravo. Mais ne vous fiez pas à cela comme mesure de défense contre les attaques par injection SQL. Bien que les fonctions côté client puissent rendre plus difficile l’envoi d’entrées malveillantes sur votre serveur, il est facile de les contourner avec quelques modifications du navigateur et des outils tels que celui qui vient d’être mentionné. Par conséquent, vous devez le compléter par une validation côté serveur.
Certaines plates-formes de programmation, telles que #ASP.NET, incluent des fonctionnalités intégrées qui évalueront automatiquement les entrées de l’utilisateur en vue de détecter du contenu malveillant sur les publications de page . Mais ils peuvent être contournés par des pirates informatiques avec suffisamment de nervosité et de subtilité. Vous devez donc néanmoins exécuter les entrées de l’utilisateur dans vos procédures de contrôle de sécurité. Vous ne pouvez jamais être trop prudent.
3- Utiliser les paramètres de commande
Une meilleure alternative à l’échappement serait d’utiliser des paramètres de commande. Les paramètres de commande sont définis en ajoutant des noms d’espaces réservés dans les commandes SQL, qui seront ultérieurement remplacées par une entrée utilisateur. #ASP.NET dispose d’un ensemble d’API très intuitif et facile à utiliser à cette fin.
Le code suivant, écrit en C #, montre comment vous pouvez utiliser les paramètres de commande pour protéger votre site Web contre l’injection SQL:
Signaler une annonce
SqlCommand cmd = new SqlCommand ("SELECT * FROM utilisateurs WHERE nomutilisateur = @ nomutilisateur ET mot de passe = @ mot de passe" , con );
SqlParameter username = new SqlParameter ( ); nom_utilisateur.NomParamètre = "@nom_utilisateur"; username.value = txtUsername.Text ; cmd.Parameters.Add (nom d'utilisateur);
SqlParameter password = new SqlParameter ( ); password.ParameterName = "@password"; password.value = txtPassword.Text ; cmd.Parameters.Add (mot de passe);
vous commencez par créer un SqlCommand objet et en utilisant le @ paramètre_name the paradigme dans la chaîne de commande où l’entrée utilisateur doit être insérée.
Vous créez ensuite des instances de SqlParameter objets, dans lesquels vous insérez l’entrée utilisateur, au lieu de la concaténer directement avec la chaîne de commande.
Enfin, vous ajoutez le SqlParameter objecter à la SqlCommand La collection Parameters de l’objet, qui remplacera les paramètres avec l’entrée fournie. ADO.net s’occupe du reste.
En PHP, l’équivalent est préparé, ce qui est un peu plus compliqué que son équivalent ASP.net. Vous pouvez l’explorer ici .
4-EXPLICITE EXPLICITEMENT VOTRE ENTRÉE
Cette astuce concerne les langages tels que PHP, qui sont faiblement typés, ce qui signifie que vous ne définissez généralement pas les types de données pour les variables, et que le langage se charge automatiquement de convertir différents types de données entre eux.
Les conversions explicites peuvent servir de raccourci pour échapper des entrées lorsque des types non-chaînes sont impliqués. Donc, si vous attendez de l’utilisateur qu’il entre un int pour le age paramètre, vous pouvez assurer la sécurité de l’entrée avec le code suivant en PHP:
$ age = ( int ) $ _POST ['age'];
Notez que cet extrait de code valide uniquement le type de l’entrée, pas sa plage. Vous devrez donc exécuter un autre code pour vous assurer que l’utilisateur n’entre pas d’âge négatif – ou peu réaliste, tel que 1300.
En outre, une autre bonne pratique consiste à éviter d’utiliser des guillemets simples dans les commandes SQL dans lesquelles une entrée non chaîne est impliquée. Donc au lieu d’utiliser le code suivant…
$ sql_command = "select * from users où age = ". $ age;
… Il serait un peu plus sûr d’utiliser le suivant:
$ sql_command = "select * from users où age = ' ". $ âge. "'";
Conclusion:
La bonne nouvelle est que la protection contre l’injection consiste «simplement» à filtrer correctement votre entrée et à déterminer si l’on peut faire confiance à une entrée. Mais la mauvaise nouvelle est que toutes les entrées doivent être filtrées correctement à moins de pouvoir faire confiance à tout le monde (mais le dicton «ne jamais dire jamais» vient ici à l’esprit).
Par exemple, dans un système à 1 000 entrées, filtrer 999 d’entre elles avec succès n’est pas suffisant, car il ne reste qu’un champ qui peut servir de solution de rechange au traitement d’ Achille . Et vous pourriez penser que l’insertion du résultat d’une requête SQL dans une autre requête est une bonne idée, car la base de données est fiable, mais si le périmètre ne l’est pas, l’entrée provient indirectement de personnes atteintes de malintent . C’est appelé Deuxième injection SQL au cas où cela vous intéresserait.
Comme le filtrage est assez difficile à faire correctement (comme la crypto), ce que je conseille généralement est de vous fier aux fonctions de filtrage de votre infrastructure: elles ont fait leurs preuves et fonctionnent minutieusement. Si vous n’utilisez pas de framework, vous devez réfléchir sérieusement à la question de savoir si ne pas leur utilisation est logique dans le contexte de sécurité de votre serveur. 99% du temps, ce n’est pas le cas.
En d’autres termes, l’injection SQL existe depuis des décennies et continuera probablement de figurer en tête des tableaux de vulnérabilité pour les années à venir. Cela prend quelques étapes simples – mais bien calculées – pour vous protéger et protéger vos utilisateurs, et cela devrait faire partie de vos principales priorités lors de l’audit de votre code source pour détecter les failles de sécurité.
La clé pour éviter d’être victime de la prochaine grande violation de données d’injection SQL consiste tout d’abord à contrôler et à valider les entrées de l’utilisateur et, deuxièmement, à vous préparer au «quand» et non au «si».
Document IEEE de l'injection SQL
Le livre Elsevier de l'injection SQL
Comment protéger votre site Web contre les attaques par injection SQL?
Table of Contents
Categories
Préface
Si vous avez lu nos précédents articles , nous abordons dans deux articles les problèmes de sécurité des sites Web et des applications Web. Pour trop d’entreprises, ce n’est qu’après Une faille de sécurité s’est produite qui fait que les meilleures pratiques en matière de sécurité Web deviennent une priorité. Au cours de mes années en tant que professionnel de la sécurité informatique, j’ai constaté maintes et maintes fois à quel point le monde des problèmes de sécurité du développement Web peut être obscur pour beaucoup de programmeurs.dans ce post, nous voulons expliquer le problème d’ injection SQL
Désormais, injection SQL représente désormais une menace sérieuse pour la sécurité Internet pour diverses applications Web dynamiques résidant sur Internet. Ces applications Web pilotent de nombreux processus vitaux dans diverses entreprises basées sur le Web. À mesure que l’utilisation d’Internet pour divers services en ligne se développe, les menaces à la sécurité sur le Web augmentent également. Il existe un besoin universel pour toutes les applications Web dynamiques et ce besoin universel est le besoin de stocker, de récupérer ou de manipuler des informations à partir d’une base de données. La plupart des systèmes qui gèrent les bases de données et leurs exigences, tels que MySQL Server et PostgreSQL, utilisent SQL comme langage. La flexibilité de SQL en fait un langage puissant. Il permet à ses utilisateurs de demander ce qu’il / elle veut sans divulguer aucune information sur la manière dont les données seront récupérées. Cependant, l’utilisation intensive des bases de données SQL a attiré l’attention des pirates. Ils tirent parti d’applications Web mal codées pour attaquer des bases de données. Ils introduisent une requête SQL apparente, via une entrée utilisateur non autorisée, dans l’instruction de demande légitime. Dans cet article, nous avons essayé de présenter une revue complète de tous les différents types d’attaques par injection SQL présentes, ainsi que la détection de telles attaques et les mesures préventives utilisées. Nous avons mis en évidence leurs forces et leurs faiblesses. Une telle classification aiderait d’autres chercheurs à choisir la bonne technique pour des études ultérieures.
LA SECURITE EST LE PARMAMETRE PRINCIPAL
Une approche efficace des menaces à la sécurité Web doit, par définition, être proactive et défensive. À cette fin, cet article vise à susciter un esprit de sécurité, en injectant, espérons-le, au lecteur une bonne dose de paranoïa.
Ce guide met en particulier l’accent sur 10 pièges courants et importants liés à la sécurité Web, y compris des recommandations sur la manière de les atténuer. L’accent est mis sur le Top 10 des vulnérabilités Web identifié par le Projet de sécurité des applications Web ouvertes (OWASP) , une organisation internationale à but non lucratif dont le but est d’améliorer la sécurité des logiciels dans le monde entier.
VULNÉRABILITÉS DE SÉCURITÉ DU SITE WEB LES PLUS COMMUNES
Parmi les plus grandes violations de données et cyber-attaques de la dernière décennie, il est clair que les erreurs marginales et imprudentes ainsi que les défaillances dans la sécurité des sites Web se sont révélées dangereuses. Même les gros joueurs ont subi de lourdes pertes, non seulement sur le plan financier, mais aussi sur le plan des clients, de la confiance, de l’image de marque et de la bonne volonté.
Nous avons compilé la liste des 10 erreurs de sécurité des sites Web les plus dangereuses que vous devez éviter.
1 – INJECTIONS SQL (FLAWS D’INJECTION)
2- SCRIPTAGE DE SITE TRANSVERSAL (XSS)
3. AUTHENTIFICATION CASSÉE ET GESTION DE SESSION
4. ASSUREZ LES RÉFÉRENCES DES OBJETS DIRECTS
5. MISCONFIGURATION DE SECURITE
6. DEMANDE DE FOURNITURE CROISÉE (CSRF)
7- EXPOSEUR DE DONNÉES SENSIBLES
8- CONTRÔLE D’ACCÈS AU NIVEAU DE FONCTION MANQUANT
9- UTILISER DES COMPOSANTS AVEC DES VULNERABILITES CONNUES
10- REDIRECTIONS ET RENVOIS INVALIDES
N’oublie pas:
ANALYSE DE SÉCURITÉ DE SITE WEB IRRÉGULIÈRE OU AUCUN SITE. L’importance d’une analyse régulière de la sécurité des sites Web ne saurait être suffisamment soulignée. Ce n’est que par le biais d’une analyse régulière que nous pourrons trouver les vulnérabilités et les lacunes existantes et, en conséquence, les corriger. Les entreprises commettent souvent l’erreur fondamentale de ne pas analyser leurs sites Web tous les jours et après des modifications majeures des stratégies, des systèmes, etc.
Qu’est-ce que les attaques par injection SQL?
Le Top 10 de l’OWASP répertorie les scripts XSS (Cross-Site Scripting, Injection et Cross-Site Scripting) comme les risques de sécurité les plus courants pour les applications Web. En effet, elles vont de pair car les attaques XSS dépendent d’une attaque par injection réussie. Bien qu’il s’agisse du partenariat le plus évident, Injection ne se limite pas à l’activation de XSS.
L’injection est une classe entière d’attaques reposant sur l’injection de données dans une application Web pour faciliter l’exécution ou l’interprétation de données malveillantes de manière inattendue. Les exemples d’attaques de cette classe incluent les scripts XSS (Cross-Site Scripting), l’injection SQL, l’injection d’en-tête, l’injection de journal et la divulgation du chemin d’accès complet. Je gratte la surface ici.
Cette classe d’attaques est l’épouvantail de tous les programmeurs. Ce sont les attaques les plus courantes et les plus réussies sur Internet en raison de leurs nombreux types, de leur grande surface d’attaque et de la complexité parfois nécessaire pour se protéger de ces attaques. Toutes les applications ont besoin de données quelque part pour fonctionner. Les scripts inter-sites et les réparations d’interface utilisateur sont, en particulier, si courants que je leur ai dédié le chapitre suivant. Ils sont généralement classés séparément des attaques par injection dans leur classe, en raison de leur importance.
OWASP utilise la définition suivante pour les attaques par injection:
Soit dit en passant, les défauts d’injection résultent d’une défaillance classique du filtrage des entrées non fiables. Il peut se produire lorsque vous passez des données non filtrées au serveur SQL (SQL injection), dans le navigateur (XSS – Nous avions parlé de cela avant ), au serveur LDAP (injection LDAP), ou nulle part ailleurs. Le problème ici est que l’attaquant peut injecter des commandes à ces entités, ce qui entraîne une perte de données et le piratage des navigateurs des clients.
dans l’autre définition,
Les programmeurs font souvent confiance aux données de leur base de données, estimant qu’elles sont totalement sûres sans se rendre compte qu’elles sont sans danger pour un usage particulier ne signifie pas qu’elles sont sans danger pour tous les autres usages ultérieurs. Les données d’une base de données doivent être traitées comme non fiables, sauf preuve du contraire, par exemple via des processus de validation.
En cas de succès, une injection SQL peut manipuler la requête SQL ciblée pour effectuer une opération de base de données non prévue par le programmeur.
Veuillez considérer la requête suivante:
Ce qui précède présente plusieurs défauts.
1- Tout d’abord, nous n’avons pas validé le contenu des données POST pour nous assurer qu’il s’agit d’un ID utilisateur valide.
2- Deuxièmement, nous permettons à une source non fiable de nous dire quel utilisateur_id utiliser – un attaquant pourrait définir n’importe quel user_id valide qu’il voudrait. Peut-être que l’id_utilisateur était contenu dans un champ de formulaire caché que nous pensions sûrs car le formulaire Web ne le laisserait pas être modifié (en oubliant que les attaquants peuvent tout soumettre).
3- Troisièmement, nous n’avons pas échappé l’identifiant user_id et ne l’avons pas transmis à la requête en tant que paramètre lié, ce qui permet également à l’attaquant d’injecter des chaînes arbitraires pouvant manipuler la requête SQL étant donné que nous n’avons pas réussi à le valider.
Les trois défaillances ci-dessus sont remarquablement courantes dans les applications Web.
COMMENT SE PROTEGER CONTRE LES ATTAQUES PAR INJECTION SQL
Les canaux d’entrée utilisateur étant le principal vecteur d’attaques par injection SQL, la plupart des méthodes défensives impliquent le contrôle et la validation de la saisie de l’utilisateur pour les modèles d’attaque.
Voici plusieurs mesures pouvant garantir la sécurité des entrées de l’utilisateur.
1-JAMAIS CONFIANCE EN LA SAISIE DE L’UTILISATEUR
La première règle empirique concernant la saisie de l’utilisateur est « ne faites pas confiance et ne vérifiez pas », ce qui signifie que toutes les formes de saisie de l’utilisateur doivent être considérées comme malveillantes, sauf preuve du contraire. Cela ne concerne pas seulement les zones de saisie simples, telles que les zones de texte et les zones de texte, mais également tout le reste: les entrées masquées, les paramètres de chaîne de requête, les cookies et les téléchargements de fichiers.
Le fait que l’interface utilisateur du navigateur ne permette pas à l’utilisateur de manipuler une entrée ne signifie pas qu’elle ne peut pas être falsifiée. Des outils simples tels que Burp Suite activé Les utilisateurs doivent capturer les requêtes HTTP et modifier n’importe quoi, y compris les valeurs de formulaire masquées, avant de les soumettre au serveur. Et si vous pensez être malin en codant vos données en Base64, celles-ci peuvent facilement être décodées, modifiées et recodées par des utilisateurs malveillants.
2-Valider les chaînes d’entrée côté serveur
La validation consiste à s’assurer que le bon type d’entrée est fourni par les utilisateurs et à neutraliser toute commande malveillante potentielle pouvant être intégrée dans la chaîne d’entrée. Par exemple, en PHP, vous pouvez utiliser mysql \ _real \ _escape \ _ string ( ) pour échapper des caractères susceptibles de modifier la nature de la commande SQL.
Une version modifiée du code de connexion mentionné précédemment serait la suivante:
Cette simple modification protégerait votre code contre l’attaque présentée en ajoutant un caractère d’échappement (\) devant les guillemets simples ajoutés intentionnellement par l’utilisateur malveillant.
Une note sur la validation:
Certaines plates-formes de programmation, telles que #ASP.NET, incluent des fonctionnalités intégrées qui évalueront automatiquement les entrées de l’utilisateur en vue de détecter du contenu malveillant sur les publications de page . Mais ils peuvent être contournés par des pirates informatiques avec suffisamment de nervosité et de subtilité. Vous devez donc néanmoins exécuter les entrées de l’utilisateur dans vos procédures de contrôle de sécurité. Vous ne pouvez jamais être trop prudent.
3- Utiliser les paramètres de commande
Une meilleure alternative à l’échappement serait d’utiliser des paramètres de commande. Les paramètres de commande sont définis en ajoutant des noms d’espaces réservés dans les commandes SQL, qui seront ultérieurement remplacées par une entrée utilisateur. #ASP.NET dispose d’un ensemble d’API très intuitif et facile à utiliser à cette fin.
Le code suivant, écrit en C #, montre comment vous pouvez utiliser les paramètres de commande pour protéger votre site Web contre l’injection SQL:
Signaler une annonce
SqlCommand cmd = new SqlCommand ("SELECT * FROM utilisateurs WHERE nomutilisateur = @ nomutilisateur ET mot de passe = @ mot de passe" , con ); SqlParameter username = new SqlParameter ( ); nom_utilisateur.NomParamètre = "@nom_utilisateur"; username.value = txtUsername.Text ; cmd.Parameters.Add (nom d'utilisateur); SqlParameter password = new SqlParameter ( ); password.ParameterName = "@password"; password.value = txtPassword.Text ; cmd.Parameters.Add (mot de passe);vous commencez par créer un SqlCommand objet et en utilisant le @ paramètre_name the paradigme dans la chaîne de commande où l’entrée utilisateur doit être insérée.
Vous créez ensuite des instances de SqlParameter objets, dans lesquels vous insérez l’entrée utilisateur, au lieu de la concaténer directement avec la chaîne de commande.
Enfin, vous ajoutez le SqlParameter objecter à la SqlCommand La collection Parameters de l’objet, qui remplacera les paramètres avec l’entrée fournie. ADO.net s’occupe du reste.
En PHP, l’équivalent est préparé, ce qui est un peu plus compliqué que son équivalent ASP.net. Vous pouvez l’explorer ici .
4-EXPLICITE EXPLICITEMENT VOTRE ENTRÉE
Cette astuce concerne les langages tels que PHP, qui sont faiblement typés, ce qui signifie que vous ne définissez généralement pas les types de données pour les variables, et que le langage se charge automatiquement de convertir différents types de données entre eux.
Les conversions explicites peuvent servir de raccourci pour échapper des entrées lorsque des types non-chaînes sont impliqués. Donc, si vous attendez de l’utilisateur qu’il entre un int pour le age paramètre, vous pouvez assurer la sécurité de l’entrée avec le code suivant en PHP:
Notez que cet extrait de code valide uniquement le type de l’entrée, pas sa plage. Vous devrez donc exécuter un autre code pour vous assurer que l’utilisateur n’entre pas d’âge négatif – ou peu réaliste, tel que 1300.
En outre, une autre bonne pratique consiste à éviter d’utiliser des guillemets simples dans les commandes SQL dans lesquelles une entrée non chaîne est impliquée. Donc au lieu d’utiliser le code suivant…
… Il serait un peu plus sûr d’utiliser le suivant:
Conclusion:
La bonne nouvelle est que la protection contre l’injection consiste «simplement» à filtrer correctement votre entrée et à déterminer si l’on peut faire confiance à une entrée. Mais la mauvaise nouvelle est que toutes les entrées doivent être filtrées correctement à moins de pouvoir faire confiance à tout le monde (mais le dicton «ne jamais dire jamais» vient ici à l’esprit).
Par exemple, dans un système à 1 000 entrées, filtrer 999 d’entre elles avec succès n’est pas suffisant, car il ne reste qu’un champ qui peut servir de solution de rechange au traitement d’ Achille . Et vous pourriez penser que l’insertion du résultat d’une requête SQL dans une autre requête est une bonne idée, car la base de données est fiable, mais si le périmètre ne l’est pas, l’entrée provient indirectement de personnes atteintes de malintent . C’est appelé Deuxième injection SQL au cas où cela vous intéresserait.
Comme le filtrage est assez difficile à faire correctement (comme la crypto), ce que je conseille généralement est de vous fier aux fonctions de filtrage de votre infrastructure: elles ont fait leurs preuves et fonctionnent minutieusement. Si vous n’utilisez pas de framework, vous devez réfléchir sérieusement à la question de savoir si ne pas leur utilisation est logique dans le contexte de sécurité de votre serveur. 99% du temps, ce n’est pas le cas.
En d’autres termes, l’injection SQL existe depuis des décennies et continuera probablement de figurer en tête des tableaux de vulnérabilité pour les années à venir. Cela prend quelques étapes simples – mais bien calculées – pour vous protéger et protéger vos utilisateurs, et cela devrait faire partie de vos principales priorités lors de l’audit de votre code source pour détecter les failles de sécurité.
La clé pour éviter d’être victime de la prochaine grande violation de données d’injection SQL consiste tout d’abord à contrôler et à valider les entrées de l’utilisateur et, deuxièmement, à vous préparer au «quand» et non au «si».
Document IEEE de l'injection SQL
Le livre Elsevier de l'injection SQL
Archive
Catégories
Aucun avis n’a été donné pour le moment. Soyez le premier à en écrire un.
kaviani siavosh
All Posts