Fehler im Substack-Editor durch das Schreiben der Datei "/etc/hosts"

 (scalewithlee.substack.com)
1 Punkte von GN⁺ 2025-04-26 | 1 Kommentare | Auf WhatsApp teilen
  • Im Substack-Editor tritt ein Netzwerkfehler auf, wenn bestimmte Systempfade eingegeben werden
  • Eine Web Application Firewall (WAF) blockiert solche Pfade, um Path-Traversal-Angriffe und Command-Injection-Angriffe zu verhindern
  • Das Gleichgewicht zwischen Sicherheit und Benutzbarkeit wird als wichtiges Thema sichtbar
  • Für technische Autoren wird eine bessere Lösung benötigt
  • Das Problem lässt sich durch die Verwendung eines alternativen Pfads umgehen

Wenn /etc/h*sts den Substack-Editor stört: Das Abenteuer der Web-Content-Filterung

Ein mysteriöser Netzwerkfehler

  • Beim Verfassen eines technischen Beitrags zur DNS-Auflösung trat ein unerwarteter Fehler auf
  • Bei Eingabe des Pfads /etc/h*sts trat ein Netzwerkfehler auf, und das automatische Speichern schlug fehl
  • Die Statusseite von Substack zeigte normalen Betrieb an

Beginn der Untersuchung

  • Der Fehler trat bei Eingabe eines bestimmten Dateipfads auf, während abgewandelte Pfade normal funktionierten
  • Pfade wie /etc/h*sts lösten Fehler aus, veränderte Varianten hingegen nicht

Was passiert im Hintergrund?

  • In den Entwicklerwerkzeugen des Browsers wurde eine 403 Forbidden-Antwort festgestellt
  • Cloudflare war beteiligt

Web-Application-Sicherheitsfilter verstehen

WAF kurz erklärt

  • Eine Web Application Firewall (WAF) fungiert als Sicherheitswächter für Websites
  • Sie blockiert verdächtige Anfragen

Path Traversal: Warum Vorsicht geboten ist

  • Path-Traversal-Angriffe versuchen, auf sensible Systemdateien zuzugreifen
  • Pfade wie /etc/h*sts können ein Angriffsziel sein

Command Injection: Ein weiteres Sicherheitsproblem

  • Command-Injection-Angriffe zielen darauf ab, die Ausführung von Systembefehlen auszulösen
  • Beim Erwähnen von Systempfaden kann ein Filter die Anfrage blockieren

Das Rätsel vertieft sich: historische Beispiele

  • In anderen Substack-Posts wurden ähnliche Fälle der Verwendung solcher Pfade gefunden
  • Möglicherweise hat sich das Filterverhalten ab einem bestimmten Zeitpunkt geändert

Sicherheit vs. Benutzbarkeit: eine heikle Balance

  • Der Filter von Substack dient dem Schutz, wird für technische Autoren aber zum Hindernis
  • Es gibt Verbesserungspotenzial: klare Fehlermeldungen, Erkennung technischer Inhalte, dokumentierte Workarounds

Ein Blick auf die HTTP-Antwort

  • Auf API-Ebene wurde der Statuscode 403 Forbidden bestätigt

Bessere Lösungen für Plattformen mit technischen Inhalten

  1. Kontextbezogene Filterung: Systempfade in Codeblöcken oder technischen Diskussionen erkennen
  2. Klare Fehlermeldungen: Statt „Netzwerkfehler“ erklären, dass die Blockierung durch einen Sicherheitsfilter verursacht wurde
  3. Dokumentierte Workarounds: Hinweise geben, wie sensible Pfade besprochen werden können

Fazit: Der Schnittpunkt von Sicherheit und technischem Schreiben

  • Das Problem im Substack-Editor zeigt die komplexen Herausforderungen zwischen Sicherheit und technischem Schreiben

  • Was für einen Sicherheitsfilter wie ein Angriffsmuster aussieht, kann in Wirklichkeit legitimer Inhalt sein

  • Das Problem kann durch die Verwendung eines alternativen Pfads gelöst werden

  • Leser werden gebeten, in den Kommentaren zu teilen, ob sie ähnliche Filterprobleme auf anderen Plattformen erlebt haben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-04-26
Meinungen auf Hacker News

  • Leute, die bei CDNs WAF-Regeln konfigurieren, verstehen Websites und Dienste mit technischen Inhalten oft nicht richtig. Das ist kein reines Cloudflare-Problem, bei Akamai ist es ähnlich.
    Wenn man auf einer Website, auf der über Datenbanken diskutiert wird, die grundlegenden Regeln gegen SQL Injection aktiviert, geht die Seite kaputt, und Regelsets gegen File Inclusion blockieren Zeichenketten wie /etc/hosts oder /etc/passwd.
    Es gibt natürlich auch den Aspekt des Gleichgewichts zwischen Sicherheit und Nutzbarkeit. Da man nicht weiß, welcher Dienst anfällig implementiert ist, wird es in gewisser Hinsicht sicherer, wenn man alle WAF-Regeln darüberlegt. Aber wenn ein sicher implementierter Dienst technische Konzepte diskutieren muss, werden dieselben Regelsets sehr lästig.
    Die Regeln feinzujustieren kostet viel Zeit. Wenn man behebt, dass eine Seite nicht lädt, weil /etc/hosts in einem Query-Parameter steht, lädt als Nächstes eine XHR-Ressource nicht, weil /etc/hosts im Referrer steht, und danach geht wieder etwas kaputt, weil eine JS-Analytics-Bibliothek die besuchte URL in ein Cookie schreibt – irgendwann will man die Regel einfach abschalten.

    • Neben Sicherheit und Nutzbarkeit gibt es auch Wirtschaftlichkeit. Auf den ersten Blick dumme Sicherheitsrichtlinien entstehen oft wegen Anforderungen von Versicherern.
      Wenn ein Versicherer sagt: „Wenn ihr eure Mitarbeiter nicht alle 90 Tage ihre Passwörter ändern lasst, erhöhen wir die Prämie um 20 %“, dann steigt die Prämie, egal wie zutreffend man darauf hinweist, dass NIST schon vor mehr als zehn Jahren davon abgerückt ist, regelmäßige Passwortwechsel zu empfehlen, und dass das eine schlechte Praxis ist.
      Also seufzt man, implementiert eine Passwortablauf-Richtlinie und hört sich die Beschwerden der Mitarbeiter an, man sei inkompetent. Da log4shell so berühmt geworden ist, wäre es nicht überraschend, wenn Versicherer inzwischen verlangen, dass Server gängige „Hacker-Strings“ wie /etc/hosts, /etc/passwd oder jndi: zurückweisen.
    • „Nur für den Fall“ ist die schlechteste Art von Sicherheit und macht das Gesamtsystem eher unsicherer. Für die Sicherheit muss man Passwörter monatlich ändern, 20 alphanumerische Zeichen plus 5 Sonderzeichen verlangen, alle möglichen dreibuchstabigen Compliance-Programme mit hunderte Seiten langen Checklisten bestehen, und weil es auf der Checkliste steht, muss auf dem Server auch eine WAF aktiviert sein.
      Fragt man den CIO, gegen welche tatsächliche Bedrohung das schützt, bekommt man nur einen leeren Blick zurück.
      Aus Sicht der Engineers gibt es keinen Anreiz, zu verstehen, wohin jedes Eingabeformular führt, und es auf sinnvolle Weise zu bereinigen. Bezahlt wird man dafür, Checkboxen abzuhaken und weiterzumachen, und auch Neue lernen das schnell. Solche Organisationen konzentrieren sich nicht darauf, Sicherheit zu verbessern, sondern darauf, nach einem Vorfall Verantwortung zu vermeiden.
    • Das sieht nach einer Variante des Scunthorpe-Problems aus: ein Filter, der zu naiv und aggressiv ist und zudem auf die falschen Inhalte angewendet wird.
      Es kann sinnvoll sein, Filter auf „andere Dinge“ anzuwenden, die zum Server oder zwischen Servern übertragen werden, aber beim Filtern des eigentlichen Textkörpers, der als Blog-Inhalt angezeigt wird, sehe ich keinen Sicherheitsgewinn. Das wirkt ziemlich eindeutig wie ein Bug.
      https://en.wikipedia.org/wiki/Scunthorpe_problem
    • Ich verstehe nicht, warum man auf CDN-Ebene SQL-Injection-Filterung für Eingabefelder macht. Abgesehen von Länge oder einfacher Typprüfung, etwa Zahlen oder Datumswerten, gibt es keinen Grund, Eingabefeldvalidierung im CDN zu machen.
      Das Backend muss beliebige Byte-Inhalte in Eingabefeldern verarbeiten können und darf nicht deshalb für SQL Injection anfällig sein, weil es keine Vorfilterung auf der CDN-Schicht gibt.
    • Wenn eine WAF auslöst, nur weil irgendwo im Inhalt der angeforderten Ressource die Zeichenkette "/etc/hosts" wörtlich vorkommt, wirkt sie ziemlich offensichtlich kaputt.

  • Das erinnert mich an eine Anekdote von einer E-Commerce-Plattform. Jemand hatte einen Webshop mit Memory Leak gebaut, und als Workaround wurde die App neu gestartet, sobald die Zeichenkette "OutOfMemoryException" im Log auftauchte.
    Dann wollte ein anderer Entwickler Kundensuchbegriffe loggen, und wenn jemand "OutOfMemoryException" ins Suchfeld eingab …

    • Das unvorsichtige Analysieren von Freitext-Logs ist ein unterschätzter Angriffsweg auf Systeme. Es ist erschreckend, wie viel Software Daten ohne Out-of-band-Escaping oder Bereinigung einfach blind in Logs schreibt.
    • Tatsächlich habe ich so etwas wegen WAFs schon ein paar Mal erlebt. Ein Nutzer hinterließ eine Notiz mit der Zeichenkette "system(...)", und die WAF wertete das als PHP Injection und sperrte die IP.

  • Ich frage mich, ob auch /etc//hosts oder /etc/./hosts blockiert werden. Dieses Whac-a-Mole-Spiel muss zwangsläufig scheitern.
    Die Leute, die so etwas bauen, müssen verstehen, dass Angreifer klüger und hartnäckiger sind als sie selbst, und sich nur auf bewährte Sicherheitsmethoden verlassen, etwa darauf, nicht vertrauenswürdige Eingaben nicht auszuführen.

    • Genau. Das sieht nach einer typischen Pflicht-Checkbox in einem Fortune-500-Unternehmen aus. Eine Web Application Firewall muss vorhanden sein, welche Regeln sie hat, ist egal, Hauptsache, es gibt ein paar.
      Mir wurde einmal gesagt, eine Anwendung brauche eine WAF zum Schutz vor SQL-Injection-Angriffen, obwohl sie gar keine SQL-Datenbank verwendet.
      Wenn man widerspricht, bekommt man immer den Vortrag über „Defense in Depth“ zu hören, und wenn man sagt, es sei effektiver, jeden Donnerstagmorgen einmal auf den Schreibtisch zu klopfen und sich dreimal im Kreis zu drehen, schauen sie einen an, als wäre man völlig verrückt. Ich habe das jede Woche gemacht und wurde nie gehackt – ist das etwa keine Defense in Depth? Schaden kann es ja nicht.
    • Schlechte Dinge aufzuzählen ist eine Verliererstrategie. Das wusste ich schon etwa fünf Minuten nach dem Beginn meines ersten Jobs 1995.
    • Ich habe gerade testweise ein Konto bei Substack erstellt, und es scheint, als hätten sie das Problem bereits behoben oder die WAF komplett abgeschaltet.
    • Ich verstehe nicht, warum das schwierig sein soll. Eine Funktion, um den absoluten Pfad einer Zeichenkette zu erhalten, gibt es in fast jeder Standardbibliothek jeder Sprache. Man muss nur Zeichenketten mit Schrägstrichen finden und auflösen.
      Wildcard-Auflösung ist schwieriger, aber mit einer Liste verbotener Dateien durchaus machbar.
      https://nodejs.org/api/path.html#pathresolvepaths
      Edit: realpath in C verhält sich etwas anders, daher habe ich den Link geändert.
    • Ist eine Sicherheitslösung wertlos, wenn sie einen gezielten Angreifer nicht aufhalten kann? Viele WAF-Regeln dienen dazu, Sondierungsanfragen handelsüblicher Schwachstellenscanner zu blockieren.

  • Wie Substack diese Situation für technische Autorinnen und Autoren verbessern kann?
    Indem sie an den Editor-Endpunkt für Beiträge, in denen es um jedes Thema gehen können muss – sogar um Strings, die eine dumme WAF triggern –, keine Web Application Firewall hängen, die so dumm wie ein Stein ist.
    Das ist, als würde ein Webentwicklungsforum einen XSS-Filter einsetzen, der verhindert, dass Mitglieder über XSS sprechen. Man sollte lernen, Inhalte korrekt zu escapen.

    • Sie sind wohl in der Lage, eine WAF betreiben zu müssen, um Sicherheitszertifizierungen zu bestehen. Bei Open-Source-WAFs gibt es im Wesentlichen nur modsecurity und den Beta-Nachfolger coraza.
      Die sind dumm und verwenden nur den schwer lesbaren Müllhaufen namens coreruleset von OWASP.
    • Sie sollten jemanden für Cybersecurity einstellen. Scheint es dort nicht zu geben.

  • Der Aussage, dieser Fall zeige eine interessante Spannung zwischen Schutz und Usability in der Websicherheit, kann ich kaum zustimmen. Das ist einfach ein Bug, und zwar ein dummer Bug. Er zeigt nur, dass Leute, die es besser wissen müssten, es nicht tun.
    Die Spannung zwischen Sicherheit und Usability gibt es tatsächlich, aber das hier ist sie nicht. Normalerweise geht es um Kompromisse, bei denen man gute Sicherheit umsetzt und dadurch Nutzerinnen und Nutzer nervt: Zwei-Faktor-Authentifizierung, Sperre nach drei Fehlversuchen, Rate Limiting gegen DoS – mehr Sicherheit verschlechtert die User Experience, bessere User Experience senkt die Sicherheit.
    Das hier ist keines von beidem. Es ist schlechte Sicherheit und schlechte User Experience. Ich sehe nicht, wo da die Spannung sein soll.

    • Im Allgemeinen halte ich es für eine sinnvolle Sicherheitspraxis, eine WAF pauschal auf alle Endpunkte anzuwenden und sie dann selektiv zu entfernen, wenn solche Probleme auftreten. Besonders wenn man Drittsoftware wie Wordpress mit Plugins hostet, ist es deutlich schwieriger, jeden öffentlichen Endpunkt einzeln zu bewerten.
    • Das erinnert mich an die PHP-3-Zeit. Ich glaube, PHP hat damals URL-Request-Inhalte „bereinigt“, um SQL-Injection pauschal zu verhindern – oder es war vielleicht eine Einstellung, die auf Shared Hosting häufig aktiviert war.
      Natürlich fanden PHP-Site-Autoren das schnell heraus, es wurden verschiedene Umgehungstechniken genutzt, und insgesamt hat diese „Bereinigung“ wahrscheinlich mehr Schaden angerichtet, als wenn es sie gar nicht gegeben hätte.

  • Nachdem ich früher einmal darauf hereingefallen war, fiel mir beim Wort „Netzwerkfehler“ sofort die Ursache ein.
    Als ich ein Competitive-Programming-Team betreute, bekam die Hälfte der Schülerinnen und Schüler eine leere Seite, wenn sie eine Lösung einreichten. Nach einer Stunde Debugging grenzten wir es auf einige C++-Typen und Schlüsselwörter ein, die, wenn sie im Code vorkamen, einen 403 auslösten – alles Dinge, die auch in JavaScript eine Bedeutung haben.
    Als ich bei einer Bank arbeitete, gab es ebenfalls eine API, bei der man Python-Dateien einreichen musste; die meisten Python-Dateien führten zu einem 403, kurze Dateien gingen durch. Nach Stunden Debugging grenzten wir es auf ein einzelnes Schlüsselwort ein, das gelegentlich im Code vorkam.
    Ein paar Monate später passierte dasselbe in einer neuen Cloud-Umgebung, und wieder verbrannten wir Stunden damit. Nach dem zweiten Mal sorgte ein Kollege dafür, dass das Deployment-Skript bei einem 403 "HAHAHA YOU'VE BEEN WAFFED" ausgibt, und ich bin ihm bis heute dankbar, weil ich diesen Fehler viel häufiger gesehen habe, als erwartet.

    • Ich frage mich, ob du dich erinnerst, ob das Cloudflare war oder eine andere WAF.

  • In unserer Anwendung ist uns etwas Ähnliches passiert. Unser internes Red Team veröffentlichte Daten, die XSS- und andere Injection-Angriffsversuche enthielten.
    Die Angriffe selbst waren nicht erfolgreich, aber allein weil diese Einträge existierten, blockierte die Firmenfirewall Netzwerk-Requests, die diese Payload enthielten, sodass die interne Admin-Seite nicht geladen wurde. Am Ende wurde ein fehlgeschlagener XSS-Angriff zu einem effektiven DoS-Angriff.

  • Altes wird wieder neu. Früher nannte man so etwas das Scunthorpe-Problem.
    https://en.m.wikipedia.org/wiki/Scunthorpe_problem

    • Ich erinnere mich, dass in den alten Eve-Online-Foren das Wort cockpit immer zu c***pit wurde. Das war ziemlich lustig.
    • Ich musste auch an die jüngste Entfernung von Wörtern wie „diversity“, „equity“ und „inclusion“ auf Websites der US-Regierung denken.
      Wenn man über Biologie, Finanzen oder Geologie schreibt? Einfach Pech gehabt.
      Dumme Filterung ist schon schlimm genug, selbst wenn sie von klugen und wohlmeinenden Menschen eingesetzt wird.
    • Jetzt ist es wohl an der Zeit, diesen Substack-Fall zum Wikipedia-Artikel hinzuzufügen.

  • Gestern Abend bin ich bei OpenRouter auf ein ähnliches Problem gestoßen. OpenRouter ist als „Vermittlungsstellen“-Dienst großartig, weil man mehrere LLMs über einen einzigen Endpunkt nutzen kann. Gestern Abend begann ich zu testen, welche Modelle gut darin sind, rohes HTML auf verschiedene Arten zu verarbeiten.
    Da die OpenRouter-API jedoch durch Cloudflare geschützt ist, wurden viele, wenn auch nicht alle Requests blockiert, sobald der Body eines POST-Requests bestimmte rohe HTML- und JavaScript-Fragmente enthielt. Schickt man denselben Prompt direkt an OpenAI oder Anthropic, gibt es kein Problem.
    Bei kostenlosen Modellen würde ich verstehen, dass man Missbrauchsschutz streng einstellt, aber hier geht es um abgerechnete Requests an kommerzielle Modelle, und das macht es noch ärgerlicher.

    • Ich frage mich, ob du es gemeldet hast.

  • Ich hatte dieses Problem früher auch, und es war extrem frustrierend. Wegen "Network error" konnte ich einen Artikel, an dem ich monatelang geschrieben hatte, nicht aktualisieren; ich dachte, es läge daran, dass der Artikel durch die Bearbeitung länger geworden war, und fand die Ursache nicht.
    Den Support zu kontaktieren war wegen des AI-Chatbots ebenfalls schwierig, und als ich endlich einen Menschen erreichte, schien deren „technischer Support“ nicht die Absicht zu haben, sich das in angemessener Zeit anzusehen.
    Erst als jemand auf Twitter die Möglichkeit eines magischen Strings ins Spiel brachte, der dumme Sicherheitslogik auslöst, fand ich das Problem und konnte den Artikel schließlich ändern.