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 de Hacker News

• Les personnes qui configurent les règles WAF sur les CDN comprennent souvent mal les sites et services qui traitent de contenus techniques. Ce n’est pas propre à Cloudflare : Akamai est similaire
  Si l’on active les règles de base contre l’injection SQL sur un site qui discute de bases de données, le site casse, et les jeux de règles contre l’inclusion de fichiers bloquent des chaînes comme /etc/hosts ou /etc/passwd
  Il y a aussi une question d’équilibre entre sécurité et utilisabilité. Comme on ne peut pas savoir quel service a été implémenté de manière vulnérable, empiler toutes les règles WAF peut effectivement rendre les choses plus sûres. Mais quand un service correctement sécurisé doit discuter de concepts techniques, ces mêmes jeux de règles deviennent très agaçants
  Ajuster finement les règles prend énormément de temps. On corrige le fait que la page ne s’affiche pas parce que le paramètre de requête contient /etc/hosts, puis c’est une ressource XHR qui ne se charge plus parce que le référent contient /etc/hosts, puis une bibliothèque JS d’analyse met l’URL visitée dans un cookie et tout casse à nouveau ; au final, on a juste envie de désactiver la règle

  • Il n’y a pas seulement la sécurité et l’utilisabilité, il y a aussi l’aspect économique. Des politiques de sécurité qui paraissent idiotes viennent souvent d’exigences d’assureurs
    Si un assureur dit : « si vous n’obligez pas les employés à changer leur mot de passe tous les 90 jours, nous augmenterons la prime de 20 % », on aura beau expliquer, à juste titre, que le NIST a cessé de recommander les changements périodiques de mot de passe il y a plus de dix ans et que c’est une mauvaise pratique, la prime augmentera quand même
    On soupire donc en implémentant une politique d’expiration des mots de passe, puis on écoute les employés se plaindre de l’incompétence ambiante. Comme log4shell est devenu très connu, il ne serait pas surprenant que les assureurs exigent désormais que les serveurs rejettent des « chaînes de piratage » courantes comme /etc/hosts, /etc/passwd ou jndi:
  • Le « au cas où » est la pire approche de la sécurité, et rend l’ensemble du système moins sûr. On change les mots de passe tous les mois par sécurité, on impose 20 caractères alphanumériques et 5 symboles, on doit passer toutes sortes de conformités à acronymes de trois lettres avec des checklists de centaines de pages, et comme c’est dans la checklist, il faut aussi activer un WAF sur le serveur
    Si l’on demande au CIO quelle menace réelle cela bloque, on n’obtient qu’un regard vide
    Du point de vue d’un ingénieur, il n’y a aucune incitation à comprendre où va chaque formulaire de saisie et à l’assainir de manière pertinente. Ce qui est rémunéré, c’est de cocher des cases et de passer à autre chose, et même les nouveaux l’apprennent vite. Ce type d’organisation ne cherche pas à améliorer la sécurité, mais à éviter d’être tenue responsable après une compromission
  • Cela ressemble à une variante du problème de Scunthorpe, avec un filtre trop naïf et agressif, appliqué en plus au mauvais contenu
    Appliquer des filtres aux « autres choses » qui vont vers le serveur, en sortent ou circulent entre serveurs peut avoir du sens, mais filtrer le corps de texte réel destiné à être affiché comme contenu de blog ne semble apporter aucun bénéfice de sécurité. Cela ressemble plutôt à un bug assez évident
    https://en.wikipedia.org/wiki/Scunthorpe_problem
  • Je ne comprends pas pourquoi on ferait du filtrage d’injection SQL des champs de saisie au niveau du CDN. À part la longueur ou une validation simple de type, par exemple un nombre ou une date, il n’y a aucune raison de valider les champs de saisie sur le CDN
    Le backend doit être capable de traiter un contenu arbitraire en octets dans les champs de saisie, et ne doit pas être vulnérable à l’injection SQL simplement parce qu’il n’y a pas de préfiltrage au niveau du CDN
  • Si un WAF se déclenche parce que la chaîne "/etc/hosts" apparaît telle quelle n’importe où dans le contenu de la ressource demandée, il semble assez clairement cassé

• Cela me rappelle une anecdote sur une plateforme d’e-commerce. Quelqu’un avait créé une boutique web avec une fuite mémoire, et, comme contournement, l’application était redémarrée dès que la chaîne "OutOfMemoryException" apparaissait dans les logs
  Puis un autre développeur a voulu journaliser les recherches des clients, et si quelqu’un saisissait "OutOfMemoryException" dans la barre de recherche…

  • Analyser imprudemment des logs en texte libre est un vecteur d’exploitation système sous-estimé. C’est effrayant de voir combien de logiciels écrivent aveuglément des données dans les logs sans échappement hors bande ni assainissement
  • J’ai effectivement vécu plusieurs fois ce genre de problème à cause d’un WAF. Un utilisateur avait laissé une note contenant la chaîne "system(...)", et le WAF l’a interprétée comme une injection PHP, puis a bloqué l’IP

• Je me demande s’ils bloquent aussi /etc//hosts ou /etc/./hosts. Ce genre de chasse à la taupe est voué à l’échec
  Les gens qui conçoivent cela devraient comprendre que les attaquants sont plus intelligents et plus obstinés qu’eux, et ne s’appuyer que sur des méthodes de sécurité éprouvées, par exemple ne pas exécuter des entrées non fiables

  • Exact. Cela ressemble à une case obligatoire très courante dans les Fortune 500. Il faut absolument avoir un pare-feu d’application web, peu importe quelles sont les règles, tant qu’il y en a quelques-unes
    On m’a même déjà dit qu’une application qui n’utilisait pas de base SQL avait besoin d’un WAF pour bloquer les attaques par injection SQL
    Si l’on conteste, on a toujours droit au cours sur la « défense en profondeur », et si l’on dit qu’il serait plus efficace de taper une fois sur son bureau tous les jeudis matin puis de tourner trois fois sur soi-même, on vous regarde vraiment comme un fou. Je l’ai fait chaque semaine et je ne me suis jamais fait pirater, donc c’est bien de la défense en profondeur, non ? Ça ne peut pas faire de mal
  • Énumérer les mauvaises choses est une stratégie perdante. Environ cinq minutes après avoir commencé mon premier emploi en 1995, je savais déjà que c’était une mauvaise idée
  • Je viens de créer un compte sur Substack pour tester, et il semble qu’ils aient déjà corrigé le problème ou complètement désactivé le WAF
  • Je ne vois pas pourquoi ce serait difficile. La fonctionnalité permettant d’obtenir le chemin absolu d’une chaîne existe dans la bibliothèque standard de presque tous les langages. Il suffit de trouver les chaînes contenant des slashs et d’essayer de les résoudre
    La résolution des jokers est plus délicate, mais si l’on dispose d’une liste de fichiers interdits, c’est tout à fait faisable
    https://nodejs.org/api/path.html#pathresolvepaths
    Modification : en C, realpath se comporte un peu différemment et modifie les liens
  • Une solution de sécurité n’a-t-elle aucune valeur si elle n’arrête pas un attaquant déterminé ? Beaucoup de règles WAF servent à bloquer les requêtes de reconnaissance des scanners de vulnérabilités prêts à l’emploi

• Comment Substack pourrait améliorer cette situation pour les rédacteurs techniques ?
  Il suffirait de ne pas coller un pare-feu applicatif web aussi bête qu’un caillou devant un endpoint d’édition d’articles qui doit pouvoir traiter n’importe quel sujet, y compris des chaînes susceptibles de déclencher un WAF idiot.
  C’est comme si un forum de développement web mettait en place un filtre XSS empêchant ses membres de parler de XSS. Il faut apprendre à échapper correctement le contenu.

  • Ils sont dans une situation où ils doivent faire tourner un WAF pour passer une certification de sécurité. Les seuls WAF open source sont à peu près modsecurity et son successeur en bêta, coraza.
    Ils sont stupides et ne font qu’utiliser l’amas de déchets illisible de l’OWASP appelé coreruleset.
  • Il leur faut embaucher des gens en cybersécurité. On dirait qu’ils n’en ont pas.

• J’ai du mal à être d’accord avec l’idée que ce cas illustre une tension intéressante, dans la sécurité web, entre protection et utilisabilité. C’est simplement un bug, et un bug stupide. Il montre seulement que des gens qui devraient savoir mieux ne le savent pas.
  La tension entre sécurité et utilisabilité existe réellement, mais ce n’est pas ça. En général, il s’agit d’un compromis où l’on implémente une bonne sécurité au prix d’une gêne pour l’utilisateur. L’authentification à deux facteurs, le verrouillage après 3 échecs, ou la limitation de débit pour prévenir les DoS : renforcer la sécurité dégrade l’expérience utilisateur, et améliorer l’expérience utilisateur réduit la sécurité.
  Ici, ce n’est ni l’un ni l’autre. C’est une mauvaise sécurité et une mauvaise expérience utilisateur. Je ne vois pas où serait la tension.

  • De manière générale, appliquer un WAF en bloc à tous les endpoints puis le retirer sélectivement lorsque ce genre de problème survient me semble être une pratique de sécurité utile. C’est particulièrement vrai quand on héberge des logiciels tiers comme Wordpress avec des plugins, où évaluer un par un tous les endpoints publics est beaucoup plus difficile.
  • Ça me rappelle l’époque de PHP 3. Il me semble que PHP « nettoyait » le contenu des requêtes URL pour tenter de bloquer globalement les injections SQL, à moins que ce ne soit un réglage souvent activé sur les hébergements mutualisés.
    Bien sûr, les auteurs de sites PHP l’ont vite compris, diverses techniques de contournement ont été utilisées, et au final ce « nettoyage » a probablement produit des résultats pires que s’il n’avait pas existé.

• Comme ça m’était déjà arrivé une fois, dès que j’ai vu « erreur réseau », la cause m’est tout de suite venue à l’esprit.
  Quand j’encadrais une équipe de programmation compétitive, la moitié des élèves de la classe recevaient une page blanche en soumettant leur solution. Après une heure de debug, on avait réduit le problème à quelques types et mots-clés C++ qui, s’ils apparaissaient dans le code, provoquaient un 403, et qui avaient tous aussi un sens en JavaScript.
  Quand je travaillais dans une banque, il y avait aussi une API à laquelle il fallait soumettre des fichiers Python : la plupart des fichiers Python provoquaient un 403, tandis que les fichiers courts passaient. Après plusieurs heures de debug, on a isolé un mot-clé qui apparaissait parfois dans le code.
  Quelques mois plus tard, la même chose s’est produite dans un nouvel environnement cloud, et on y a encore perdu des heures. Après la deuxième fois, un collègue a fait en sorte que le script de déploiement affiche "HAHAHA YOU'VE BEEN WAFFED" lorsqu’il recevait un 403 ; je lui en suis encore reconnaissant, car j’ai vu cette erreur bien plus souvent que prévu.

  • Je me demande si tu te souviens si c’était Cloudflare, ou un autre WAF.

• Nous avons vécu quelque chose de similaire dans notre application. Notre red team interne publiait des données contenant des tentatives de XSS et d’autres attaques par injection.
  Les attaques elles-mêmes n’avaient pas réussi, mais comme ces éléments existaient, le pare-feu de l’entreprise bloquait les requêtes réseau contenant ces payloads, ce qui empêchait la page d’administration interne de se charger. Au final, une attaque XSS ratée était devenue une attaque DoS efficace.

• Ce qui est ancien redevient nouveau. Autrefois, on appelait cela le problème de Scunthorpe.
  https://en.m.wikipedia.org/wiki/Scunthorpe_problem

  • Je me souviens que sur les anciens forums d’Eve Online, le mot cockpit était toujours remplacé par c***pit. C’était assez drôle.
  • Ça me rappelle aussi la suppression récente de mots comme « diversity », « equity » et « inclusion » sur des sites web du gouvernement américain.
    Vous écrivez sur la biologie, la finance ou la géologie ? Pas de chance.
    Même lorsqu’elle est écrite par des personnes intelligentes et bien intentionnées, le filtrage stupide est déjà suffisamment mauvais.
  • Il est temps d’ajouter ce cas Substack à l’article Wikipédia.

• J’ai rencontré un problème similaire hier soir avec OpenRouter. OpenRouter est excellent : c’est un service de type « commutateur » qui permet d’utiliser plusieurs LLM via un seul endpoint, et hier soir j’ai commencé à tester quels modèles étaient bons pour traiter du HTML brut de différentes façons.
  Mais comme l’API OpenRouter est protégée par Cloudflare, lorsque le corps d’une requête POST contient certains fragments de HTML brut et de JavaScript, beaucoup de requêtes — pas toutes — sont bloquées. En envoyant le même prompt directement à OpenAI ou Anthropic, il n’y a aucun problème.
  Pour des modèles gratuits, je comprendrais qu’ils imposent une prévention forte des abus, mais ici il s’agit de requêtes facturées vers des modèles commerciaux, ce qui rend la chose d’autant plus agaçante.

  • Je me demande si tu l’as signalé.

• J’ai déjà eu ce problème et c’était extrêmement frustrant. À cause de "Network error", je n’ai pas pu mettre à jour un article que j’avais écrit depuis des mois ; comme l’article s’allongeait avec les modifications, je pensais que c’était la cause et je n’arrivais pas à trouver le problème.
  Contacter le support était aussi difficile à cause du chatbot IA, et même quand j’ai enfin réussi à joindre un humain, leur « support technique » ne semblait pas avoir l’intention de s’en occuper dans un délai raisonnable.
  Ce n’est qu’après qu’une personne sur Twitter a suggéré la possibilité d’une chaîne magique déclenchant une logique de sécurité stupide que j’ai trouvé le problème, et que j’ai enfin pu modifier l’article.