Contributions
J’expose sur cette page mes contributions en cours ou à venir à des logiciels libres (ou autres domaines de la culture libre).
Idées
2023-05-21 - nginx + RFC 9110 - utilisation trop fréquente du code 505 HTTP Version Not Supported
En parcourant des logs d’un serveur nginx, je constate des requêtes GET / HTTP/7.9 [1], alors que, en 2023, la version la fréquente de HTTP est 2.0 et la 3.0 vient d’être publiée (juin 2022) : mettre une version de HTTP égale à 7.9 n’est donc pas une erreur du client mais est une sonde en phase de reconnaissance (soit du fuzzing, soit ciblant un logiciel précis). L’occurence de telles requêtes semble très rare toutefois.
Utiliser un code 5xx laisse à penser que c’est un problème du serveur, hors le serveur ne peut pas implémenter une version de HTTP qui n’existe pas (encore), c’est donc une erreur du client. Ce raisonnement touche au standard RFC 9110 section 15.6.6 plus qu’à nginx.
Pour les sysadmins qui observent les logs et particulièrement les erreurs 5xx (qui sont des problèmes soit dans les implémentations (à corriger) soit opérationnels (performance notamment)), ça oblige à avoir un traitement fin : est-ce que la version HTTP existe (client peut-être légitime) ou n’existe pas (attaque obligatoirement) ?
Du côté de nginx, je serais d’avis de retourner une erreur 400 (à défaut d’un meilleur code 4xx), soit avec une liste fixée dans le code disant les versions potentiellement acceptées à l’époque (actuellement ça serait erreur 400 pou HTTP > 3.0 et erreur 505 pour HTTP <= 3.0 s’il n’y a pas de module pour HTTP 3.0 puisqu’il pourrait y en avoir puisque le standard est disponible). Pour laisser plus de flexibilité, il pourrait être créé un paramètre dans la configuration pour permettre aux sysadmins de changer la version maximum existante sans avoir à changer la version de nginx tout de suite. Ce paramètre pourrait être abusé par les sysadmins qui ne voudraient pas avoir de codes 5xx même si une nouvelle version de HTTP devient disponible et que des clients peuvent alors commencer à la demander.
2023-05-21 - nginx - utilisation plus exhaustive du code 405 Method Not Allowed
En parcourant des logs d’un serveur nginx et observant les attaquants opportunistes, je remarque que les méthodes HTTP exotiques ne sont pas rejetées avec le code "405 Method Not Allowed". Par exemple la configuration try_files $uri =404; donne :
- requête = "DELETE /fichier-inexistant.pdf HTTP/1.1" réponse = "404 Not Found" car le fichier n’existe pas
- requête = "DELETE /fichier-existant.pdf HTTP/1.1" réponse = "405 Not Allowed"
Il serait intéressant qu’il y ait un paramètre de configuration methods_allowed GET HEAD POST; par exemple pour refuser inconditionnellement des méthodes exotiques pour le serveur en question afin de limiter encore plus la surface d’attaque.
La RFC 9110 section 9.1 Method > Overview dit que l’implémentation des méthodes GET et HEAD est obligatoire, toutes les autres sont optionnelles et peuvent changer dynamiquement.
Il y a déjà dans le code de nginx des retours "405 Not Allowed" selon les modules (chercher la constante NGX_HTTP_NOT_ALLOWED, par exemple ngx_http_static_module.c retourne 405 si la méthode n’est pas GET, HEAD ou POST ; ou ngx_http_empty_gif_module.c retourn 405 si la méthode n’est pas GET ou HEAD), mais il serait préférable que ça retourne toujours 405 si aucun module n’est en capacité de répondre (ou laisser à l’administrateur la possibilité de faire cette liste dans la conf).
PS : je ne suis pas complètement sûr que la fonctionnalité n’existe pas déjà, il est possible que mon observation vienne du fait que Debian compile nginx avec --with-http_dav_module, et peut-être que le verbe DELETE pourrait potentiellement répondre même si on a explicitement ou implicitement dav_methods off; dans le contexte.
Actions à faire :
- Compiler nginx sans aucun module
- Parcourir https://nginx.org/en/docs/dev/development_guide.html
- Re-tester
- Confirmer ou non le problème
- Éventuellement investiguer comment ça se comporte si on active le module dav