Sécurité de WordPress : surveillez votre API Rest

WordPress étant l'un des CMS les plus populaires au monde, il est une cible privilégiée pour les hackers tant la portée de la découverte d'une nouvelle faille peut être grande. Les attaques automatisées sont légions, ce que n'importe quel webmaster a déjà dû remarquer en explorant les logs des requêtes HTTP reçues par son serveur.

Se protéger des attaques automatisées

Pas de panique cependant, si vous respectez les bonnes pratiques en terme d'hébergement, de mise à jour du CMS et de ses plugins ainsi qu'en limitant le nombre de ces derniers, vous êtes déjà bien mieux équipé qu'une grande partie des utilisateurs de WordPress et donc hors de portée de la majorité des attaques non-ciblées.

Mais une attaque ce n'est pas qu'un assemblage de failles techniques. C'est avant tout et surtout de la reconnaissance, de la récupération d'informations puis leur exploitation.

Les données exposées via l'API de WordPress

Et si je vous disais qu'un intrus se cachait au cœur même de WordPress et avait le potentiel d'exposer vos secrets les mieux gardés ?

Depuis la version 4.7.0 de WordPress, celui-ci est livré avec une API Rest qui permet la récupération des contenus accessibles aux utilisateurs anonymes, mais aussi d'effectuer des opérations de type CRUD sur les ressources du CMS une fois authentifié.

Véritable pas en avant à l'époque de sa sortie, l'API Rest fait aujourd'hui partie intégrante de WordPress et est utilisée par un grand nombre de plugins. C'est elle également qui fournit les données nécessaires au fonctionnement de Gutenberg.

Seulement voilà, même si celle-ci est bien pratique, elle est souvent ignorée par les développeurs lors de développements de features d'autorisation pouvant faire fuiter des données devant être protégées.

Partons ensemble pour un petit tour d'horizon des points à garder en tête lors du développement d'un projet avec WordPress.

Énumération des utilisateurs

https://developer.wordpress.org/rest-api/reference/users/#list-users

/wp-json/wp/v2/users

En se rendant à cette url, vous retrouverez la liste des utilisateurs de votre site WordPress. Même si je suis sûr que vous avez un mot de passe complexe avec des caractères variés, peut-être n'est-ce pas le cas de votre webmaster, de votre rédacteur ou de votre chef de projet ayant accès à votre site ?

Plutôt que de brut forcer le nom d'utilisateur et le mot de passe pour tenter de pénétrer dans votre site, il est trivial de récupérer les utilisateurs d'un site puis d'effectuer une attaque par dictionnaire pour casser les mots de passe les plus fréquemment utilisés.

Attention donc, même si votre nom d'utilisateur n'est qu'un assemblage de caractère aléatoires, il est très facilement récupérable par quiconque équipé d'un navigateur web. Préférez toujours l'utilisation d'un mot de passe fort plutôt que le recours à des pratiques de sécurité par l'obscurité.

Énumérations des fichiers de la bibliothèque de médias

https://developer.wordpress.org/rest-api/reference/media/#list-media

/wp-json/wp/v2/media?_fields=source_url&per_page=100
/wp-json/wp/v2/media?_fields=source_url&per_page=100&search=zip
/wp-json/wp/v2/media?_fields=source_url&per_page=100&search=pdf
/wp-json/wp/v2/media?_fields=source_url&per_page=100&search=xls

TOUS les fichiers ajoutés à la bibliothèque WordPress depuis son interface d'administration sont visibles par n'importe qui.

S'il n'y a qu'une seule chose à retenir de cet article, c'est celle-ci. Je le répète donc, tous les fichiers ajoutés à la bibliothèque WordPress depuis son interface d'administration sont visibles par n'importe qui.

Avec les urls du dessus, il est possible de naviguer dans les medias, d'effectuer des recherches, de ne montrer que les fichiers zip, pdf, etc.

Si le listing des dossiers du serveur est le plus souvent désactivé lors de l'hébergement d'un site WordPress avec un seveur nginx ou Apache, le listing via l'API est une zone d'ombre pour bon nombre de développeurs qui ignorent totalement cette possibilité.

En tapant malencontreusement ce genre d'URLs au hasard de mes navigations sur le web, je suis déjà tombé sur :

• des sites de VOD ou de cours en ligne qui autorisaient le listing de leurs fichiers vidéo via l'API
• des sites internes protégés par mot de passe en front mais ne protégeant pas certains documents confidentiels y étant hébergés
• des captures d'écrans affichant des identifiants en clair.

(Tous les propriétaires de sites ont été prévenus et ces soucis sont maintenant réglés)

Conclusion

Vous l'aurez compris, le but de cet article est d'éduquer les développeurs, webmasters et propriétaires de sites à ce qui est privé et ce qui est public sur un site. S'il est facile de se rendre compte que l'on accède à une page à laquelle nous ne devrions pas simplement en ouvrant son URL dans un navigateur, je conçois qu'il soit un peu plus pénible de le vérifier pour chaque route de l'API Rest de WordPress.

Mais comme les usages et les pratiques du web évoluent pour permettre plus d'interactivité et la communication entre différents systèmes via les APIs, nous devrions évoluer avec eux et avoir le réflexe de penser omnicanal pour tous les développements réalisés sur un site, que ce soit un site WordPress ou non.

Comme la recette graphique et fonctionnelle vérifie la conformité d'un développement par rapport à un rendu visuel et une spécification, ajoutons également une recette de tous ses canaux de diffusion, du flux RSS jusqu'à l'API.