
Atténuer les attaques CVE-2018-6389 WordPress load-scripts / load-styles
Atténuer les attaques WordPress load-scripts / load-styles liées à la CVE-2018-6389.
Refuser toutes les requêtes vers wp-admin/load-scripts.php et wp-admin/load-styles.php via Nginx.
En résumé
WordPress utilise load-scripts.php (pour JS) ou load-styles.php (pour les fichiers CSS) et le navigateur reçoit plusieurs fichiers JS/CSS en une seule requête – c'est donc meilleur pour les performances et la page se charge plus vite. Cette fonctionnalité a été conçue uniquement pour les pages d'administration, mais elle est aussi utilisée sur la page wp-login.php, donc aucune authentification n'est requise pour ces fichiers.
-- How to DoS 29% of the World Wide Websites - CVE-2018-6389
# par exemple
https://example.com/wp/wp-admin/load-scripts.php?c=1&load[]=jquery-ui-core,iris,wp-color-picker,dashboard,list-revision,media-grid,media,image-edit,set-post-thumbnail,nav-menu,custom-header,custom-background,media-gallery,svg-painter,wp-fullscreen-stu,wp-ajax-response,wp-api-request,wp-pointer,autosave,heartbeat,wp-auth-check
# idem pour https://example.com/wp/wp-admin/load-styles.php
Une seule requête (sans authentification nécessaire) peut amener le serveur à effectuer >180 lectures d'E/S et concaténer tous les fichiers en une réponse de plus de 4 Mo. Pour les petits serveurs sans pare-feu ni limitation de débit appropriés, cela suffit pour mener des attaques DoS.
- Vous devriez vraiment utiliser HTTPS. Si ce n'est pas le cas, vous ne devriez pas avoir de site web.
- Lorsque vous utilisez HTTPS, il n'y a aucune raison de ne pas utiliser HTTP/2.
- Avec HTTP/2, il n'est pas nécessaire de concaténer vos fichiers. C'est même un anti-modèle.
-- How to mitigate CVE-2018-6389 – the load-scripts.php DoS "attack" in WordPress
load-scripts.php et load-styles.phpAjoutez ce rôle à requirements.yml :
# requirements.yml
- src: https://github.com/ItinerisLtd/trellis-cve-2018-6389
version: 0.1.0 # Vérifiez la dernière version !
Exécutez la commande :
➜ ansible-galaxy install -r requirements.yml --force
Ajoutez le rôle dans dev.yml et server.yml, immédiatement après role: wordpress-setup :
roles:
# certains autres rôles Trellis ...
- { role: wordpress-setup, tags: [wordpress, wordpress-setup, letsencrypt] }
- { role: trellis-cve-2018-6389, tags: [nginx, wordpress, wordpress-setup] }
# certains autres rôles Trellis ...
Ensuite, re-provisionnez comme d'habitude :
# https://roots.io/trellis/docs/local-development-setup/
➜ vagrant reload --provision
# https://roots.io/trellis/docs/remote-server-setup/
➜ ansible-playbook server.yml -e env=<environment>
Désactivez la concaténation :
# config/application.php OU wp-config.php OU équivalent
# normal OU Bedrock obsolète :
define('CONCATENATE_SCRIPTS', false);
# Bedrock avec roots/wp-config :
Config::define('CONCATENATE_SCRIPTS', false);
Ensuite, déployez comme d'habitude :
# https://roots.io/trellis/docs/deploys/
➜ ./bin/deploy.sh <environment> <domain>
# ou alternativement
➜ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"
Non, vous ne pouvez pas l'utiliser sur des hébergements managés comme Kinsta ou WP Engine.
C'est à l'hébergeur d'atténuer ce type d'attaques.
Merci ! Content que ça vous plaise. Il est important que mon chef sache que quelqu'un utilise ce projet. Plutôt que de donner des avis sur wp.org, envisagez de :
➜ ansible-playbook -i 'localhost,' --syntax-check tests/test.yml
trellis-cve-2018-6389 est un projet de Itineris Limited créé par Tang Rufus.
Un grand merci à l'équipe Roots dont Trellis rend ce projet possible.
La liste complète des contributeurs se trouve ici.