Le SAST expliqué simplement

Vous avez déjà donné un faux prénom au barista, juste pour l'entendre le crier dans tout le café ?
Félicitations : vous avez compris, sans le savoir, la faille la plus célèbre de l'informatique.

Pour repérer les failles dans les instructions du programme, on fait du SAST (Static Application Security Testing, ou test de sécurité statique) : un outil qui relit le codecode : le texte du programme, écrit par les développeurs d'une application, sans la lancer, pour y repérer les faillesfailles : une erreur dans un logiciel qu'un attaquant peut utiliser pour lui faire faire ce qu'il ne devrait pas avant la mise en ligne.

Vous allez comprendre ce que cet outil peut repérer, ce qui lui échappe et quelles questions poser à votre équipe.

Astuce : les mots soulignés en pointillé ont une définition. Passez la souris dessus, ou touchez-les sur un téléphone.

Le barista trop obéissant

Dans un café à emporter, on vous demande votre prénom. Le barista l'écrit au feutre sur le gobelet, puis le crie au comptoir quand la boisson est prête.

Imaginez maintenant un barista qui applique sa consigne comme une machine : il crie « Servez les commandes de », suivi de ce qui est écrit sur le gobelet. Mot pour mot. Sans réfléchir. Regardez la scène, en trois actes :

Avec un barista humain, c'est une blague. Avec un programme, qui ne réfléchit pas, c'est une faille.

C'est ça, une injection :ce que vous avez écrit n'a pas été traité comme un prénom, mais comme une partie de l'ordre.

Dans une vraie application, le comptoir est la base de donnéesbase de données : le logiciel qui range et retrouve les informations de l'application : clients, factures…, et la phrase criée est une question écrite dans un langage appelé SQL. L'attaquant n'écrit pas « et toutes les commandes », mais une formule de quelques caractères qui produit le même effet.

D'où le nom : une injection SQLinjection SQL : une attaque où un texte tapé sur un site est pris pour un ordre par la base de données.

La parade est la même qu'au comptoir : la question part d'un côté, le texte du visiteur de l'autre, dans sa case. Les développeurs appellent ça une requête paramétréerequête paramétrée : une question envoyée à la base où la saisie du visiteur est transmise à part, comme une simple valeur. L'article approfondi la décortique ligne par ligne, avec une démo à essayer.

Les informaticiens ont même leur blague culte sur le sujet : la bande dessinée xkcd n° 327 (2007), où une mère appelle son fils « Robert'); DROP TABLE Students;-- ». Traduction : « Robert, et efface la liste des élèves ».

L'école a perdu toutes ses fiches.
Depuis, on le surnomme Little Bobby Tables.

Plus d'un quart de siècle

On croirait cette faille réservée aux sites des années 2000, compteur de visites et GIF qui clignote compris. Raté :

1. 1998
   La première description publique.

   Un chercheur qui signe « rain.forest.puppy » explique dans le magazine Phrack comment glisser des ordres dans les questions envoyées à une base de données. Le mode d'emploi est public depuis.

2. 2008
   Heartland : 130 millions de cartes bancaires.

   Une équipe menée par Albert Gonzalez entre chez Heartland Payment Systems, qui traite des paiements par carte, par une injection SQL, puis installe de quoi intercepter les numéros de carte. Avec quelques autres victimes du même groupe, plus de 130 millions de numéros de cartes sont volés.

   Gonzalez prendra vingt ans de prison.
   Et un jour, précise le jugement.

3. 2015
   TalkTalk : des pages oubliées.

   L'opérateur britannique se fait voler les données d'environ 157 000 clients via une injection SQL dans de vieilles pages web que plus personne ne surveillait. Parmi les attaquants, des adolescents.

   Le régulateur britannique inflige une amende record pour l'époque : 400 000 livres.

4. 2023
   MOVEit : une faille, 2 000 victimes.

   Fin mai 2023, le groupe criminel Cl0p exploite une injection SQL dans MOVEit Transfer, un logiciel d'échange de fichiers utilisé par des milliers d'entreprises et d'administrations. Bilan : plus de 2 000 organisations touchées, et les données de dizaines de millions de personnes volées.

   En un seul coup.

5. 2025
   FortiWeb : même les gardiens.

   Une injection SQL est découverte dans FortiWeb, un pare-feu applicatif de Fortinet, dont le métier est justement de bloquer… les injections SQL. Des attaquants l'exploitent quelques jours après la publication du correctifcorrectif : la mise à jour qui répare la faille.

Le point commun :aucune de ces failles n'est exotique. À chaque fois, une saisie venue de l'extérieur modifie l'ordre envoyé à la base. En 2024, l'agence américaine de cybersécurité et le FBI ont même publié une alerte pour demander aux éditeurs d'en finir avec les injections SQL.
Vingt-cinq ans après le mode d'emploi.

Comment un SAST repère le danger

Un SAST ne lance pas l'application et n'essaie aucune attaque. Il lit le code, comme un relecteur très patient, et cherche un chemin dangereux en trois étapes :

Pour suivre ce chemin, l'outil fait une chose très simple dans l'idée : il met une goutte d'encre sur tout ce qui vient de l'extérieur, et regarde où l'encre se diffuse. Si elle atteint une opération sensible sans être passée par une case à part, il peut signaler le chemin qu'il a su reconstituer.

Les spécialistes appellent ça l'analyse de tainttaint : « contamination » en anglais : on marque la donnée venue de l'extérieur et on suit où elle se répand dans le programme. Encore faut-il que l'outil sache modéliser chaque étape du trajet.

C'est un peu le correcteur orthographique de la sécurité : il relit chaque ligne, à chaque modification, sans jamais se lasser ni partir en pause café. Et comme le correcteur orthographique, il souligne parfois un mot correct, et laisse passer une faute qu'il ne connaît pas.

Bon, concrètement, un SAST trouve quoi ?

Le prénom collé dans l'ordre n'est que la star de la famille. Un SAST cherche aussi ses cousins :

• Un texte tapé qui devient un ordre.Comme au comptoir du café. Les spécialistes parlent d'injectioninjection : quand une saisie est prise pour une instruction par le programme, et elle ne vise pas que les bases de données : une commande système peut être piégée de la même façon. Cousin proche : un nom de fichier mal vérifié qui permet d'ouvrir n'importe quel fichier du serveur.
• Une page qui piège ses visiteurs.Un attaquant glisse un petit programme dans un commentaire ; il s'exécute dans le navigateurnavigateur : le logiciel qui affiche les sites web : Chrome, Firefox, Safari… de chaque lecteur et peut voler sa sessionsession : la connexion ouverte du lecteur sur le site, qui permet d'agir à sa place. On parle de XSSXSS : cross-site scripting : un attaquant glisse un script dans une page que d'autres visiteurs ouvriront.
• Un colis piégé.L'application déballe des données préparées par un inconnu, ce qui peut déclencher des actions que personne n'avait prévues, jusqu'à exécuter du code. On parle de désérialisationdésérialisation : la reconstruction d'un objet du programme à partir de données reçues.
• Des secrets mal protégés.Un mot de passe écrit en clair dans le code, ou un chiffrement que l'on sait casser depuis des années.
• Des protections coupées.Une connexion chiffréeconnexion chiffrée : une connexion protégée pour que personne ne puisse lire ce qui y passe qui ne vérifie plus à qui elle parle : comme confier une lettre recommandée à quiconque se dit facteur.

Et ce qu'il ne sait pas faire : comprendre ce que l'application est censée faire. Il voit qu'une saisie finit dans un ordre, pas qu'un client ne devrait jamais voir la facture d'un autre.

Corriger : la bonne case, pas le pansement

Face à une alerte, la tentation est grande de colmater : interdire les virgules, refuser les apostrophes, bloquer le mot « DROP ».
C'est le pansement.

Ça bloque une ruse précise, jamais toutes, et ça finit par gêner les vrais clients (bonjour à toutes les personnes qui s'appellent O'Brien ou N'Diaye et que des formulaires refusent).

La vraie correction se fait en quatre temps :

1. Étape 1

   Comprendre le chemin : d'où vient la saisie, et où elle est collée.

2. Étape 2

   Corriger là où elle est collée : la case à part pour les valeurs. Et pour ce qui ne rentre pas dans une case, comme le nom d'une colonne de tri, une liste de valeurs autorisées.

3. Étape 3

   Ajouter un test qui rejoue l'attaque et vérifie qu'elle ne change plus rien, pour que cette faille-là ne revienne pas en douce.

4. Étape 4

   Relancer l'analyse, puis mettre la nouvelle version en service. Tant que ce n'est pas fait, vos visiteurs utilisent toujours l'ancienne.

À retenir :qu'elle vienne d'un humain ou d'une IA, une correction suit le même parcours. Une IA peut très bien proposer le pansement : rapide, propre en apparence, et insuffisant. Vérifiez qu'elle supprime la cause.

Toutes les alertes ne se valent pas

Une injection dans la page de connexion d'un site ouvert à tous et une injection dans un outil interne qui sert trois personnes le premier lundi du mois, ce n'est pas la même urgence. Pour trier, on revient à la vieille formule des gestionnaires de risque :

Dernier point : la confiance dans l'alerte compte aussi. Une alerte encore incertaine sur une page publique mérite une vérification rapide.

Et quand l'outil se trompe

Comme tout outil de détection, un SAST peut se tromper dans les deux sens. Pensez à un test médical : « positif » veut dire « l'outil a trouvé quelque chose ».

Un faux positiffaux positif : une alerte qui signale un problème qui n'existe pas coûte cher : quelqu'un doit le lire, comprendre et trancher. Une équipe noyée sous les fausses alarmes finit par ne plus lire les rapports, et c'est là que la vraie faille passe, au milieu du bruit.

D'où viennent-elles ?

• Une protection que l'outil ne voit pas.Le programme n'accepte qu'un nombre, mais l'outil ne repère pas cette vérification et voit seulement « une saisie, collée dans une question ».
• Une valeur qui ne vient pas de l'extérieur.Un mot écrit en dur dans le code, comme le nom d'une table : aucun visiteur ne peut le changer.
• Un chemin impossible.Le code dangereux existe, mais aucun point d'entrée (page, API, tâche planifiée) ne permet d'y arriver, vérification faite.

Et les faux négatifsfaux négatifs : une vraie faille que l'outil n'a pas signalée, les plus dangereux, viennent surtout d'un fichier que l'outil n'a pas su lire, d'un détour trop long qu'il a perdu en route, ou d'un outil de développement qu'il ne connaît pas. Un bon SAST se juge donc à deux choses : le temps qu'il faut pour trancher chaque alerte (il doit montrer le chemin complet), et l'honnêteté de son rapport sur ce qu'il n'a pas lu.

Ce que le SAST ne couvre pas à lui seul

Un SAST relit d'abord le code écrit par votre équipe, Pour le reste, il faut d'autres outils :

Et surtout, aucune de ces analyses ne connaît vos règles métier. Exemple : un site remet la commande n° 42 à quiconque tape 42 dans l'adresse de la page.

Rien n'est collé dans un ordre, la plupart des outils restent muets (certains repèrent des contrôles d'autorisation manquants, aucun ne connaît vos règles), et pourtant n'importe qui peut lire la facture du voisin en changeant un chiffre dans l'adresse de la page. Qui a le droit de voir quoi, seul vous le savez : il faut l'écrire dans le code, et le tester.

À vous de jouer : coup de feu au comptoir

Vous avez maintenant toutes les cartes en main : on passe derrière le comptoir. Vous tenez le Café du Tamis pendant cinq jours.

Le personnel applique les fiches de consignes à la lettre, comme un programme, et chaque matin l'outil d'analyse vous rend son rapport. À vous de décider quoi en faire : chaque choix protège vos clients… ou vous fait perdre votre journée.

Morale de l'histoire : l'outil peut suivre les détours qu'il sait modéliser. Choisir la bonne correction, écarter une fausse alerte avec une preuve et relire ce qu'il ne sait pas lire, c'est là que tout se joue.

Petit quiz

Les questions qu'on se pose

Pour conclure

Une injection, c'est une saisie qui finit dans un ordre, comme le prénom crié tel quel au comptoir. Un SAST relit le code pour repérer ce chemin avant la mise en ligne, mais il ne voit ni ce qu'il n'a pas lu ni vos règles métier. Gardez trois réflexes : une analyse à chaque modification, une décision écrite pour chaque alerte, et des tests sur qui a le droit de voir quoi.

Les mots de cet article · 10 mots

SAST

Static Application Security Testing : l'analyse du code d'une application, sans l'exécuter, pour y trouver des failles.

Injection

Une faille où une saisie du visiteur est exécutée comme une instruction.

SQL

Le langage utilisé pour interroger une base de données.

Requête paramétrée

Une question où la saisie est transmise à part, comme une simple valeur : la case à part.

Taint

« Contamination » : le suivi d'une donnée venue de l'extérieur jusqu'à une opération sensible.

Faux positif / faux négatif

Une alerte sur du code sûr / une vraie faille que l'outil n'a pas trouvée.

Source

L'entrée, là où arrive ce que tape l'utilisateur (le gobelet).

Sink

L'opération sensible, là où la donnée devient dangereuse (le comptoir).

Sanitizer

Ce qui neutralise une donnée pour une opération précise. La case à part fait encore mieux : la donnée arrive, mais ne peut plus changer la question.

Couverture

La part du code que l'outil a réellement analysée.

Lire ensuite : SAST en profondeur : moteurs, taint et limites