Brevet FR3147642A1 — publié le 20241011

La présente invention concerne un procédé de génération d’un développement informatique résistant aux attaques par injection SQL à partir d’un développement préexistant caractérisé en ce qu’il comporte les étapes suivantes une étape de caractérisation des requêtes d’un premier fichier par un analyseur qui consiste à extraire de chacun des fichiers les méthodes de manière à identifier et caractériser les requêtes en fonction de ce qu’elles sont déjà des requêtes préparées (en anglais prepared statements) ou non, par des traitements en boucle pour parcourir successivement les modèles successifs constituant le code source du fichier en cours de traitement, et pour chacun des modèles, une boucle secondaire imbriquée pour extraire et caractériser successivement tous les séquences du modèle en cours de traitement dans la boucle principale, avant d’incrémenter la boucle principale pour passer au modèle suivant , et de modification par un moteur d’intelligence artificielle des méthodes enregistrées ; consistant à constituer N lots de M méthodes à traiter, N étant supérieur 1 et NxM correspondant au plus proche entier supérieur au nombre de méthodes enregistrées dans ladite mémoire temporaire. Figure de l’abrégé : Figure 1 Procédé de génération d’un code informatique résistant aux attaques par injection SQL Domaine technique de l’invention La présente invention concerne la sécurité logicielle et plus particulièrement, cette invention concerne des techniques complètes pour identifier des vulnérabilités de sécurité logicielle pendant le développement, le test et le déploiement de logiciels. En Europe, on estime que 70% des attaques informatiques utilisent la méthode d’injection SQL. Cela s’explique par l’omniprésence des développements basés sur le langage SQL. Quel que soit le domaine d’activité, la plupart des développements informatiques mettent en œuvre des bases de données, et le langage informatique le plus répandu pour manipuler des données est le langage SQL (acronyme du terme anglais Structured Query Language). Ce langage est utilisé par la plupart des solutions informatiques pour organiser le stockage, la manipulation et la recherche de données. Il permet aussi d’effectuer des requêtes, de mettre à jour les données, de les réorganiser, ou encore de créer et de modifier le schéma et la structure d’un système de base de données et de contrôler l’accès à ses données. Le langage SQL est utilisé dans tous les domaines où les bases de données sont exploitées. En d’autres termes, on le retrouve dans pratiquement tous les domaines où des données sont générées et analysées. Dans l’industrie de la finance, les applications bancaires et de traitement de paiements stockent les données sur les transactions financières et les utilisateurs. Ces systèmes reposent sur des bases de données complexes et requièrent donc l’usage de SQL. De même, les applications de streaming musical comme Spotify ou Deezer utilisent intensivement les bases de données, par exemple pour stocker les vastes catalogues de fichiers musicaux issus de différents albums par différents artistes. Les réseaux sociaux tels que Facebook™ ou Instagram™ utilisent le langage SQL pour stocker les informations sur le profil d’un utilisateur telles que sa biographie ou sa position géographique. Chaque fois qu’un utilisateur crée une publication ou partage un contenu, le langage SQL permet de mettre à jour la base de données. En raison de cette omniprésence dans la plupart des développements informatiques, les attaques utilisant les opportunités offertes par le langage SQL représentent une source de vulnérabilité majeure et prisée par les pirates informatiques. Une des méthodes les plus utilisées par les pirates informatiques pour accéder à une base de données est désignée par le terme « Injection SQL ». Elle consiste à insérer du code malveillant dans une requête SQL via un formulaire ou un autre champ de saisie d'une application web, afin d'obtenir des informations sensibles ou d'exécuter des actions malveillantes sur la base de données. Les conséquences peuvent être très graves, allant de la divulgation d'informations confidentielles à la prise de contrôle complète de la base de données. Pour lutter contre ces attaques, une solution consiste à filtrer les requêtes en analysant les entrées utilisateur pour vérifier qu'elles correspondent à ce qui est attendu. Et ne contiennent pas de caractères spéciaux ou de séquences de caractères qui pourraient être utilisés pour injecter du code SQL. Ce filtrage consomme des ressources informatiques et dégradent les performances, et surtout ne sont jamais exhaustives car les variantes de séquences et de caractères permettant de procéder à de l’injection SQL sont infinies, et un filtrage excessif peut provoquer des disfonctionnements. Une autre solution consiste à limiter les privilèges des utilisateurs en fonction de leurs besoins. Les utilisateurs ne doivent avoir accès qu'aux ressources dont ils ont besoin pour effectuer leur travail. Cela réduit les risques d'attaques par injection SQL. Toutefois, l’administration des privilèges constitue une tâche fastidieuse et complexe. Une autre solution consiste à prévoir en amont, lors du développement de l’application, exclusivement des requêtes préparées : Les requêtes préparées permettent de séparer les données fournies par l'utilisateur des instructions SQL. Cela empêche les attaquants d'injecter du code malveillant dans les requêtes SQL. Une requête préparée en langage SQL est une méthode de traitement de requêtes qui permet d'améliorer les performances et la sécurité des opérations de base de données. Lorsqu'une requête est envoyée au serveur de base de données, le moteur de requête SQL doit d'abord analyser la requête, la compiler et l'exécuter. Avec les requêtes préparées, cette étape est effectuée une seule fois et la requête compilée est stockée en mémoire cache. Ainsi, lorsqu'une requête préparée est exécutée à nouveau, le serveur de base de données peut simplement récupérer la requête compilée en mémoire cache, ce qui améliore les performances. En outre, les requêtes préparées (en anglais « prepared statements ») permettent de mieux sécuriser les opérations de base de données en évitant les attaques d'injection SQL. En effet, les paramètres de la requête sont transmis séparément de la requête elle-même, ce qui empêche les attaquants d'injecter du code SQL malveillant dans la requête. Les développeurs peuvent notamment utiliser des bibliothèques de gestion de base de données fournissant des fonctions qui protègent contre les attaques par injection SQL, comme proposé par le brevet américain US7653620. Pour se protéger contre les attaques par injection SQL, il est essentiel de mettre en place des pratiques de développement de code sécurisé, de tester régulièrement les applications pour détecter les vulnérabilités et d'utiliser des outils de prévention des attaques par injection SQL. Toutefois, les systèmes d'information deviennent de plus en plus complexes, de plus en plus puissants, interconnectés et librement accessibles aux partenaires et aux clients sur des réseaux largement distribués avec des interactions électroniques largement anonymes. Le développement de logiciels lui-même est de plus en plus distribué par le biais d'accords de développement avec des prestataires indépendants et le recours à des développements collaboratifs. Ces tendances mettent à rude épreuve la capacité des organisations à sécuriser et à protéger les données numériques contre les abus ou les accès non autorisés et à garantir que le code ne contient aucune faille, sans compter que le codage avec des requêtes préparées est fastidieux. Les requêtes non préparées peuvent être identifiées par la présence de chaînes de caractères contenant des instructions SQL directement incorporées dans le code. En utilisant ces méthodes, on peut détecter les requêtes qui ne sont pas préparées et mettre en place des mesures pour les remplacer par des requêtes préparées afin d'améliorer les performances et la sécurité de la base de données. État de la technique On connaît dans l’état de la technique l’article Raymond Mui et Al. dans " Empêcher l'injection SQL par le nettoyage automatique des requêtes avec ASSIST " - Electronic Proceedings in Theoretical Computer Science, vol. 35, 17 septembre 2010, pp27-38 , décrit un procédé pour empêcher l'injection SQL, qui est provoquée lorsqu'un utilisateur transmet une entrée incorrecte à une base de données. La technique fournit un assainissement automatique des requêtes SQL grâce à l'utilisation d'une analyse statique et d'une transformation de programme. On connaît aussi l’article Baratloo et. Al. dans " Transparent run-time defense against smashing attack " - Actes de la conférence technique annuelle USENIX 2000 - 18-23 juin 2000 - San Diego, CA, USA, pp251-262, décrit l'atténuation des attaques contre les piles de processus avec une première méthode qui intercepte tous les appels aux fonctions de bibliothèque connues pour être vulnérables et une seconde méthode utilise la modification binaire de la mémoire de processus pour forcer la vérification des éléments critiques des piles avant utilisation. On connaît dans l’état de la technique le brevet américain délivré sous le numéro US9298924 décrivant un procédé mis en œuvre par ordinateur pour corriger automatiquement une vulnérabilité de sécurité dans un code source d'un programme informatique, le procédé comprenant les étapes suivantes : Identification, dans un code source d'un programme informatique, d'une vulnérabilité de sécurité sous la forme d'une partie de code qui envoie des données corrompues au code récepteur correspondant dans le code source ; Recherche de la partie de code qui envoie les données entachées contenant la création d'instruction ; Recherche du code correspondant qui crée une requête avec les données entachées ; Remplacement par un espace réservé une variable de la portion de code qui envoie les données corrompues ; Remplacement par un appel « prepareStatement » un appel « createStatment » correspondant à la portion de code qui envoie les données entachées ; Ajout d’un appel « setString » correspondant à la portion de code qui envoie les données entachées ; Suppression de l’argument de requête d'un « execute/executeQuery » dans la portion de code ; Détermination si la sortie de la partie de code qui contient la création d'instruction domine l'entrée dans le code récepteur qui crée la requête ; et si la sortie ne domine pas l'entrée, la correction automatique de la vulnérabilité de sécurité en effectuant automatiquement la modification du code en effectuant au moins l'une des Déplacement d’une partie de la portion de code vers un emplacement différent dans le code source et Copie d’une partie de la partie de code à un emplacement différent dans le code source dans le cadre de la modification du code source pour amener le code source à assainir les données corrompues avant que les données corrompues n'atteignent le code récepteur correspondant. On connaît aussi le brevet européen délivré sous le n° EP2092424 proposant un procédé mis en œuvre par ordinateur pour détecter des vulnérabilités de sécurité dans un programme informatique, comprenant les étapes consistant à : recevoir dans une mémoire le code source dudit programme informatique à analyser, ledit code source comprenant des éléments de code et des instructions, au moins une partie desdites instructions référençant des variables, dans lequel lesdites variables comprennent des structures de données ayant des variables membres, lesdites variables membres ayant les noms des membres ; construire, à l'aide d'un analyseur de code source s'exécutant sur un processeur, un modèle orienté objet dudit code source, dans lequel lesdits éléments de code sont représentés par des objets respectifs, dans lequel ladite construction d'un modèle orienté objet comprend l'attribution d'une instance unique des identifiants pour chacune desdites variables membres ; et en utilisant ledit modèle, construire au moins un graphe de flux de contrôle représentant un flux dudit programme informatique, stocker le modèle orienté objet dans une base de données orientée objet ; recevoir une requête de base de données de code source, dans un langage de requête de graphe de code prédéfini, concernant une vulnérabilité de sécurité dans laquelle un nom de membre d'une variable membre prédéterminée est identique audit nom de membre d'une autre variable membre ; analyser ledit au moins un graphe de flux de contrôle en réponse à ladite requête dans la base de données de code source afin d'identifier une partie dudit code source ayant ladite vulnérabilité de sécurité en identifiant des références à ladite variable membre prédéterminée en utilisant lesdits identificateurs d'instance uniques de celle-ci ; et signaler ladite faille de sécurité. Le brevet européen délivré sous le numéro EP3049988 décrit un procédé pour remédier automatiquement à des failles de sécurité, le procédé comprenant les étapes constituées par : la réception, en mémoire, d'un rapport d'analyse binaire statique pour un fichier binaire qui correspond à une application, le rapport identifiant une faille de sécurité dans une section du fichier binaire ; l'identification, par un processeur, sur la base, au moins en partie, du rapport reçu, de la section du fichier binaire qui correspond à la faille de sécurité, la section identifiée comprenant un premier segment de code binaire qui assure une fonctionnalité d'une manière non sécurisée ; la localisation d'un patch binaire de concordance qui comprend un second segment de code binaire qui assure une fonctionnalité d'une manière sécurisée et qui concorde avec la fonctionnalité qui est assurée par le premier segment de code binaire dans la section identifiée, à l'intérieur d'une bibliothèque de patchs ; la détermination de si oui ou non le remplacement, à l'intérieur du fichier binaire, de la section identifiée par le patch binaire de concordance devrait conduire à une modification au niveau d'une fonction du fichier binaire ; si aucune modification au niveau de la fonction n'est déterminée comme devant survenir, le remplacement de la section identifiée du fichier binaire par le patch de concordance; et sinon, la génération d'une notification consistant en ce que le remplacement devrait modifier la fonction. Inconvénients de l’art antérieur La présente invention vise à répondre à ces inconvénients. A cet effet l’invention concerne selon sa portée la plus générale un procédé de génération d’un développement informatique résistant aux attaques par injection SQL à partir d’un développement préexistant caractérisé en ce qu’il comporte les étapes suivantes : Sur une application exécutée sur un terminal, récupérer une archive .zip fournie par l’utilisateur à partir dudit développement préexistant Transfert desdits fichiers compressés à un serveur de traitement mutualisé par une session chiffrée Exécution par un programme installé sur le serveur pour Décompression chacun desdits fichiers transférés dans l’arborescence décrite dans le fichier compressé caractériser les requêtes d’un premier fichier par un analyseur qui consiste à extraire de chacun des fichiers les méthodes de manière à identifier et caractériser les requêtes en fonction de ce qu’elles sont déjà des requêtes préparées (en anglais prepared statements) ou non, par des traitements en boucle pour parcourir successivement les modèles successifs constituant le code source du fichier en cours de traitement, et pour chacun des modèles, une boucle secondaire imbriquée pour extraire et caractériser successivement toutes les séquences du modèle en cours de traitement dans la boucle principale, avant d’incrémenter la boucle principale pour passer au modèle suivant , L’étape suivante concernant la modification par un moteur d’intelligence artificielle des méthodes enregistrées ; consistant à constituer N lots de M méthodes à traiter, N étant supérieur 1 et NxM correspondant au plus proche entier supérieur au nombre de méthodes enregistrées dans ladite mémoire temporaire : Traitement en parallèle d’un premier lot de N méthodes par ledit moteur d’intelligence artificielle pour remplacer les valeurs du corps de la méthode par une requête préparée définissant explicitement la valeur et le typage de chaque paramètre de la méthode originelle Remplacement dans ledit fichier temporaire dans un fichier temporaire FTM du contenu de la méthode originelle par le contenu de la méthode modifiée à l’étape précédente En cas de défaut de modification, enregistrement de la méthode non modifiée dans ladite table des méthodes non traitées Enregistrement d’un fichier modifié à partir du fichier enregistré dans la mémoire MTFM correspondant au code enregistré avec remplacement desdits marqueurs par le nouveau contenu des méthodes modifiés lors de l’étape de traitement du lot considéré Mise à jour de la table des fichiers traités par la prise en compte horodatée des méthodes traités du lot considéré Retour à l’étape de traitement pour le lot suivant, jusqu’à la dernière méthode à traitée Compression du code enregistré dans la mémoire MTFM, et mise à disposition par l’utilisateur par un lien pour le transfert sécurisé vers le terminal client. L’objet de la présente invention peut également revêtir l’une ou une combinaison compatible des caractéristiques suivantes : Ladite étape de caractérisation des requêtes comprend les étapes suivantes : Traitement d’un premier fichier par un analyseur pour extraire une première méthode présente dans ledit fichier et récupération des informations comprenant la ligne de début, la ligne de fin, le nom et les informations de déclaration et le corps de ladite méthode Analyse syntaxique pour vérifier si ladite méthode contient une requête préparée Si la méthode ne contient pas de requête préparée, le nom et les informations de déclaration sont enregistrées dans une table des méthodes non traitées, et retour à l’étape précédente pour l’analyse syntaxique de la méthode suivante dudit fichier A défaut, balayage de l’ensemble du fichier source, jusqu’à la ligne de début de la méthode en cours d’analyse, enregistrement (a) dans une mémoire temporaire MTFM (mémoire temporaire des fichiers marqués) du code précédent ladite ligne de début, insertion d’un marqueur avec l’identification de ladite méthode à la place de ladite première ligne, omission de tout le code jusqu’à la ligne de fin de méthode, et enregistrement dans ladite mémoire temporaire, après ledit marqueur, de tout le reste du code dudit fichier dans ladite mémoire temporaire, et (b) enregistrement du corps de ladite méthode dans un fichier temporaire FTM avec un nom unique correspondant au nom du fichier, au nom de la méthode et aux informations dé déclaration et retour à l’étape précédente pour l’analyse syntaxique de la méthode suivante dudit fichier. 3. Après le traitement de toutes les méthodes d’un fichier, retour à l’étape pour l’analyse du fichier suivant, jusqu’au dernier fichier pour constituer une mémoire contenant la liste de toutes les méthodes à traiter pointant sur les corps enregistrés dans ledit fichier temporaire. Description d’exemple non limitatifs de réalisation La présente invention sera mieux comprise à la lecture de la description qui suit, concernant un exemple non limitatif de réalisation illustré par les dessins annexés où : La représente une vue schématique de l’architecture matérielle pour la modification automatique d’un développement informatique La représente une méthode Java/JDBC avant traitement La représente une méthode Java/JDBC après traitement par le moteur d’intelligence artificielle. Principe général dE l’invention Le but de l’invention est de proposer un procédé automatique de modification d’un développement informatique pour le rendre invulnérable aux attaques par injection SQL qui affectent les sites Web exploitant des bases de données. Ces attaques se produisent lorsqu’un malfaiteur exécute une requête SQL sur la base de données via les données entrantes du client au serveur. Des commandes SQL sont insérées dans la saisie du plan de données (par exemple, à la place du nom d’utilisateur ou du mot de passe) afin d’exécuter des commandes SQL prédéfinies. Un exploit d’injection SQL réussi peut lire les données sensibles de la base de données, modifier (insérer, mettre à jour ou supprimer) les données de la base de données, exécuter des opérations d’administration de la base de données (par exemple la fermer), récupérer le contenu d’un fichier spécifique, et, dans certains cas, envoyer des commandes au système d’exploitation. Par exemple, le formulaire Web d’un site Web peut demander le nom de compte d’un utilisateur, puis l’envoyer à la base de données afin d’extraire les informations de compte associées à l’aide de SQL dynamique, comme ceci : “SELECT * FROM users WHERE account = ‘“ + userProvidedAccountNumber +”’;” Même si cela fonctionne pour les utilisateurs qui saisissent correctement leur numéro de compte, cela laisse un passage aux attaquants. Si, par exemple, quelqu’un décidait de fournir un numéro de compte “‘ or ‘1’ = ‘1’”, cela donnerait une chaîne de requête comme celle-ci : “SELECT * FROM users WHERE account = ‘’ or ‘1’ = ‘1’;” Puisque ‘1’ = ‘1’ est toujours évalué comme TRUE, la base de données renvoie les données de tous les utilisateurs au lieu d’un seul. La vulnérabilité à ce type d’attaque informatique est liée au fait que SQL ne fait aucune distinction réelle entre le plan de contrôle et le plan de données. Pour cette raison, les injections SQL fonctionnent surtout si un site Web utilise SQL dynamique. De plus, les injections SQL sont très courantes avec les applications PHP, Python, J2EE/JDBC et ASP.NET, malgré la nature d’interfaces programmatiques qui permettent de fabriquer des requêtes préparées, mais ces interfaces ne sont pas systématiquement utilisées. Afin de protéger un développement informatique contre les attaques par injection SQL, une solution consiste à exclure toutes les procédures utilisant une requête de type SQL dynamique) pour n’utiliser que des requête préparées (requêtes paramétrées ou en anglais « prepared statement). Glossaire Les termes suivants auront, dans le présent brevet, la signification suivante : « Méthode » désigne dans le contexte de la programmation orientée objet (POO), une routine membre d'une classe, par exemple une méthode d'instance, n'agissant que sur un seul objet (instance de la classe) à la fois ou une méthode statique ou méthode de classe, indépendante de toute instance de la classe (objet). « Requête » désigne une séquence de caractères fonctionnelle, appelée en anglais « Statement » « mémoire » désigne un espace permettant d’écrire, la modification et la lecture dans un moyen physique, par exemple un disque dur ou une mémoire flash. Architecture matérielle La représente une vue schématique de l’architecture matérielle du système destinée à la modification automatique d’un développement informatique selon l’invention. L’utilisateur utilise un terminal informatique (10) qui échange des données sous un protocole sécurisé avec un serveur (20), par des sessions de type Https par exemple. Le serveur (20) est par exemple un serveur distribué dans le nuage (« Cloud » en anglais), échangeant des données avec un moteur d’intelligence artificielle (30). Ce moteur d’intelligence artificielle (30) peut être constitué par un réseau de neurones pré-entraîné exécuté par le serveur, ou un webservice extérieur qui n’est pas pré-entraîné. Traitement sur le terminal informatique (10) Le terminal informatique exécute une application informatique (11) spécifique à l’invention commandant l’interface utilisateur pour sélectionner le fichier (12) correspondant au développement originel présentant de potentielles failles de sécurité par attaque par Injection SQL et le transférer au serveur de traitement (20) via un protocole sécurisé. Le fichier originel (12) est généralement un fichier compressé de type .zip out tar.gz qui contient du code source C++, C#, GoLang, Java, JavaScript, Python ou PHP. Optionnellement, l’application (11) décompresse le fichier originel (12), vérifie si le code qu’il contient est compatible avec les traitements appliqués par le serveur (20), par exemple par une analyse sémantique pour vérifier si le code informatique correspond à un langage pris en compte par ces traitements, avant de recompiler le fichier originel (12). Le fichier originel (12) est ensuite transféré à l’application logicielle (21), exécutée sur le serveur (20) dans le Cloud, via une interface logiciel sous Windows™, macOS™ et Linux™. Après le traitement par le serveur (20), le fichier sécurisé (13) est transmis au terminal (10) et enregistré pour permettre son utilisation à la place du fichier originel (12). Traitement sur le serveur (20) L’application (11) décompresse le fichier et extrait tous les programmes sources pour enregistrer dans une mémoire temporaire du serveur (20) un ensemble de fichiers (22). Cette mémoire temporaire sera effacée à l’issue des traitements et après le transfert du fichier traité sur le terminal (10). L’application (22) commande ensuite une succession présentés ci-après. décomposition en méthodes Une première étape de caractérisation des requêtes consiste à extraire de chacun des fichiers les méthodes de manière à identifier et caractériser les requêtes en fonction de ce qu’elles sont déjà des requêtes préparées (en anglais prepareted statements) ou non. Cette première étape de caractérisation des requêtes consiste à appliquer des traitements en boucle pour parcourir successivement les modèles successifs constituant le code source du fichier en cours de traitement, et pour chacun des modèles, une boucle secondaire imbriquée pour extraire et caractériser successivement tous les séquences du modèle en cours de traitement dans la boucle principale, avant d’incrémenter la boucle principale pour passer au modèle suivant. Boucle principale d’analyse des modeles Dans cette boucle principale, le code informatique d’un fichier en cours de traitement fait l’objet d’une analyser pour identifier les modèles, c’est-à-dire les portions de code informatique définissant une routine. Cette analyse se fait par un analyseur sémantique de type connu, pour : reconnaître dans le code les séries de lignes de code correspondant à une méthode et détecter si la méthode en cours de traitement contient une requête préparée procéder à un traitement pour enregistrer dans une table un enregistrement EM i d’une entrée correspondant aux informations d’intérêt du modèle considéré, notamment : - la ligne de code de début de ladite méthode considérée - la ligne de code de fin de ladite méthode considérée - le nom et les informations de déclaration et le corps de ladite méthode considérée - le corps de ladite méthode. Si la méthode en cours d’analyse ne contient pas de requête préparée, le nom et les informations de déclaration sont enregistrées dans une table des méthodes non traitées, et retour à l’étape précédente pour l’analyse syntaxique de la méthode suivante dudit fichier. Boucle secondaire d’enregistrement des requetes à traiter Si la méthode en cours d’analyse contient une requête d’un type autre qu’une requête préparée, l’application commande l’exécution d’une boucle secondaire, pour préparer un fichier temporaire du code marqué, correspondant au code dont on extrait le corps des requêtes non préparées pour les remplacer par un marqueur temporaire, et une table des corps des requêtes qui seront ensuite traitées pour être réintroduite dans le corps marqué en remplacement de ces marqueurs temporaires. Ce traitement de la requête consiste à : isoler la partie du code avant et après le corps de la requête identifiée, pour enregistrer un code temporaire dans lequel le corps de la requête est remplacé provisoirement par un marqueur temporaire MARQ j permettant de réintroduire ensuite une requête préparée remplissant les mêmes fonctionnalités. Ce marqueur MARQ j est une séquence avec l’identification de la méthode associée. Par ailleurs, on procède à l’enregistrement du corps de cette méthode dans un fichier temporaire FTM avec un nom unique correspondant au nom du fichier, au nom de la méthode et aux informations dé déclaration et retour à l’étape précédente pour l’analyse syntaxique de la méthode suivante dudit fichier, et le lien avec le marqueur MARQ j . Procéder à l’enregistrement dans une mémoire temporaire MTFM (mémoire temporaire des fichiers marqués) de toutes les lignes de code du fichier précédent ladite ligne de début suivi par un marqueur inséré après ces lignes, le marqueur étant une séquence avec l’identification de ladite méthode à la place de ladite première ligne, omission de tout le code jusqu’à la ligne de fin de méthode, et enregistrement dans ladite mémoire temporaire, après ledit marqueur, de tout le reste du code dudit fichier dans ladite mémoire temporaire MTFM (mémoire temporaire des fichiers marqués). On traite ainsi de manière récursive toutes les requêtes d’une méthode par la boucle secondaire et toute les méthodes de chacun des fichiers par la boucle principale. Après le traitement de toutes les méthodes d’un fichier, retour à l’étape pour l’analyse du fichier suivant, jusqu’au dernier fichier pour constituer une mémoire contenant la liste de toutes les méthodes à traiter pointant sur les corps enregistrés dans ledit fichier temporaire. Traitement des méthodes isolées Les corps des méthodes à traiter enregistrées dans le fichier temporaire font ensuite l’objet d’un traitement par un moteur d’intelligence artificielle pour produire un fichier comprenant les corps de méthodes reconstruites en mode de requêtes préparées. Par exemple, une méthode Java/JDBC avant traitement illustrée par la deviendrait après traitement par le moteur d’intelligence artificielle une méthode illustrée par la . Toutefois, la taille du fichier ne permet pas un traitement de l’ensemble des méthodes par un seul traitement, et l’invention prévoit l’extraction de sous-ensembles de méthodes à traiter, pour un traitement par un même moteur d’intelligence artificielle en mode série-parallèle, par N lots comprenant M méthodes chacun, N et M étant des nombres entiers supérieurs à 1, avec NxM correspondant au plus proche entier supérieur au nombre de méthodes enregistrées dans ladite mémoire temporaire de telle sorte que le dernier traitement porte sur un nombre de méthodes correspondant au reste de méthodes à traiter. Le procédé prévoit : le traitement en parallèle d’un premier lot de N méthodes par ledit moteur d’intelligence artificielle pour remplacer les valeurs du corps de la méthode par une requête préparée définissant explicitement la valeur et le typage de chaque paramètre de la méthode originelle. Le remplacement dans ledit fichier temporaire dans un fichier temporaire FTM du contenu de la méthode originelle par le contenu de la méthode modifiée à l’étape précédente En cas de d’échec de modification, enregistrement de la méthode non modifiée dans ladite table des méthodes non traitées L’enregistrement d’un fichier modifié à partir du fichier enregistré dans la mémoire MTFM correspondant au code enregistré avec remplacement desdits marqueurs par le nouveau contenu des méthodes modifiés lors de l’étape de traitement du lot considéré La mise à jour de la table des fichiers traités par la prise en compte horodatée des méthodes traités du lot considéré Le retour à l’étape de traitement pour le lot suivant, jusqu’à la dernière méthode à traiter. Transfert du code sécurisé Le code modifié enregistré dans la mémoire MTFM est ensuite compressé et mise à disposition par l’utilisateur par un lien pour le transfert sécurisé vers le terminal client. Procédé de génération d’un développement informatique résistant aux attaques par injection SQL à partir d’un développement préexistant caractérisé en ce qu’il comporte les étapes suivantes : Sur une application exécutée sur un terminal, récupérer une archive .zip fournie par l’utilisateur à partir dudit développement préexistant Transfert desdits fichiers compressés à un serveur de traitement mutualisé par une session chiffrée Exécution par un programme installé sur le serveur pour Décompression de chacun desdits fichiers transférés dans l’arborescence décrite dans le fichier compressé caractériser les requêtes d’un premier fichier par un analyseur qui consiste à extraire de chacun des fichiers les méthodes de manière à identifier et caractériser les requêtes en fonction de ce qu’elles sont déjà des requêtes préparées (en anglais prepared statements) ou non, par des traitements en boucle pour parcourir successivement les modèles successifs constituant le code source du fichier en cours de traitement, et pour chacun des modèles, une boucle secondaire imbriquée pour extraire et caractériser successivement toutes les séquences du modèle en cours de traitement dans la boucle principale, avant d’incrémenter la boucle principale pour passer au modèle suivant , L’étape suivante concernant la modification par un moteur d’intelligence artificielle des méthodes enregistrées ; consistant à constituer N lots de M méthodes à traiter, N étant supérieur 1 et NxM correspondant au plus proche entier supérieur au nombre de méthodes enregistrées dans ladite mémoire temporaire : Traitement en parallèle d’un premier lot de N méthodes par ledit moteur d’intelligence artificielle pour remplacer les valeurs du corps de la méthode par une requête préparée définissant explicitement la valeur et le typage de chaque paramètre de la méthode originelle Remplacement dans ledit fichier temporaire dans un fichier temporaire FTM du contenu de la méthode originelle par le contenu de la méthode modifiée à l’étape précédente En cas de défaut de modification, enregistrement de la méthode non modifiée dans ladite table des méthodes non traitées Enregistrement d’un fichier modifié à partir du fichier enregistré dans la mémoire MTFM correspondant au code enregistré avec remplacement desdits marqueurs par le nouveau contenu des méthodes modifiés lors de l’étape de traitement du lot considéré Mise à jour de la table des fichiers traités par la prise en compte horodatée des méthodes traités du lot considéré Retour à l’étape de traitement pour le lot suivant, jusqu’à la dernière méthode à traitée Compression du code enregistré dans la mémoire MTFM, et mise à disposition par l’utilisateur par un lien pour le transfert sécurisé vers le terminal client. Procédé de génération d’un développement informatique résistant aux attaques par injection SQL à partir d’un développement préexistant selon la revendication 1 caractérisé en ce que ladite étape de caractérisation des requêtes comprend les étapes suivantes : Traitement d’un premier fichier par un analyseur pour extraire une première méthode présente dans ledit fichier et récupération des informations comprenant la ligne de début, la ligne de fin, le nom et les informations de déclaration et le corps de ladite méthode Analyse syntaxique pour vérifier si ladite méthode contient une requête préparée Si la méthode ne contient pas de requête préparée, le nom et les informations de déclaration sont enregistrées dans une table des méthodes non traitées, et retour à l’étape précédente pour l’analyse syntaxique de la méthode suivante dudit fichier A défaut, balayage de l’ensemble du fichier source, jusqu’à la ligne de début de la méthode en cours d’analyse, enregistrement (a) dans une mémoire temporaire MTFM (mémoire temporaire des fichiers marqués) du code précédent ladite ligne de début, insertion d’un marqueur avec l’identification de ladite méthode à la place de ladite première ligne, omission de tout le code jusqu’à la ligne de fin de méthode, et enregistrement dans ladite mémoire temporaire, après ledit marqueur, de tout le reste du code dudit fichier dans ladite mémoire temporaire, et (b) enregistrement du corps de ladite méthode dans un fichier temporaire FTM avec un nom unique correspondant au nom du fichier, au nom de la méthode et aux informations dé déclaration et retour à l’étape précédente pour l’analyse syntaxique de la méthode suivante dudit fichier Après le traitement de toutes les méthodes d’un fichier, retour à l’étape pour l’analyse du fichier suivant, jusqu’au dernier fichier pour constituer une mémoire contenant la liste de toutes les méthodes à traiter pointant sur les corps enregistrés dans ledit fichier temporaire.