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

• 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

[GN⁺]

Hacker-News-Kommentar

• Menschen, die WAF-Regeln in einem CDN konfigurieren, verstehen Websites und Dienste mit technischen Inhalten oft nicht besonders gut. Nicht nur Cloudflare, auch Akamai hat dasselbe Problem

  • Bei Websites, die mit Datenbanken arbeiten, kann schon das Aktivieren grundlegender Regeln zum Schutz vor SQL-Injection die Seite kaputtmachen
  • Es gibt auch Regelsets für Dateieinbindungen, sodass Dinge wie /etc/hosts oder /etc/passwd blockiert werden
  • Ich denke, das Gleichgewicht zwischen Sicherheit und Nutzbarkeit ist wichtig. Wenn man alle WAF-Regeln anwendet, steigt zwar die Sicherheit, aber für Dienste, auf denen technische Konzepte diskutiert werden müssen, ist das unpraktisch
  • Regeln fein granular abzustimmen kostet viel Zeit. Damit Anwendungsfälle erlaubt bleiben und die Regeln trotzdem aktiv sind, sind viele Änderungen nötig
  • Es kann zu Problemen kommen, etwa dass Seiten oder Ressourcen nicht geladen werden. Da kommt schnell die Versuchung auf, die Regeln einfach abzuschalten

• Das erinnert mich an eine Anekdote über eine E-Commerce-Plattform: Jemand hatte einen Webshop mit Memory Leak programmiert und das Problem so „gelöst“, dass die App neu gestartet wurde, sobald im Log die Zeichenfolge OutOfMemoryException auftauchte

  • Ein anderer Entwickler wollte die Suchanfragen der Kunden protokollieren, und wenn jemand in das Suchfeld OutOfMemoryException eingab, gab es Probleme

• Ich frage mich, ob /etc/hosts oder /etc/./hosts blockiert wird. Das wirkt wie ein zwangsloses Whack-a-Mole-Spiel. Hacker sind klüger und entschlossener, daher sollte man sich nur auf bewährte Sicherheit verlassen

• Gedanken dazu, wie Substack diese Situation für technische Autoren verbessern könnte

  • Man sollte keine dumme WAF auf einem Endpunkt laufen lassen, auf dem Leute Texte zu beliebigen Themen bearbeiten können
  • Das ist so, als würde man in einem Webentwicklungsforum einen XSS-Filter einbauen, sodass Mitglieder nicht mehr über XSS sprechen können
  • Man sollte lernen, Inhalte korrekt zu escapen

• Das hebt einen interessanten Fall der Spannung zwischen Schutz und Nutzbarkeit in der Websicherheit hervor

  • In diesem Fall wird aber eher ein Bug hervorgehoben. Die Spannung zwischen Sicherheit und Nutzbarkeit existiert tatsächlich, aber hier geht es nicht darum
  • Die Spannung zwischen Sicherheit und Nutzbarkeit ist normalerweise ein Trade-off. Mehr Sicherheit verschlechtert die User Experience
  • Dieser Fall zeigt sowohl schlechte Sicherheit als auch eine schlechte User Experience

• Ein Problem aus der Zeit, als ich ein Team für Competitive Programming unterrichtete: Wenn C++-Typen und Keywords im Code auftauchten, gab es einen 403-Fehler

  • Als ich bei einer Bank arbeitete, gab es eine API, bei der Python-Dateien eingereicht werden mussten, und die meisten Python-Dateien führten zu einem 403-Fehler
  • Auch in einer neuen Cloud-Umgebung trat ein ähnliches Problem auf

• Ein Problem, das auftrat, als ein internes Red Team Daten veröffentlichte, die XSS- und andere Injektionsangriffe enthielten

  • Der Angriff selbst funktionierte nicht, aber allein die Existenz solcher Einträge verhinderte das Laden interner Admin-Seiten

• Ein altes Problem taucht wieder auf. Man nennt das das Scunthorpe-Problem

• Ich hatte ein ähnliches Problem mit OpenRouter. OpenRouter ist ein Dienst, der einen einzigen Endpunkt bereitstellt, über den verschiedene LLMs genutzt werden können

  • Wenn bestimmte HTML- und JavaScript-Schnipsel im Body einer POST-Anfrage enthalten waren, wurden viele Anfragen blockiert

• Inhaltsfilterung sollte stark vom Kontext abhängen. Wenn die WAF von dem getrennt ist, was sie filtern soll, entstehen Probleme

  • Das ist ähnlich wie bei Spam-Filtern. Ein Mailserver filtert abhängig von der Konfiguration des sendenden Servers
  • Zustellungsbasierte Filterung ist wirksamer als inhaltsbasierte Filterung. Dasselbe gilt für Websites und WAFs