Outils de scanner d’injection SQL
Un code d’application Web faible peut permettre aux pirates d’accéder à votre base de données et à votre réseau
Aperçu de l’injection SQL
L’injection SQL est actuellement la forme d’attaque de site Web la plus courante en ce sens que les formulaires Web sont très courants, qu’ils ne sont souvent pas codés correctement et que les outils de piratage utilisés pour trouver les faiblesses et en tirer parti sont couramment disponibles en ligne. Ce type d’exploit est assez facile à accomplir pour que même des pirates informatiques inexpérimentés puissent commettre des méfaits. Cependant, entre les mains du pirate informatique très habile, une faiblesse du code Web peut révéler l’accès au niveau racine des serveurs Web et à partir de là, des attaques sur d’autres serveurs en réseau peuvent être accomplies.
Le langage de requête structuré (SQL) est le langage presque universel des bases de données qui permet le stockage, la manipulation et la récupération de données. Les bases de données qui utilisent SQL incluent MS SQL Server, MySQL, Oracle, Access et Filemaker Pro et ces bases de données sont également sujettes à une attaque par injection SQL.
Les formulaires Web doivent permettre un accès à votre base de données pour permettre la saisie de données et une réponse, de sorte que ce type d’attaque contourne les pare-feu et les défenses des terminaux. Tout formulaire Web, même un simple formulaire d’ouverture de session ou une boîte de recherche, peut donner accès à vos données au moyen d’une injection SQL s’il est mal codé.
Fonctionnement de l’injection SQL
Les prospects, les clients, les employés et les partenaires commerciaux peuvent tous avoir le droit de stocker ou de récupérer des informations de votre base de données. Votre site permet probablement à tout visiteur du site de soumettre et de récupérer des données. L’accès légitime pour les visiteurs comprend la recherche sur le site, les formulaires d’inscription, les formulaires de contact, les formulaires d’ouverture de session et tous ces éléments fournissent des fenêtres dans votre base de données. Ces différents points d’accès sont très probablement intégrés dans des applications « prêtes à l’emploi » ou peuvent être des applications personnalisées configurées uniquement pour votre site. Ces formulaires et leur code de support proviennent probablement de nombreuses sources, ont été acquis à différents moments et éventuellement installés par différentes personnes.
L’injection SQL est l’utilisation de ces champs accessibles au public pour accéder à votre base de données. Cela se fait en entrant des commandes SQL dans vos champs de formulaire au lieu des données attendues. Des formulaires mal codés permettront à un pirate de les utiliser comme point d’entrée de votre base de données, à quel point les données de la base de données peuvent devenir visibles et l’accès à d’autres bases de données sur le même serveur ou d’autres serveurs du réseau peut être possible.
Les fonctionnalités du site Web telles que les formulaires de contact, les pages d’ouverture de session, les demandes d’assistance, les fonctions de recherche, les champs de rétroaction, les paniers d’achat et même les fonctions qui fournissent un contenu de page Web dynamique sont toutes susceptibles d’être attaquées par injection SQL car les champs présentés pour l’utilisation par les visiteurs DOIVENT permettre au moins à certaines commandes SQL de passer directement à la base de données.
Risque d’injection SQL
Étant donné que les bases de données contrôlent de nombreuses fonctions du site Web, presque tous les sites Web invitent les visiteurs et de nombreux formulaires Web sont vulnérables, l’injection SQL est devenue et est restée pendant des années la forme la plus courante d’outil de piratage de site Web utilisé. De plus, tant de criminels utilisent maintenant l’injection SQL que de nouvelles faiblesses de serveur, d’application et de code sont découvertes presque quotidiennement.
Nos propres dossiers indiquent que la plupart (plus de la moitié) des sites Web que nous avons été invités à analyser présentaient des risques d’injection SQL de niveaux élevés ou moyens. Un niveau de risque élevé est celui qui est effectivement une porte déverrouillée et non gardée. Un risque moyen est un risque qui, combiné à un ou plusieurs autres facteurs, pourrait causer des problèmes. Un nombre encore plus grand de sites présentaient des problèmes à faible risque. Ce que vous devez savoir: Le pourcentage de sites présentant au moins un risque majeur augmente en fait.
Même si l’injection SQL est un problème connu depuis des années, plusieurs facteurs entraînent une augmentation du taux de risque. La première est que de plus en plus d’entreprises offrent plus d’interactions sur le site Web avec les visiteurs et que cette tendance augmente considérablement. Deuxièmement, à mesure que de plus en plus de pirates acquièrent des compétences en injection SQL, ils découvrent de plus en plus d’applications et de services susceptibles d’être attaqués et développent de nouvelles attaques sur d’anciennes applications. Le résultat est une augmentation presque exponentielle des possibilités d’utiliser cette méthode d’attaque.
Votre risque d’être attaqué avec succès à l’aide de l’injection SQL est basé sur deux facteurs: la nature et la taille de votre entreprise et l’âge, l’état des mises à jour et des correctifs sur vos applications et la compétence et le nombre de votre personnel technique. Cela se résume à savoir si vous êtes une cible intéressante et si votre serveur Web, les applications qui s’y trouvent et le code de votre site Web sont bien conçus, bien intégrés et contiennent tous les correctifs et mises à jour actuels.
Votre site est en danger immédiat si votre entreprise stocke des données de grande valeur, si votre entreprise ou entité opère dans un domaine d’activité très contesté, ou si votre site a une importance ou une valeur politique ou sociale. Naturellement, si vous avez quelque chose de valeur monétaire, vous êtes une cible. Mais vous êtes également une cible si votre site est un leader d’opinion dans un environnement litigieux. Des blogueurs nous ont demandé de l’aide car le sujet traité avait suscité des attaques par injection SQL.
Les attaques par injection SQL sont maintenant sollicitées en ligne. Un client contrarié, un concurrent ou même un ex–conjoint peut désormais facilement engager un « script kiddie » – ou pire, un pirate informatique talentueux – pour attaquer un site. Les chances que le pirate se fasse prendre sont faibles. La chance que la partie contrariée puisse endommager votre site sans être pointée du doigt car la partie responsable est élevée.
Techniquement, vous êtes à risque d’injection SQL si vous avez des équipements ou des applications qui n’ont pas été régulièrement mis à jour et corrigés, ou si vous avez du code sur votre site qui n’a pas été correctement écrit. L’âge de l’équipement, les applications et le code est un indicateur approximatif du risque. Un autre est le nombre de serveurs impliqués, le nombre d’applications et le nombre de points d’accès au site Web. Si vous utilisez des serveurs hébergés ou si vous utilisez des ressources techniques externalisées, un examen par un tiers de la sécurité de votre site est important. Et même le personnel interne peut être tellement pressé par le temps et le manque de ressources que les mises à jour et les correctifs peuvent être retardés ou que le vieux code hérité peut être utilisé sans examen approprié.
Exemple d’injection SQL
Chaque fois qu’un visiteur du site Web saisit des données dans un formulaire sur votre site, une requête SQL est générée et transmise à votre base de données. Dans le cas d’un simple formulaire d’ouverture de session, le nom d’utilisateur et le mot de passe sont présentés à la base de données et s’ils sont valides, la base de données répond par une réponse et l’utilisateur est autorisé à y accéder (ou non). Ainsi, peu importe la simplicité du formulaire ou du processus Web, un accès à la base de données est requis et une réponse est attendue.
À l’aide de l’injection SQL, un pirate tentera d’entrer une commande SQL spécialement conçue dans un champ de formulaire au lieu des informations attendues. L’intention est de sécuriser une réponse de la base de données qui aidera le pirate à comprendre la construction de la base de données, telle que les noms de table. L’étape suivante consisterait à accéder et à afficher les données dans les tables importantes ou à ajouter des données aux tables, telles que l’ajout de nouveaux comptes ou de noms d’utilisateur et de mots de passe. La troisième étape, en gros, consisterait à utiliser l’accès à la base de données pour découvrir et modifier les paramètres de sécurité sur un serveur qui permettraient à un pirate d’accéder à l’administration.
Tout langage de script dynamique, y compris ASP, ASP.NET , PHP, JSP et CGI sont vulnérables aux attaques. Le seul équipement nécessaire est un navigateur Web. Il existe des outils largement disponibles en ligne qui automatiseront semi-le processus de recherche des faiblesses, et il existe de nombreux forums dans lesquels les pirates partagent des exploits et s’entraident pour surmonter les obstacles.
Résultats de l’injection SQL
Comme vous pouvez l’imaginer, un pirate accédant à votre serveur signifie que vous aurez effectivement perdu toutes les données de ce serveur au profit de l’envahisseur. Pire encore, il y a maintenant une tête de pont derrière votre pare-feu à partir de laquelle des attaques sur d’autres serveurs et services peuvent maintenant être effectuées. De cette manière, l’injection SQL peut donner accès à toutes les données de l’entreprise ou personnelles.
Du point de vue d’un pirate, un élément du piratage qui est presque aussi important que l’effraction est le maintien du secret. Déclencher une « alarme » quelconque est la dernière chose qu’ils veulent faire. Leur travail d’infiltration prend du temps et souvent la valeur des données volées diminue si le vol est découvert (information de valeur en vol d’identité ou de carte bancaire par exemple). Ainsi, les hacks d’injection SQL sont souvent découverts des mois et dans certains cas des années après leur initiation.
Alternativement, si un dommage pur et simple est l’intention, les mauvaises choses qui peuvent être faites à une base de données une fois que l’on a accès aux commandes en cours d’exécution ne manquent pas. Une table entière peut être définitivement supprimée à l’aide d’une seule commande SQL. Cependant, une attaque par injection SQL plus sophistiquée pourrait impliquer une corruption massive de grandes bases de données et même la destruction de copies de sauvegarde.
Défense contre l’injection SQL
Les sites Web nécessitant un accès constant à la base de données, les pare-feu offrent peu ou pas de défense contre les attaques par injection SQL. Votre site Web est public et des pare-feu doivent être configurés pour permettre à chaque visiteur du site d’accéder à votre base de données, généralement via le port 80/443.
Les programmes antivirus sont tout aussi inefficaces pour bloquer les attaques par injection SQL. Ils sont destinés à repérer et à arrêter un tout autre type de données entrantes.
La défense par injection SQL la plus couramment utilisée est composée de deux composants. Tout d’abord, il y a la mise à jour et le correctif de routine de tous les serveurs, services et applications, ce qui présente bien sûr de nombreux avantages et est une pratique courante. Ensuite, il y a la production et l’utilisation d’un code de site Web bien écrit et bien testé qui interdit les commandes SQL inattendues.
Ces deux défenses sont par définition suffisantes pour stopper toute attaque par injection SQL. Alors, pourquoi les vulnérabilités et les risques du site Web augmentent-ils et pourquoi les attaques réussies se produisent-elles plus souvent? Les réponses sont chacune simples et se combinent en une liste intimidante:
- Le nombre de serveurs, d’applications et le volume de code sur les sites Web augmentent
- Ces serveurs, applications et langages de code interagissent entre eux de manière parfois imprévisible
- Le nombre et la fréquence des mises à jour et des correctifs augmentent
- Les services informatiques travaillent davantage avec moins de personnel et certaines activités telles que les mises à jour sont reportées
- Roulement du personnel informatique et les licenciements laissent parfois des trous camouflés dans les routines de sécurité
- L’installation automatique de chaque correctif et mise à jour qui arrive produit souvent effets secondaires indésirables
- Le code hérité est souvent réutilisé lorsque les sites sont mis à jour, gardant parfois le code écrit selon les anciennes normes en usage longtemps après qu’il soit obsolète
- Le nombre de personnes qui tentent de faire des piratages et le nombre d’outils disponibles pour simplifier le piratage augmentent presque de manière exponentielle
De plus en plus d’entreprises avec d’énormes facteurs de risque et de grandes « empreintes » Web en viennent à conclure que tout corriger et embaucher plus de personnel pour surveiller le site. le travail du personnel existant n’est plus viable.
Solution d’outil de scanner d’injection SQL pour site Web
La nouvelle solution aux attaques par injection SQL (et à toutes les autres attaques basées sur le Web) consiste à concentrer un temps informatique limité et précieux sur les risques sérieux qui sont réellement présents, plutôt que d’utiliser une approche de fusil de chasse et d’appliquer toutes les correctifs possibles à chaque serveur, chaque application et chaque page de code, qu’elle soit nécessaire ou non. Cette nouvelle approche revient à demander à un médecin d’évaluer un patient et de proscrire le SEUL médicament nécessaire pour produire un remède, plutôt que de demander au patient d’aller directement à la pharmacie pour obtenir tous les médicaments possibles et de les prendre tous en même temps.
Ainsi, une plus grande sécurité est obtenue grâce à l’utilisation d’outils de test d’applications Web, tels que beSECURE, en tant qu’outil d’analyse par injection SQL pour examiner (analyser) un site Web à l’aide d’une liste de milliers d’attaques connues, puis rendre compte des problèmes relativement rares (généralement moins d’une douzaine) graves.
L’analyse du site Web fonctionne sur la base du repérage et du signalement des risques CONNUS. Le piratage courant est une activité très « publique ». Les outils sont largement promus. Les techniques sont largement diffusées dans les forums publics. Même de nouvelles méthodes deviennent publiques dans les heures ou les jours suivant leur première utilisation, grâce à des groupes comme SecuriTeam.com et d’autres qui surveillent et préviennent ensuite largement les autres.
BeSECURE, le système automatisé de détection des vulnérabilités, est un service Web qui utilise une compilation de tous les risques connus dans les familles et toutes les familles dans une seule base de données qui a pris de nombreuses années à compiler et de nombreuses heures par jour à maintenir. En utilisant cette base de données, beSECURE peut évaluer n’importe quel site Web et produire un rapport des risques RÉELS et ACTUELS évalués en fonction de leur importance relative – souvent en quelques heures et sans perturber les activités en cours du site.
Maintenant, vous pouvez prendre vos précieuses heures de travail informatiques et gérer directement les risques réels tels que l’injection SQL plutôt que de passer des centaines d’heures à installer des correctifs et des mises à jour, dont vous n’avez pas besoin ou qui gèrent des risques si faibles qu’ils sont négligeables.
Pour plus d’informations sur beSECURE, veuillez utiliser le formulaire sur cette page ou nous contacter.