Une « faille » rendrait WordPress vulnérable à une attaque DoS
Le 06 février 2018 à 09h15
1 min
Internet
Internet
Le chercheur en sécurité Barak Tawily affirme avoir identifié une faille dans WordPress. Via une attaque DoS (déni de service), elle permet de faire tomber n'importe quel site basé sur ce CMS.
Il explique que la brèche se trouverait dans le fichier « load-scripts.php » et qu'elle concernerait toutes les versions de WordPress (toutes les explications techniques se trouvent par ici, avec une vidéo par là).
Barak Tawily a contacté WordPress via son programme de bug bounty (via HackerOne). Sans s'attendre à une récompense, il espérait visiblement que la société proposerait une mise à jour, mais ce ne fut pas le cas.
Voici la réponse qu'il aurait obtenue : « Ce genre de chose devrait vraiment être atténué au niveau du serveur ou du réseau plutôt qu'au niveau de l'application, hors du contrôle de WordPress ».
Le chercheur propose donc sa propre solution pour atténuer le problème. WordPress n'a pas encore réagi publiquement à cette histoire.
Le 06 février 2018 à 09h15
Commentaires (8)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 06/02/2018 à 09h40
Ce CMS… c’est failles sur failles depuis trop longtemps maintenant.
Ils en sont où de la refonte du core ?
Parce que là, avec le nombre de sites sous Wordpress, ça devient une aberration en terme de sécurité ce CMS. Y a vraiment besoin d’un lifting en profondeur.
Le 06/02/2018 à 10h50
ce n’est pas très méchant comme faille. Un peu près tous les sites peuvent être DDOS. Ici Wordpress l’aide un peu c’est tout.
C’est surtout la réponse de l’équipe Wordpress qui fait peur.
Le 06/02/2018 à 11h20
Tu confonds DDOS et DOS. Ici on parle de simple DOS
Le 06/02/2018 à 13h01
Sincèrement, en 2018, proposer cette “qualité” de code dans une solution aussi implantée de par le monde, c’est une honte.
J’ai lâché l’affaire il y a longtemps, mais même récemment pour migrer une instance d’un domaine à l’autre fallait faire du search & replace dans le fichier de dump SQL. Ah, certaines configurations étaient sérialisées en PHP et donc ça a foutu la merde ? MAIS WTF ?!
Et je ne parle pas des fonctions dans tous les sens, on te les préfixe avec un underscore - c’est public ou privé - on ne sait pas réellement, de classe de temps en temps, de l’autre on te mixe du camel case et snake case, on te mets des méthodes API fourre-tout, des objet en global, des filter obscurs, etc.
Bref, je n’ai rien à dire sur l’expérience utilisateur qui est top et une documentation et communauté qui semble à la hauteur, mais le cœur technique faut réellement faire le ménage.
Le système de plugin est vraiment trop permissif (cf les vulnérabilités sur les plugin tiers).
Puis sincèrement la (non) réaction de l’éditeur, ça donne pas envie de mettre ses billes dans sa solution.
Le 06/02/2018 à 13h37
C’est du bullshit tout ça !
Un simple système de cache règle le problème. En plus aujourd’hui la l=plupart des hébergeurs proposent un système anti-DOS.
Ce sont les 10k requêtes qui rendent son serveur indisponible, pas le fait de télécharger un script de 4 Mo.
Le 06/02/2018 à 17h50
Le 07/02/2018 à 08h16
Le 07/02/2018 à 15h28