Introduction : Qu’est-ce que l’injection SQLInjection SQL

Article à destination des développeurs web et administrateurs de sites.

Une injection SQL est comme son nom l’indique une injection ou insertion de code SQL via des données transmises depuis un site web. Une injection réussie et correctement exploitée permet de récupérer des informations sensibles d’une base de données ou encore de modifier/supprimer/ajouter des données.

D’une manière générale, toutes les actions liées à une base de données sont possibles. Habituellement ce type d’injection concerne PHP avec une base SQL mais d’autres langages comme ASP peuvent aussi être concernés.

Ce type d’injection survient habituellement quand les données des utilisateurs sont utilisées sans être filtrées ou vérifiées.

Que peut-on faire exactement avec une injection SQL ?

Habituellement le pirate cherchera à récupérer des informations sensibles de votre base de données.

Même si vous connaissez vos visiteurs ou ne pensez pas connaître un utilisateur capable d’attaquer votre site, il faut savoir qu’un pirate cherchera simplement des sites vulnérables à l’aide de ce que l’on appelle un Dork Google.

Un Dork est un mot-clé très précis contenant un modèle qui permet de récupérer de sites éventuellement faillibles.

Il n’y a pas de raisons légitimes d’afficher tous les dorks possibles ici et d’ailleurs ils sont très nombreux, sachez simplement qu’on peut rechercher une page précise qui pourrait correspondre à une page faillible de votre site.

Par se connecter sur une telle page, la requête SQL que l’on place sur notre site ressemble généralement à quelque chose comme :

"SELECT id FROM users WHERE name = 'Admin' AND password = '".$_POST["password"]."'"

On sélectionne donc l’identifiant de l’utilisateur dont le nom est Admin et dont le mot de passe correspondant à celui envoyé par l’utilisateur qui veut se connecter.

C’est à ne JAMAIS faire, car si on poste :

' OR '1'='1

en tant que mot de passe on obtient la requête suivante :

"SELECT id FROM users WHERE name = 'Admin' AND password = '' OR '1'='1'"

Ce qui donne, traduit en français : "Sélectionner l’identifiant de l’utilisateur dont le nom est admin et dont le mot de passe est vide OU 1 est égal à 1"

Ainsi le mot de passe ne sera pas vide mais 1 est égal à 1 donc l’accès est autorisé, l’identifiant est bien sélectionné.

C’est l’exemple très classique dont on parle souvent en cours de bases de données.

Comment savoir si mon site est faillible ?

On peut chercher les problèmes à partir de nos codes sources directement mais aussi, et plus simplement, en ajoutant un

'

à la fin d’une url faillible. Si une erreur apparaît sur votre site du type, c’est qu’il y a potentiellement un souci :

Erreur dans l'exécution de la requête 'SELECT * FROM galerie WHERE id = 2''. Message de MySQL : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

L’erreur apparaît sur le site car " id=2' " est directement utilisé pour former la requête alors que " ' " est un caractère spécial de SQL. Ce qui provoque donc une erreur de syntaxe.

Cette erreur nous indique donc que les données entrées par les utilisateurs ne sont pas vérifiées du côté serveur, et qu’il y a donc de fortes chances qu’on puisse aller plus loin.

Je ne vais pas ici continuer jusqu’au bout mais sachez qu’ensuite le pirate pourra récupérer les noms des tables et à afficher leur contenu. Les mots de passe (de la table admin par exemple) apparaîtront généralement chiffrés sur le site. C’est notamment pour cela qu’il faut absolument chiffrer les mots de passe des utilisateurs dans les bases de données.

L’autre façon de savoir si son site est faillible est de scanner son code source.

Il existe deux façons de scanner un code source : la façon manuelle et la façon automatique.

La façon manuelle consiste, comme son nom l’indique, à rechercher nos morceaux de code qui communiquent avec la base de données et s’assurer qu’ils soient robustes (voir plus bas dans l’article).

La façon automatique consiste à analyser son code avec un outil. OWASP propose une liste d’outils de ce genre :

https://www.owasp.org/index.php/Source_Code_Analysis_Tools

Blind SQL injection (injection SQL à l’aveugle)

Comme son nom l’indique, l’injection SQL « à l’aveugle » consiste à exploiter un site faillible de la même manière que celle qu’on a vu.

À cela près que le résultat (les messages d’erreur) ne sont pas affichés sur la page.

Là encore des outils complets sont utilisés pour automatiser tout cela. Notamment si une entreprise fait appel à une équipe de hackers éthiques pour tester la sécurité de leur systèmes sans avoir à fournir le code source.

Comment s’en prémunir

Venons-en au point essentiel, se prémunir des attaques par injection SQL.

Si on reprend l’exemple du début :

"SELECT id FROM users WHERE name = 'Admin' AND password = '".$_POST["password"]."'"

On utilise ici ce que l’utilisateur envoie directement dans la requête.

Donc la première chose à faire est d’éviter (d’échapper) les caractères spéciaux à l’aide de mysqli_real_escape_string() :

"SELECT id FROM users WHERE name = 'Admin' AND password = '".mysqli_real_escape_string($_POST["password"])."'"

Les fonctions addslashes() et magic_quotes_gpc() sont aussi utilisées mais ne protègent pas aussi bien que mysqli_real_escape_string().

Un moyen qui tend à se généraliser mais impacte légèrement les performances est l’utilisation des commandes préparées

Les procédures stockées nécessitent plus de connaissances mais peuvent aussi être utilisées. L’identification restera bien protégée à l’intérieur de la procédure et ne pourra plus être détournée.

Enfin, il faut préférer l’utilisation de comptes utilisateurs à accès limité pour empêcher la modification ou suppression d’éléments de la base de données.

Et éventuellement vérifier les données avec des expressions régulières ou utiliser des tableaux contenant tous les résultats possibles.

Envie d’en apprendre plus sur les failles web ?

Cette faille et bien d’autres est vue en détail dans mon cours vidéo sur les tests d’intrusion web.

Nous allons parler des fondamentaux : fonctionnement d’HTTP, d’HTTPs, de DNS et de l’architecture web de manière générale.

Nous allons également mettre en place un laboratoire de test avec des machines virtuelles pour héberger et scanner nos sites vulnérables afin d’apprendre sans rien casser.

Nous allons bien sûr parler de toutes les failles web (XSS, CSRF, SQL, LFI, RFI, …etc) en suivant le Top 10 OWASP mais aussi de tout ce qui gravite autour de la sécurité web : dénis de service, mauvaises configurations, données personnelles, reconnaissance, etc…

Impatient de commencer avec vous, je vous propose de rejoindre le cours dès maintenant: https://cyberini.com/cours/hacking-ethique-tests-intrusion-web/

Articles similaires

31 Commentaires
Cliquez ici pour ajouter un commentaire

  • Moi je ne trouve pas de site faillible tu n’aurais pas un site ?

    Répondre
  • LeHackerDesBois
    6 avril 2014 8 h 11 min

    merci pour ces renseignements je go direct verifier si mon site est securiser. meme si je n’ai pas tout compris =)

    Répondre
  • Bonjour et merci pour votre article. Depuis quelques jours mon site est victime de hacker. j’ai vérifié les injections SQL j’ai pas l’impression qu’il y ai un probleme a ce niveau la… Je ne trouve pas la faille !

    Est-ce vous pourriez m’aider svp ?

    Le site : http://www.olivale.com

    Merci beaucoup pour votre aide, je ne sais plus quoi faire !
    Bonne journée.

    Répondre
  • Pourriez-vous m’indiqué vers qui me tourner svp ? ca peux plus continuer 🙁
    Merci

    Répondre
  • Salut, d’abord je tiens à vous remercie pour votre dangerosité.

    Pourriez-vous me dire pourquoi ça ne marche pas si on mit  » ‘ or ‘0’=’0 « , ou une autre valeur à la place de « 0 » au lieu de  » ‘ or ‘1’=’1  » svp?.

    Selon l’explication et logiquement 0 est égal à 0 alors ça doit marcher non ?

    J e vous remercie par avance pour votre repose.

    Répondre
    • Salut, me remercier pour ma dangerosité semble un peu étrange mais merci quand même. Il y a beaucoup de variations possibles je ne dis pas qu’il y a juste 1=1 qui fonctionne

      Répondre
  • « On sélectionne donc l’id de l’utilisateur dont le nom ET Admin et dont le mot de passe correspondant à celui envoyé par l’utilisateur qui veut se connecter. » = est
    Ceci etait un message du correcteur orthographique 😛 (oui je sais je n’ai pas mis d’accent a « etait » et pas non plus sur mon « a », mais je suis en qwerty…)

    Répondre
  • Bonsoir,

    Article super intéressant. Je retiens son dernier paragraphe qui me semble être d’une importance capitale en matière de sécurisation, je cite:

    « Enfin, il faut préférer l’utilisation de comptes utilisateurs à accès limité pour empêcher la modification ou suppression d’éléments de la base de données. Et éventuellement vérifier les données avec des expressions régulières ou utiliser des tableaux contenant tous les résultats possibles. »

    Ce principe de limitation des droits utilisateurs sur une base de données reste valable pour tout type de serveur et d’environnement, surtout lorsqu’il s’agit notamment de sécuriser une infrastructure réseau toute entière ! LoL! 🙂

    Répondre
  • Bonjours !

    Merci, déjà, de nous faire partager votre expérience !

    Le principe d’une injection SQL est donc dans le champ du mot de passe de demander au site si 1=1, et la réponse positive du site (bête comme il est) nous permet de se connecter selon le lien de redirection en cas de réponse positive ?

    Je ne suis pas sur de mon raisonnement et préfère vous demander !

    Ce serait pas mal que vous créiez un tout petit site à notre disposition pour nous entraîner ;).

    Mais si je comprend bien en modifiant le code on peut aussi avoir d’autre résultats moins éthique comme un payement par carte bancaire en confirmant l’achat et même le numéro de carte … Et dans cette optique tous les sites « pro » se sont prémunis de cette faille, alors pourquoi certains sur des forums ne jurent encore que par la sainte relique InjectionSQL ?

    Merci, Daegars.

    Répondre
    • Bonjour,
      Alors ce n’est pas le fait de demander si 1=1 qui pose problème, mais le fait de pouvoir exécuter dans la base de données des requêtes SQL. Les conséquences de cette possibilité de communication avec la base de données sont effectivement nombreuses, dont l’utilisation de la commande avec 1=1 qui permet de ne pas avoir à utiliser le mot de passe. J’ai fait un exemple pour bien comprendre sur la page suivante : https://www.leblogduhacker.fr/sandbox
      Tous les sites, « pro » ou non devraient être prémunis de cette faille, mais l’erreur est humaine et c’est justement pour cela qu’il est utile de faire de la prévention et d’indiquer comment résoudre ce problème.

      Répondre
      • Bonjour Michel,
        Pour l’instant je n’ai jamais eu à me pencher sur ce genre de failles. La problématique des failles « injections sql » n’est finalement pas due à une mauvaise sécurité de la base de données mais plutôt à un ou plusieurs scripts mal sécurisés en amont.

        La mise en oeuvre de tels scripts requiert des connaissances pointues dans le domaine de la sécurité d’un système d’information, ce qui bien évidemment complique la tâche de sécurisation d’une base de données pour des « Administrateurs » n’ayant pas les compétences requises. Attention, je ne fais aucun jugement à ce niveau. Moi-même j’ai été confronté à un manque de connaissance au niveau des scripts Java, notamment dans le cadre d’un déploiement de centralisateur de logs au sein d’une grosse infra réseau/systèmes. Lorsque l’on s’attaque à du filtrage hyper pointu de logs applicatifs par exemple, c’est balaise mais passionnant ! 🙂

        L’un des gros inconvénient de ce type de « technique de sécurisation » est qu’elle nécessite énormément de ressources systèmes et une supervision drastique de l’ensemble de l’infrastructure réseau et systèmes, ce qui la rend peu abordable à de toute petite structure et système d’information.

        Répondre
        • Bonjour Diki,
          Oui, ce sont bien les façons d’accéder à une base de données qui présentent des faiblesses. Je ne dirais pas que créer du code sécurisé demande des connaissances vraiment pointues (dans ce cas du moins) mais qu’il y a des bonnes pratiques de développement à appliquer, notamment lorsque l’on traite des « entrées utilisateur ».
          Et effectivement la sécurité est souvent un « poids » dans le sens où elle demande des connaissances, du budget, et d’autres ressources que tu cites très bien. Seulement, même en mettant tout cela en place, on risque de se faire pirater, alors qu’en est-il si l’on ne fait rien…

          Répondre
  • HOUNTON Wilfried
    20 octobre 2016 18 h 28 min

    Vraiment intéressant

    Répondre
  • Bonjour et merci pour cet article. Je me demande juste pourquoi ne pas faire un SELECT * from users; pour ensuite faire des actions en local ?

    Répondre
  • Bonjour Michel,

    Je suis votre cours sur le Hacking ethique et alors j’ai remarqué une injection SQL depuis une page Web de mon modem alors comment s’en prémunir ?

    J’ai regarder la page de code de la page web en question et alors depuis la page de code il est écrit comment se connecter au modem,
    ceci dit pour la personne qui ne connaît pas le code WIFI c’est impossible de se connecter à distance bref du coup je n’ai pas les droits pour changer le code d’accés du modem,
    J’ai même le bouton service qui ne fonctionne pu !

    du coup depuis OWASP j’ai trouvé une faille SQL et j’aimerai savoir comment la corriger,

    Dans l’attente d’une réponse que j’espère favorable de votre part je vous accorde mes respects,

    Cordialement.

    Dorian ROSSE.

    Répondre
    • Bonjour Dorian,
      Content de vous trouver parmi les étudiants du cours ! 🙂
      Je ne sais pas de quel modem il s’agit exactement, il s’agit probablement de la page de connexion ou d’aide à la connexion au modem. Vous devriez pouvoir accéder à votre modem depuis un ordinateur connecté à celui-ci, par contre je ne saurais vous dire où la page est stockée physiquement. Car il faudrait effectivement y accéder pour pouvoir éditer et corriger le code source. Vous trouverez sans doute de l’aide dans le manuel de la box et/ou sur un site officiel. Bonne continuation.

      Répondre
  • Svp comment me proteger contre sqlmap

    Répondre
  • salut michel je vient de lire ton sujet très bien fait comme toujours .

    je vois des gens qui ont des problèmes avec cela c »est vrai que cela est pas
    simple quant cela et la première fois qu’on aborde le sujet.

    donc ici je fait deux commentaire en deux parti. un pour les utilisateur normal et un autre
    pour les gens plus avancés dans le domaine.

    donc dans celui la je parle de cross site scripting xss plus connu sous le nom de xss
    est en faite un sous ensemble de l’injection html . xss est le problème de sécurité

    applicatif web le plus répandu et le plus pernicieux. les failles xss se produisent à chaque fois
    qu’une application prend des données écrites par l’utilisateur.

    et les envoie à un browser web sans en avoir au préalable validé ou codé le contenu.
    xss permet à des attaquants d’exécuter du script dans le navigateur de la victime.

    afin de détourner des sessions utilisateur. défigurer des sites web insérer du contenu hostile
    effectuer des attaques par phishing et prendre le contrôle du navigateurs de la victime.

    en utilisant un script malicieux malware scripting le script malicieux est habituellement
    écrit en java script. mais n’importe quel langage de programmation supporté .

    par le navigateur de la victime est une cible potentielle pour cette attaque.

    environnements affectés

    touts les contextes applicatifs web sont vulnérables au cross site scripting

    vulnérabilité

    il existe trois types de cross site scripting connus par réflexion par stockage et par injection dom.
    l’attaque xss par réflexion est la plus facile à exploiter une page renverra à l’utilisateur.

    des données fournies directement à celui ci echo $_request [‘ userinput’] ;

    l’attaque xss par stockage prend des données hostiles. les stocke dans un fichier.
    une base de données ou tout autre système de back end et ultérieurement affiche les

    données à l’utilisateur. non filtrées. ceci est extrêmement dangereux dans les système
    tels que cms. les blogs ou les forums où un grand nombre d’utilisateurs seront à même

    de voir les inputs d’autres individus. avec les attaques xss basées sur dom. le code java script
    et les variables du site sont manipulé plutôt que les éléments html.

    alternativement. les attaques peuvent être ou un mélange ou un hybride de ces trois
    types. le danger avec cross site scripting n’est pas tant le type d’attaque.

    mais plutôt qu’il soit possible. les comportements non standards ou inattendus du navigateur
    peuvent présenter des vecteurs.d’attaque subtils.xss est aussi potentiellement accessible

    à travers tous les composants qu’utilise le navigateur. les attaques sont habituellement
    effectuées en java script qui est un puissant langage de programmation.

    l’utilisation de java script permet aux attaquants de manipuler n’importe quel aspect de la page.
    rendue y compris l’ajout de nouveaux éléments tel qu’ajouter une demande de login.

    qui forwarde les droits à un site hostile.en manipulant n’importe quel aspect de l’arborescence
    interne dom et supprimant ou changeant la présentation de la page.

    java script permet l’utilisation de xml httprequest qui est typiquement employé par des sites
    utilisant les technologies ajax même si le site de la victime n’emploie pas ajax aujourd’hui.

    en utilisant xml httprequest il est parfois possible de contourner la politique source d’un
    navigateur. transmettant ainsi les données de la victime vers des sites hostiles.

    et de créer des vers complexes et des zombies malveillants. qui perdurent aussi longtemps
    que le navigateur reste ouvert.

    les attaques ajax n’ont pas besoin d’être visibles ou de nécessiter une interaction
    de l’utilisateur. pour exécuter des attaques dangereuses de type cross site request

    forgery . csrf. si cela est utile pour toi michel tu peut bien sûr tant servir pour les
    réponse que tu donne aux gens avec grand plaisir.

    dans la partie suivante je donne des conseille de sécurité et bien sûr les chose
    qu’il faut par faire pour les gens qui en savent un peut plus voir même pour ceux

    qui déboute dans le domaine voila je souhaite une très bonne journée à tous

    et a très bientôt pour la suite du sujet

    Répondre
  • bonne soirée michel pour répondre a diki je pense que certaines pratique sont
    mal mise en place pour la sécurité avec de gros danger à la clef ?

    exemple le déchiffrement ssl c’est un peu le second effet kiss cool ce qui remet sous les feux
    de l’actualité la technique du déchiffrement ssl consistant à décoder au sein de l’entreprise

    les communications cryptées des employés afin de maintenir la sécurité une technique
    à haut risque. d’un côté les grands fournisseurs de services web ou d’outils de connexion .

    qui soit pour se refaire une virginité après le scandale prism soit par réelle conviction
    renforcent l’usage du chiffrement. qu’on songe par exemple à l’annonce de google

    affirmant sa volonté de privilégier le référencement des sites https. de l’autre les responsables
    de la sécurité informatique des grandes entreprises. que ces montée en puissance du cryptage

    peut déranger. car s’il censé garantir la confidentialité des échanges des internautes il rend
    aussi aveugle les équipements de sécurité. et au milieu le déchiffrement ssl ou plutôt tls

    le successeur de ssl autrement dit la mise en oeuvre par l’entreprise d’une technique lui
    permettant d’inspecter les flux que l’utilisateur pensait chiffrés entre le serveur et sont poste.

    de travail. le sujet n’a rien de réellement neuf à part qu’il prend aujourd’hui une autre dimension.
    du fait de la généralisation du chiffrement sur les services web.

    Répondre
  • bonne soirée michel comme je les dit dans le commentaire que j’ai fait sur le cross site scripting
    et les danger du ssl de donne la suite du sujet plus basée sur les injection sql et la sécurité.

    introduction au concept d’injection sql. l’idée de ce sujet est de permettre aux plus néophytes
    d’entre nous de parvenir à mieux comprendre la sécurité contre les injection.

    ne sera pas détaillée la mise en oeuvre d’injection sql au delà du strict nécessaire à la compréhension.
    pour des raison bien évidente de sécurité.

    les développeurs débutants sont bien souvent peu ou pas conscients des possibilités énormes
    de manipulation possibles avec les requêtes sql donc des risques d’injection sql

    il supposent à tort que les requêtes sql sont des instructions fiables or il n’en est rien. une requête sql
    est par nature en mesure de contourner tout ou partie des contrôles de sécurité d’une application.

    l’injection sql est donc possible uniquement quand une requête est générée à partir de données.
    fournies par un utilisateur. données utilisées directement pour construire tout ou partie d’une

    requête sql insert update jointure conditions de filtrage de regroupement.
    la technique d’injection sql la plus courante vise à forcer l’analyseur de requête sql à ignorer

    le reste de la requête en utilisant les symboles de mise en commentaires.

    l’attaque par injection sql -sqli est un ensemble de techniques qui permet à un attaquant.
    d’utiliser une faiblesse dans le code développé. avec pour objectif de détourner l’utilisation.

    prévue d’une requête sql dans son contexte applicatif. la finalité étant d’injecter tout ou fragment.
    d’une requête sql dans la requête qui doit normalement s’exécuter. à un instant de l’application

    exemple identification suppression de compte etc. typiquement toute exécution d’une requête sql qui
    attribue directement des valeurs par concaténation et ou qui utilise. directement des variables

    provenant directement du front sans aucun. traitement crée cette faille dans le code.
    la sécurisation doit s’effectuer sur plusieurs niveaux pour limiter la surface d’attaque.

    dans un schéma idéal de sécurisation il devrait systématiquement y avoir deux connexion.
    sql une utilisée pour accéder aux ressources en lecture et une seconde en écriture.

    chacune avec le minimum de droit requis pour les besoin de l’application.
    ce modèle de sécurisations permet de limiter la portée de chaque injection. sql possible

    cette stratégie n’est pas toujours possible limite de l’hébergement. et à défaut le compte utilisateur
    utilisé. devrait avoir les accès minimums nécessaire au fonctionnement de l’application.

    second niveau de protection contre les injections sql la couche d’accès aux données.
    dans une architecture mvc ou trois tiers la dal. data access layer est l’objet qui permet de s’interfacer

    avec la base de données pour exécuter les requêtes sql. exemple l’objet pdo en php elle devrait
    systématiquement être intégrée dans les applicatifs via un wrapper surcouche logiciel.

    qui réaliserait des préparations des requêtes avant leur exécution de manière à garantir que 100%
    des requêtes sont utilisées via une requête préparée.

    troisième niveau de défense contre les injection sql
    le modèle /objet relationnel. toujours dans le cadre d’une architecture professionnelle.

    les données émanant de la base de données ou d’un formulaire devraient passer par un objet
    relationnel qui réaliserait les contrôles et les transcodages nécessaire.

    sur le format des données attendues ou à défaut retourner une valeur prédéfinie voir annuler le traitement
    de manière à garantir le typage et le format des données.

    Répondre
  • salut michel un grand merci pour ta réponse sûr la sécurité des entreprise.

    je voie que tu parle de injection sql en aveugle pour faire vite je donne une petit explication.

    sur son utilisation pour un pirate et à quoi cela peut lui servir l’objectif de cette approche est de déterminer
    la réponse en fonction du retour de l’application.

    absence de données. message d »erreur ou délais de réponse de la base. cette attaque est principalement
    utilisée quand une application es configurée pour afficher des message d’erreur générique.

    il est aisé d’envisager une requête testant l’existence de l’id d’un utilisateur. puis grâce à une condition if
    d »exiger du moteur d’attendre quelques seconde s’il n’existe pas. ce type d’attaque par injection sql.

    est relativement compliquée mais pas impossible. elle sert en règle générale en phase de reconnaissance pour
    définir le moteur sql employé. ou pour se faire une idée du schéma de la table de la base ou pour contrôler

    si un enregistrement existe par des tests sur les clés primaires.

    Répondre
    • Salut, oui tout à fait, elle est tout simplement « à l’aveugle » faute de faire autrement et amène donc potentiellement des résultats moins précis, mais utiles pour la reconnaissance, merci 🙂

      Répondre
  • salut michel super intéressant ton sujet des injection sql . l’attaque par injection sql est l’une des failles les plus
    communes sur un site internet. pour réponde à diki il est donc primordial de la comprendre pour s’en protéger.

    depuis 1998 et jusqu’à lors les attaques par injection sql restent la faille de sécurité la plus fréquente sur les site
    internet. pour cause une trop grande méconnaissance du sujet et un manque de sensibilisation des développeurs

    web à la sécurité dans sa globalité. ici michel pour les déboutant je parle de injection sql qui pour moi ne semble
    la plus dangereuse. ? injection sql par sous requête et empilement stackes queries sqli est de loin l’attaque la plus

    dangereuse pour une infrastructure. elle permet d’exécuter plusieurs instructions dans la même requête
    pour étendre les possibilités de l’injection sql initiale. une requête par empilement offre un très grand niveau de

    contrôle à un attaquant. ce type d’attaque par injection sql permet à l’attaquant de ne pas exécuter la requête
    d’origine et de la remplacer par une nouvelle requête sql. il pourra à partir de la faire ce qu’il souhaite.

    le risque le plus grand est que l’environnement de la base de données puisse avoir accès à des commandes
    comme xp-shellcmd qui permettent d’exécuter du code shell directement via une procédure stockée.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous devez remplir ce champ
Vous devez remplir ce champ
Veuillez saisir une adresse e-mail valide.

Menu