Une erreur de l’éditeur Substack provoquée par l’écriture du fichier "/etc/hosts"

• Dans l’éditeur de Substack, la saisie de certains chemins système provoque une erreur réseau
• Un pare-feu applicatif web (WAF) bloque ces chemins afin d’empêcher les attaques de traversée de répertoires et les attaques par injection de commandes
• La question de l’équilibre entre sécurité et ergonomie devient centrale
• Une meilleure solution est nécessaire pour les rédacteurs techniques
• Il est possible de contourner le problème en utilisant un chemin alternatif

---

Quand /etc/h*sts perturbe l’éditeur Substack : l’aventure du filtrage de contenu web

Une mystérieuse erreur réseau

• Une erreur inattendue survient pendant la rédaction d’un article technique sur la résolution DNS
• La saisie du chemin /etc/h*sts déclenche une erreur réseau et l’enregistrement automatique échoue
• La page d’état de Substack indique pourtant que le service fonctionne normalement

Début de l’enquête

• L’erreur se produit lors de la saisie d’un chemin de fichier précis, alors que des variantes du chemin fonctionnent normalement
• Des chemins comme /etc/h*sts provoquent l’erreur, tandis que des versions modifiées ne posent aucun problème

Que se passe-t-il en coulisses ?

• Les outils de développement du navigateur montrent une réponse 403 Forbidden
• Cloudflare est impliqué

Comprendre les filtres de sécurité des applications web

Brève explication d’un WAF

• Un pare-feu applicatif web (WAF) joue le rôle de gardien de sécurité d’un site web
• Il bloque les requêtes jugées suspectes

Attaques de traversée de répertoires : pourquoi c’est surveillé

• Une attaque de traversée de répertoires cherche à accéder à des fichiers système sensibles
• Des chemins comme /etc/h*sts peuvent être considérés comme des cibles d’attaque

Injection de commandes : un autre problème de sécurité

• Une attaque par injection de commandes vise à faire exécuter des commandes système
• Lorsqu’un chemin système est mentionné, le filtre peut le bloquer

Le mystère s’épaissit : un précédent historique

• Des cas similaires d’utilisation de tels chemins ont été trouvés dans d’autres publications Substack
• Il est possible que le comportement de filtrage ait changé à un moment donné

Sécurité contre ergonomie : un équilibre délicat

• Les filtres de Substack visent à protéger la plateforme, mais deviennent un obstacle pour les rédacteurs techniques
• Il existe une marge d’amélioration : messages d’erreur plus clairs, reconnaissance du contenu technique, solutions de contournement documentées

Examiner la réponse HTTP

• Le code d’état 403 Forbidden est confirmé au niveau de l’API

De meilleures solutions pour les plateformes de contenu technique

1. Filtrage contextuel : reconnaître les chemins système dans les blocs de code ou les discussions techniques
2. Messages d’erreur clairs : expliquer qu’il s’agit d’un blocage par filtre de sécurité au lieu d’une simple « erreur réseau »
3. Solutions documentées : indiquer comment discuter de chemins sensibles

Conclusion : au croisement de la sécurité et de l’écriture technique

• Le problème de l’éditeur Substack met en lumière les défis complexes entre sécurité et rédaction technique

• Ce qui peut ressembler à un motif d’attaque pour un filtre de sécurité peut en réalité être un contenu légitime

• Il est possible de résoudre le problème en utilisant un chemin alternatif

• Invitation à partager en commentaire des expériences similaires de filtrage sur d’autres plateformes

[GN⁺]

Avis Hacker News

• Les personnes qui configurent des règles WAF sur les CDN comprennent souvent mal les sites et services qui traitent de contenu technique. Ce n’est pas propre à Cloudflare, Akamai rencontre aussi le même problème

  • Pour un site qui traite de bases de données, activer les règles de protection de base contre les injections SQL peut casser le site
  • Il existe aussi des jeux de règles d’inclusion de fichiers, ce qui bloque des éléments comme /etc/hosts ou /etc/passwd
  • Je pense que l’équilibre entre sécurité et ergonomie est important. Appliquer toutes les règles WAF renforce la sécurité, mais c’est contraignant pour les services où il faut pouvoir discuter de concepts techniques
  • Affiner les règles prend beaucoup de temps. Il faut faire de nombreuses modifications pour conserver les règles tout en autorisant les cas d’usage
  • Cela peut provoquer des problèmes comme des pages qui ne se chargent pas ou des ressources qui ne se chargent pas. On peut être tenté de désactiver les règles

• Cela me rappelle une anecdote sur une plateforme e-commerce : quelqu’un avait codé une boutique en ligne avec une fuite de mémoire, et le problème avait été « résolu » en redémarrant l’application dès que la chaîne "OutOfMemoryException" apparaissait dans les logs

  • Un autre développeur voulait enregistrer les termes de recherche des clients, et si quelqu’un saisissait "OutOfMemoryException" dans le champ de recherche, cela provoquait un problème

• Je me demande s’ils bloquent /etc/hosts ou /etc/./hosts. Cela ressemble à un jeu de taupe sans fin voué à l’échec. Les hackers sont plus intelligents et plus déterminés, donc il faut s’appuyer uniquement sur de la sécurité éprouvée

• Avis sur la façon dont Substack pourrait améliorer la situation pour les auteurs techniques

  • Il ne faudrait pas faire tourner un WAF idiot sur un endpoint où les gens peuvent éditer du texte sur n’importe quel sujet
  • C’est comme implémenter un filtre XSS sur un forum de développement web au point d’empêcher les membres de parler de XSS
  • Il faut apprendre à échapper correctement le contenu

• Cela met en avant un cas intéressant de tension entre protection et ergonomie en sécurité web

  • Mais dans ce cas, cela met surtout en évidence un bug. La tension entre sécurité et ergonomie existe bel et bien, mais ce n’est pas ce qu’on voit ici
  • La tension entre sécurité et ergonomie est généralement un compromis. Renforcer la sécurité dégrade l’expérience utilisateur
  • Ici, on a à la fois une mauvaise sécurité et une mauvaise expérience utilisateur

• Problème rencontré en enseignant à une équipe de programmation compétitive : si des types et mots-clés C++ apparaissaient dans le code, cela déclenchait une erreur 403

  • Quand je travaillais dans une banque, il existait une API où il fallait soumettre des fichiers Python, et la plupart des fichiers Python déclenchaient une erreur 403
  • Un problème similaire se produit aussi dans un nouvel environnement cloud

• Problème survenu lorsque l’équipe interne de red team a publié des données contenant des tentatives de XSS et d’autres attaques par injection

  • L’attaque elle-même ne fonctionnait pas, mais la présence de ces éléments empêchait le chargement des pages d’administration internes

• Un vieux problème qui réapparaît. On appelle cela le problème de Scunthorpe

• J’ai rencontré un problème similaire avec OpenRouter. OpenRouter est un service qui fournit un endpoint unique permettant d’utiliser divers LLM

  • Si certains fragments HTML et JavaScript sont inclus dans le corps d’une requête POST, beaucoup de requêtes sont bloquées

• Le filtrage de contenu devrait fortement dépendre du contexte. Quand le WAF est séparé de ce qu’il est censé filtrer, cela pose problème

  • C’est similaire au filtrage anti-spam. Un serveur e-mail filtre en fonction de la configuration du serveur expéditeur
  • Le filtrage basé sur l’acheminement est plus efficace que le filtrage basé sur le contenu. Cela s’applique aussi aux sites web et aux WAF