Un mardi soir, 22h. Le telephone sonne : « Mon site affiche une page blanche, la base de donnees est vide. » Trois ans de commandes, 2000 clients, 15000 produits, et aucune sauvegarde recente. Les logs ont fini par parler : un plugin de galerie non mis a jour depuis 2021, une CVE de 2023, une injection SQL pour lire les tables, puis un DROP TABLE sur l’ensemble de la base. Quatre minutes, montre en main. Cette nuit-la, seuls les journaux binaires MySQL actifs par defaut ont permis de rejouer l’historique et de recuperer 99,8 % des donnees. Cet article reprend les sept failles les plus courantes du web, alignees sur l’OWASP Top 10, en insistant sur ce qui compte vraiment : la remediation defensive.
Le constat est sobre. La majorite des intrusions n’exploitent pas une faille exotique mais une combinaison de basiques negliges : une entree non validee, une sortie non echappee, un composant obsolete, une configuration laissee a sa valeur de demonstration. Comprendre le mecanisme de chaque vulnerabilite, mesurer son impact, puis appliquer un correctif concret : c’est cette discipline, repetee, qui distingue un site resilient d’une cible facile. Chacune des sections qui suit traite une categorie majeure et se termine par des mesures applicables des aujourd’hui par un developpeur ou un administrateur.
Broken Access Control : la faille numero un
En tete de l’OWASP Top 10, le controle d’acces defaillant survient lorsqu’un utilisateur accede a une ressource ou une action qui devrait lui etre interdite. Le cas le plus repandu reste l’IDOR (Insecure Direct Object Reference) : une URL du type /facture?id=1043 que l’on modifie en 1044 pour lire la facture d’un autre client, parce que le serveur ne verifie jamais que la ressource appartient bien a la session courante. S’y ajoutent les endpoints d’administration accessibles sans role, les verifications faites cote client seulement, ou les API qui renvoient plus de champs que necessaire.
L’impact va de la fuite de donnees personnelles a l’elevation de privileges complete. La remediation repose sur un principe simple mais exigeant : refuser par defaut, autoriser explicitement. Toute requete sensible doit verifier, cote serveur, que l’identite authentifiee possede le droit precis sur l’objet precis demande. On applique le principe du moindre privilege a chaque role, on centralise la logique d’autorisation plutot que de la disperser dans les controleurs, et on prefere des identifiants non devinables (UUID) aux entiers sequentiels. Enfin, on journalise les acces refuses : un pic de 403 trahit souvent une enumeration en cours.
Injection SQL : requetes parametrees, toujours
Presente dans le Top 10 depuis 1998, l’injection survient quand une donnee fournie par l’utilisateur est interpretee comme du code par un interpreteur. Le SQL en est l’illustration classique : concatener une saisie dans une requete permet de detourner sa logique, de lire des tables entieres, voire de detruire la base, exactement le scenario du DROP TABLE evoque en introduction. Le meme principe vaut pour les commandes systeme, le LDAP ou les requetes NoSQL. La cause est toujours la confusion entre instructions et donnees.
La parade est connue et non negociable : les requetes parametrees, ou requetes preparees. Le moteur recoit d’un cote la structure de la requete, de l’autre les valeurs, qui ne sont jamais interpretees comme du code. On y ajoute la validation d’entree par liste blanche, un compte de base limite au strict necessaire, et l’usage d’un ORM correctement configure. Voici le contraste fondamental, a graver dans toute base de code :
// VULNERABLE : concatenation directe d'une entree utilisateur
$query = "SELECT * FROM users WHERE id = " . $_GET['id'];
// CORRECT : requete parametree avec PDO
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$_GET['id']]);
// CORRECT : sous WordPress avec wpdb
$stmt = $wpdb->prepare("SELECT * FROM users WHERE id = %d", $id);XSS : echapper systematiquement les sorties
Le Cross-Site Scripting (XSS) consiste a injecter du code, le plus souvent JavaScript, qui s’executera dans le navigateur d’autres visiteurs. La variante stockee est la plus grave : un commentaire ou un champ de profil contenant du script est enregistre puis reaffiche tel quel a chaque consultation. La variante reflechie renvoie immediatement une entree non echappee dans la reponse. Les consequences vont du vol de cookies de session au detournement complet du compte administrateur, en passant par le defacement et la propagation de logiciels malveillants.
La regle d’or est l’echappement contextuel a la sortie : toute donnee dynamique doit etre encodee selon l’endroit ou elle est inseree (corps HTML, attribut, URL, JavaScript). Sous WordPress, on dispose de esc_html(), esc_attr() et esc_url() ; en PHP natif, htmlspecialchars() avec le drapeau ENT_QUOTES. On complete par une validation des entrees et, surtout, par une politique de securite du contenu (Content-Security-Policy) qui interdit l’execution de scripts non autorises. Cet en-tete agit comme une seconde ligne de defense si un echappement venait a manquer :
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'CSRF : des jetons anti-falsification
La falsification de requete intersites (CSRF) abuse de la confiance qu’un site accorde au navigateur d’un utilisateur authentifie. Si une action sensible (changer un mot de passe, virer des fonds, supprimer un contenu) repose uniquement sur la presence du cookie de session, un site malveillant peut declencher cette action a l’insu de la victime, simplement en la poussant a charger une page piegee pendant qu’elle est connectee. L’attaque ne lit pas la reponse mais provoque un effet de bord, ce qui suffit a faire des degats.
La remediation classique consiste a exiger, pour chaque action mutatrice, un jeton anti-CSRF imprevisible, lie a la session et verifie cote serveur. Sous WordPress, ce role est tenu par les nonces : wp_nonce_field() dans le formulaire et check_admin_referer() au traitement. On renforce le tout avec l’attribut SameSite sur le cookie de session, qui empeche son envoi lors de requetes intersites, et l’on reserve les operations sensibles a la methode POST. Un cookie de session bien durci combine plusieurs protections en une ligne :
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/SSRF : maitriser les requetes sortantes du serveur
La falsification de requete cote serveur (SSRF) entree dans le Top 10 vise les fonctionnalites qui font emettre au serveur une requete reseau vers une URL fournie par l’utilisateur : import d’image distante, generation de PDF a partir d’une page, webhook, previsualisation de lien. En manipulant cette URL, un attaquant peut faire interroger des ressources internes inaccessibles depuis l’exterieur : services d’administration, bases de donnees, ou les endpoints de metadonnees des fournisseurs cloud, mine d’informations sensibles comme des jetons d’acces.
La defense la plus robuste est une liste blanche : n’autoriser que des domaines ou des plages d’adresses explicitement approuves, plutot que de tenter de bloquer ce qui est dangereux. On valide et on normalise l’URL avant toute requete, on resout le nom de domaine et l’on verifie que l’adresse obtenue n’appartient pas a une plage privee ou de bouclage, on desactive les redirections automatiques et les protocoles inutiles (file://, gopher://). Au niveau reseau, une segmentation stricte et des regles de pare-feu sortant limitent la portee d’une eventuelle exploitation.
Mauvaise configuration et authentification defaillante
La mauvaise configuration de securite est l’une des categories les plus frequentes car elle ne demande aucune erreur de code : comptes par defaut laisses actifs, message d’erreur verbeux exposant la pile d’appel, repertoires listables, services inutiles ouverts, en-tetes de securite absents. Dans la source, l’exposition de donnees via un WP_DEBUG reste a true en production illustre parfaitement ce risque : les chemins, les requetes et parfois les identifiants se retrouvent affiches a l’ecran. La regle est de durcir par defaut, de desactiver tout ce qui n’est pas indispensable et de journaliser les erreurs dans un fichier, jamais vers le client.
L’authentification defaillante prolonge le probleme : mots de passe courts ou reutilises, absence de second facteur, sessions qui n’expirent jamais, tentatives de connexion illimitees ouvrant la voie au bourrage d’identifiants. On impose des phrases de passe longues (16 caracteres et plus), une authentification a deux facteurs pour tous les comptes a privileges, une limitation et un ralentissement des tentatives, et l’on stocke les mots de passe avec un algorithme adapte comme bcrypt ou Argon2. On complete par des en-tetes HTTP de securite (HSTS, X-Frame-Options, X-Content-Type-Options) qui ferment plusieurs vecteurs d’attaque d’un coup.
Composants vulnerables et validation des uploads
Les composants vulnerables et obsoletes constituent une categorie a part entiere du Top 10, et c’est exactement la breche qui a permis l’intrusion racontee en ouverture : une dependance non mise a jour, une CVE publique, un exploit pret a l’emploi. Une application moderne agrege des dizaines de bibliotheques transitives ; chacune est une surface d’attaque potentielle. La remediation tient dans une hygiene reguliere : inventaire des dependances, veille sur les CVE, et application sans delai des correctifs. Les commandes npm audit, composer audit et wp plugin list --update=available doivent tourner chaque semaine, idealement automatisees dans la chaine d’integration.
L’upload de fichiers non filtre, enfin, illustre l’importance de la validation d’entree appliquee au-dela du texte. Se fier a l’extension ne protege de rien : un fichier nomme image.jpg peut contenir du code executable. On verifie donc le type MIME reel avec finfo, on impose une liste blanche d’extensions et de types attendus, on regenere un nom de fichier neutre, on stocke les depots hors de la racine web et sans droit d’execution. Pris ensemble, ces sept chantiers ne relevent pas d’un projet ponctuel mais d’une discipline continue : validation des entrees, echappement des sorties, moindre privilege, mise a jour et journalisation forment la colonne vertebrale d’une defense durable.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.