Les codeurs à la conquête de la sécurité : partagez et apprenez - Injection SQL

En termes simples, SQL (ou Structured Query Language) est le langage utilisé pour communiquer avec les bases de données relationnelles ; c'est le langage de requête utilisé par les développeurs, les administrateurs de bases de données et les applications pour gérer d'énormes quantités de données sont générées chaque jour.

Nos données sont en passe de devenir l'une des matières premières les plus précieuses au monde... et lorsque quelque chose est précieux, les malfaiteurs voudront s'en emparer à leur avantage.

Les attaquants utilisent l'injection SQL, l'une des plus anciennes (depuis 1998!) et les vulnérabilités de données les plus embêtantes du marché, visant à voler et à modifier les informations sensibles disponibles dans des millions de bases de données dans le monde entier. C'est insidieux, et les développeurs doivent comprendre l'injection SQL (et savoir comment s'en défendre) si nous voulons protéger nos données.

À cette fin, nous aborderons trois aspects clés de l'injection SQL :

• どうやって動くの？
• Pourquoi c'est si dangereux
• Comment s'en défendre

Comprendre l'injection SQL

L'injection SQL peut être comprise en un seul mot : contexte.

Au sein d'une application, deux contextes existent : l'un pour les données, l'autre pour le code. Le contexte du code indique à l'ordinateur ce qu'il doit exécuter et le sépare des données à traiter.

L'injection SQL se produit lorsqu'un attaquant saisit des données traitées par erreur comme du code par l'interpréteur SQL.

Un exemple est un champ de saisie sur un site Web, dans lequel un attaquant saisit « » OR 1=1 » et il est ajouté à la fin d'une requête SQL. Lorsque cette requête est exécutée, elle renvoie « true » pour chaque ligne de la base de données. Cela signifie que tous les enregistrements de la table interrogée seront renvoyés.

Les implications de l'injection SQL peuvent être catastrophiques. Si cela se produit sur une page de connexion, elle peut renvoyer tous les enregistrements utilisateur, y compris éventuellement les noms d'utilisateur et les mots de passe. Si une simple requête visant à extraire des données aboutit, les requêtes visant à modifier des données le feront également.

Jetons un coup d'œil à un code vulnérable afin que vous puissiez voir à quoi ressemble une vulnérabilité d'injection SQL en chair et en os.

Consultez ce code :

String query = « SÉLECTIONNEZ LE SOLDE DU COMPTE DEPUIS user_data OÙ user_name = »
+ Request.getParameter (« CustomerName ») ;
essayez {
Déclaration = Connection.createStatement (...) ;
ResultSet results = Statement.executeQuery (requête) ;
}

Le code ici ajoute simplement les informations de paramètres du client à la fin de la requête SQL sans validation. Dans ce cas, un attaquant peut saisir du code dans un champ de saisie ou dans des paramètres d'URL et celui-ci sera exécuté.

L'essentiel n'est pas que les attaquants puissent uniquement ajouter « » OR 1=1 » à chaque requête SELECT, mais qu'ils puissent manipuler n'importe quel type de requête SQL (INSERT, UPDATE, DELETE, DROP, etc.) et l'étendre avec tout ce que la base de données prend en charge. Il y en a d'excellents ressources et des outils disponibles dans le domaine public qui montrent ce qui est possible.

Nous apprendrons bientôt comment corriger ce problème. Tout d'abord, comprenons l'ampleur des dégâts qui peuvent être causés.

Pourquoi l'injection SQL est si dangereuse

Voici seulement trois exemples de violations provoquées par une injection SQL :

• Site web du Bureau des élections de l'Illinois a été violée en raison de vulnérabilités d'injection SQL. Les assaillants ont volé les données personnelles de 200 000 citoyens américains. La nature de la vulnérabilité découverte signifiait que les attaquants auraient également pu modifier les données, mais ils ne l'ont pas fait.
• Hetzner, une société sud-africaine d'hébergement de sites Web, a été violée à hauteur de 40 000 fiches clients. Une vulnérabilité d'injection SQL a entraîné le vol de tous les enregistrements clients de leur base de données.
• Un fournisseur de services financiers catholique du Minnesota, aux États-Unis, a été violée à l'aide d'une injection SQL. Les informations de compte, y compris les numéros de compte, de près de 130 000 clients ont été volées.

Les données sensibles peuvent être utilisées pour prendre le contrôle de comptes, réinitialiser des mots de passe, voler de l'argent ou commettre des fraudes.

Même les informations qui ne sont pas considérées comme sensibles ou qui ne permettent pas de vous identifier personnellement peuvent être utilisées pour d'autres attaques. Les informations d'adresse ou les quatre derniers chiffres de votre numéro d'identification gouvernemental peuvent être utilisés pour usurper votre identité auprès des entreprises ou pour réinitialiser votre mot de passe.

Lorsqu'une attaque réussit, les clients peuvent perdre confiance en l'entreprise. Les réparations en cas de dommages aux systèmes ou d'amendes réglementaires peuvent coûter des millions de dollars.

Mais ça ne doit pas nécessairement se terminer ainsi pour toi.

Vaincre l'injection SQL

L'injection SQL peut être vaincue en étiquetant clairement certaines parties de votre application, afin que l'ordinateur sache si une certaine partie est constituée de données ou de code à exécuter. Cela peut être fait à l'aide de requêtes paramétrées.

Lorsque les requêtes SQL utilisent des paramètres, l'interpréteur SQL utilise le paramètre uniquement comme données. Il ne l'exécute pas sous forme de code.

Par exemple, une attaque telle que « » OR 1=1" ne fonctionnera pas. La base de données recherchera la chaîne « OR 1=1 » et ne la trouvera pas dans la base de données. Il haussera simplement les épaules et dira : « Désolé, je ne peux pas te trouver ça. »

Voici un exemple de requête paramétrée en Java :

La plupart des frameworks de développement fournissent des défenses intégrées contre les injections SQL.

Mappeurs relationnels d'objets (ORM), tels que Cadre des entités de la famille .NET, paramètrera les requêtes par défaut. Cela permettra de procéder à l'injection SQL sans aucun effort de votre part.

Cependant, vous devez savoir comment fonctionne votre ORM spécifique. Par exemple, Hiberner, un ORM populaire dans le monde Java, peut toujours être vulnérable à l'injection SQL en cas d'utilisation incorrecte.

Le paramétrage des requêtes est la première et la meilleure défense, mais il en existe d'autres. Les procédures stockées prennent également en charge les paramètres SQL et peuvent être utilisées pour empêcher l'injection SQL. Gardez à l'esprit que les procédures stockées doit également être construit correctement pour que cela fonctionne.

//Cela devrait VRAIMENT être validé aussi
String custname = Request.getParameter (« CustomerName ») ;
//effectue une validation des entrées pour détecter les attaques
String query = « SÉLECTIONNEZ account_balance FROM user_data WHERE user_name = ? « ;

PreparedStatement pstmt = Connection.PreparedStatement (requête) ;
PSTMT.setString (1, nom personnalisé) ;
résultats ResultSet = pstmt.ExecuteQuery () ;

Validez et nettoyez toujours vos entrées. Étant donné que certains caractères, tels que « OU 1=1 », ne seront pas saisis par un utilisateur légitime de votre application, il n'est pas nécessaire de les autoriser. Vous pouvez afficher un message d'erreur à l'intention de l'utilisateur ou le supprimer de votre saisie avant de la traiter.

Cela dit, ne comptez pas uniquement sur la validation et la désinfection pour vous protéger. Des humains intelligents ont trouvé des moyens de le contourner. Ce sont de bonnes stratégies de défense en profondeur (DiD), mais le paramétrage est le moyen infaillible de couvrir toutes les bases.

Une autre bonne stratégie DiD consiste à utiliser le « moindre privilège » dans la base de données et à mettre les entrées sur liste blanche. L'application du principe du moindre privilège signifie que votre application ne dispose pas d'un pouvoir illimité au sein de la base de données. Si un attaquant parvient à y accéder, les dégâts qu'il peut infliger sont limités.

L'OWASP a un excellent Aide-mémoire SQL Injection disponible pour montrer comment gérer cette vulnérabilité dans plusieurs langues et plateformes... mais si vous voulez vous améliorer, vous pouvez dès maintenant jouer à un défi d'injection SQL dans la langue de votre choix sur notre plateforme ; voici quelques-unes des plus populaires pour commencer :

Injection SQL en C#

Injection SQL dans Node.js

Injection SQL dans Python Django

Injection SQL dans Java Spring

Le voyage commence

Vous avez fait de grands progrès dans la compréhension de l'injection SQL et des étapes nécessaires pour y remédier. Génial !

Nous avons expliqué comment se produit l'injection SQL, généralement lorsqu'un attaquant utilise une entrée pour contrôler les requêtes de votre base de données à ses propres fins néfastes.

Nous avons également constaté les dommages causés par l'exploitation des vulnérabilités liées à l'injection SQL : des comptes peuvent être compromis et des millions de dollars perdus... un cauchemar, et cela coûte cher en plus.

Nous avons vu comment empêcher l'injection SQL :

• Paramétrage des requêtes
• Utilisation de mappeurs relationnels d'objets et de procédures stockées
• Validation et mise sur liste blanche des données saisies par les utilisateurs

Maintenant, c'est à toi de décider. La pratique est le meilleur moyen de continuer à apprendre et à développer la maîtrise, alors pourquoi ne pas consulter notre Ressources pédagogiques sur l'injection SQL, puis essayez notre démo gratuite de la plateforme ? Vous êtes sur la bonne voie pour devenir un Secure Code Warrior.