Nouveauté de Caddy 2.5 : Expurger les données sensibles de vos logs

Découvrez ici l'article original

Caddy est l'étoile montante des serveurs web : rapide, facile à configurer, complet (génération et renouvellement automatique des certificats TLS, HTTP/3, cloud-native, rechargement à chaud de la configuration...) et sécurisé (écrit en Go et pas en C).

Grâce à son extensibilité inégalée, Caddy est une plateforme applicative de premier ordre, disposant d'un écosystème florissant !

Pour mieux saisir sa puissance, jetez un coup d'œil aux modules Mercure (capacités push) et Vulcain (API hypermédia pilotées par le client) auxquels j'ai contribué ! Caddy est également le serveur web utilisé dans la distribution API Platform et dans Symfony Docker.

Il y a quelques jours, après un an de travail, Matt Holt a publié Caddy 2.5 ! Cette nouvelle version contient quelques nouvelles fonctionnalités que j'ai contribué ou aidé à concevoir, améliorant la sécurité du système de logs.

Contrairement à la plupart des autres serveurs web, Caddy émet des logs structurés verbeux. Bien qu'il soit pratique de pouvoir inspecter et analyser chaque détail des messages HTTP, cela peut également être dangereux. Jusqu'à la version 2.5, tous les en-têtes HTTP étaient enregistrés lorsque la journalisation est activée, y compris les en-têtes sensibles.

Cela peut entraîner de graves problèmes de sécurité si le système qui traite et stocke les logs (ELK, Datadog...) n'est pas configuré correctement. Et ils ne le sont pas par défaut ! Même des entreprises telles que Facebook, Twitter et GitHub ont stocké des millions de mots de passe d'utilisateurs en clair en raison de mauvaises configurations similaires.

Dans la version 2.5, les en-têtes HTTP standard susceptibles de contenir des informations d'identification, tels que définis dans la spécification de fetch(), sont automatiquement expurgés. Ces en-têtes sont Cookie, Set-Cookie, Authorization et Proxy-Authorization.
Si vous avez malgré tout besoin d'enregistrer ces en-têtes, par exemple pendant une session de débogage, Francis Lavoie a ajouté une nouvelle option permettant de réactiver l'ancien comportement : log_credentials.

Mais cette modification ne suffit pas à couvrir tous les cas où des données sensibles doivent être supprimées des logs. Bien que cela soit considéré comme une mauvaise pratique de sécurité, il est courant que les paramètres de requête contiennent des informations sensibles. 

Quelques exemples :

Dans de nombreux cas, vous pouvez souhaiter logguer certains paramètres de requête, mais supprimer ou remplacer certains autres qui contiennent des données sensibles. Par exemple : le paramètre de requête access token défini dans les spécifications OAuth 2.

De même, au lieu de supprimer entièrement l'en-tête Cookie, ce qui signifie supprimer tous les cookies, vous pouvez vouloir supprimer certains cookies spécifiques mais en conserver d'autres. Pour couvrir ces cas d'utilisation plus avancés mais assez courants, j'ai ajouté un certain nombre de nouveaux filtres.

Le premier nouveau filtre permet de supprimer, remplacer ou hacher des paramètres de requête spécifiques :

J'ai également contribué à un filtre similaire pour manipuler les cookies :

Enfin, j'ai ajouté la possibilité de hacher ou d'appliquer une expression régulière à la valeur de n'importe quel champ enregistré :

Le filtre de hachage est particulièrement utile pour éviter que différentes requêtes ne soient pas distinguables dans les journaux, ou lorsque vous voulez pouvoir regrouper des requêtes qui ont les mêmes valeurs caviardées, mais qui sont caviardées.

Si vous avez besoin d'aide pour mettre en place ou même pour mettre à jour Caddy, si vous voulez faire appel à une équipe de développeurs Go expérimentés, ou si vous avez besoin d'experts pour sécuriser votre application : contactez-nous !

Les-Tilleuls.coop peut vous aider !