Error Editor Substack Terjadi karena Menulis File "/etc/hosts"

• Di editor Substack, saat memasukkan jalur sistem tertentu, muncul kesalahan jaringan
• Web Application Firewall (WAF) memblokir jalur seperti ini untuk mencegah serangan path traversal dan serangan command injection
• Keseimbangan antara keamanan dan kemudahan penggunaan menjadi isu penting
• Diperlukan solusi yang lebih baik untuk penulis teknis
• Masalah dapat diatasi dengan menggunakan jalur alternatif

---

Ketika /etc/h*sts Mengganggu Editor Substack: Petualangan Pemfilteran Konten Web

Kesalahan jaringan yang misterius

• Saat mengerjakan posting teknis tentang resolusi DNS, muncul kesalahan tak terduga
• Saat memasukkan jalur /etc/h*sts, terjadi kesalahan jaringan dan penyimpanan otomatis gagal
• Halaman status Substack menunjukkan layanan berjalan normal

Investigasi dimulai

• Kesalahan terjadi saat memasukkan jalur file tertentu, tetapi berjalan normal bila jalurnya diubah
• Jalur seperti /etc/h*sts memicu kesalahan, sedangkan bentuk yang dimodifikasi tidak menimbulkan masalah

Apa yang terjadi di balik layar?

• Di alat pengembang browser, terlihat respons 403 Forbidden
• Cloudflare terlibat

Memahami filter keamanan aplikasi web

Penjelasan singkat tentang WAF

• Web Application Firewall (WAF) berperan sebagai petugas keamanan untuk situs web
• Ia memblokir permintaan yang mencurigakan

Serangan path traversal: alasan untuk waspada

• Serangan path traversal adalah upaya mengakses file sistem sensitif
• Jalur seperti /etc/h*sts dapat menjadi target serangan

Command injection: masalah keamanan lainnya

• Serangan command injection bertujuan memicu eksekusi perintah sistem
• Saat jalur sistem disebutkan, filter dapat melakukan pemblokiran

Misteri makin dalam: contoh historis

• Ditemukan contoh penggunaan jalur serupa di posting Substack lain
• Ada kemungkinan perilaku pemfilteran berubah pada titik waktu tertentu

Keamanan vs kemudahan penggunaan: keseimbangan yang rumit

• Filter Substack ditujukan untuk perlindungan, tetapi menjadi hambatan bagi penulis teknis
• Ada ruang untuk perbaikan: pesan kesalahan yang jelas, pengenalan konten teknis, dan solusi yang terdokumentasi

Meninjau respons HTTP

• Di level API, dikonfirmasi kode status 403 Forbidden

Solusi yang lebih baik untuk platform konten teknis

1. Pemfilteran kontekstual: mengenali jalur sistem dalam blok kode atau diskusi teknis
2. Pesan kesalahan yang jelas: menjelaskan bahwa pemblokiran disebabkan oleh filter keamanan, bukan sekadar "kesalahan jaringan"
3. Solusi terdokumentasi: menyediakan cara untuk membahas jalur sensitif

Kesimpulan: persimpangan antara keamanan dan penulisan teknis

• Masalah pada editor Substack menyoroti tantangan kompleks antara keamanan dan penulisan teknis

• Apa yang tampak seperti pola serangan bagi filter keamanan sebenarnya bisa merupakan konten yang sah

• Masalah dapat diatasi dengan menggunakan jalur alternatif

• Permintaan agar pembaca membagikan pengalaman mereka di komentar jika pernah mengalami masalah pemfilteran serupa di platform lain

[GN⁺]

Pendapat Hacker News

• Orang-orang yang mengatur aturan WAF di CDN sering kali tidak benar-benar memahami situs dan layanan yang menangani konten teknis. Ini bukan hanya masalah Cloudflare; Akamai juga mirip
  Jika aturan dasar pencegahan SQL injection diaktifkan pada situs yang membahas database, situsnya bisa rusak, dan ruleset file inclusion akan memblokir string seperti /etc/hosts dan /etc/passwd
  Memang ada sisi keseimbangan antara keamanan dan kegunaan. Karena kita tidak tahu layanan mana yang diimplementasikan secara rentan, menumpuk semua aturan WAF memang bisa membuatnya lebih aman. Namun, ketika layanan yang diimplementasikan dengan aman perlu membahas konsep teknis, ruleset yang sama menjadi sangat merepotkan
  Menyetel aturan secara rinci memakan banyak waktu. Setelah memperbaiki halaman yang tidak muncul karena parameter kueri berisi /etc/hosts, berikutnya resource XHR tidak muncul karena referrer berisi /etc/hosts, lalu berikutnya library JS untuk analitik memasukkan URL kunjungan ke cookie dan rusak lagi; akhirnya rasanya ingin mematikan saja aturannya

  • Selain keamanan dan kegunaan, ada juga ekonomi. Kebijakan keamanan yang tampak bodoh sering kali muncul karena tuntutan perusahaan asuransi
    Jika perusahaan asuransi berkata, “Kalau Anda tidak membuat karyawan mengganti kata sandi setiap 90 hari, premi akan kami naikkan 20%,” maka meski NIST sudah lebih dari 10 tahun lalu mengubah rekomendasinya agar tidak menganjurkan penggantian kata sandi berkala, dan meski benar bahwa itu praktik buruk, premi tetap naik
    Jadi orang menghela napas sambil menerapkan kebijakan kedaluwarsa kata sandi, lalu mendengar keluhan karyawan bahwa mereka tidak kompeten. Karena log4shell sudah begitu terkenal, tidak mengherankan jika sekarang perusahaan asuransi menuntut server menolak “string peretasan” umum seperti /etc/hosts, /etc/passwd, dan jndi:
  • “Untuk berjaga-jaga” adalah cara keamanan terburuk, dan justru membuat seluruh sistem menjadi kurang aman. Demi keamanan, kata sandi diganti setiap bulan, diminta 20 karakter alfanumerik plus 5 simbol, harus lolos berbagai compliance tiga huruf dengan checklist ratusan halaman, dan karena ada di checklist, WAF juga harus diaktifkan di server
    Jika bertanya kepada CIO ancaman nyata apa yang sebenarnya dicegah oleh ini, yang kembali hanya tatapan kosong
    Dari sudut pandang engineer, tidak ada insentif untuk memahami setiap form input mengarah ke mana dan melakukan sanitasi dengan cara yang bermakna. Pekerjaan yang dibayar adalah mencentang checkbox lalu lanjut, dan karyawan baru pun cepat belajar itu. Organisasi seperti ini tidak berfokus meningkatkan keamanan, melainkan menghindari tanggung jawab setelah terjadi insiden pembobolan
  • Ini terlihat seperti variasi dari Scunthorpe problem, ketika filter diterapkan terlalu naif dan agresif, bahkan pada konten yang salah
    Menerapkan filter pada “hal-hal lain” yang keluar-masuk server atau dikirim antarsesama server mungkin masuk akal, tetapi tampaknya tidak ada manfaat keamanan dari memfilter teks isi sebenarnya yang akan ditampilkan sebagai konten blog. Menurut saya ini cukup jelas lebih mirip bug
    https://en.wikipedia.org/wiki/Scunthorpe_problem
  • Saya tidak mengerti mengapa filtering SQL injection pada field input dilakukan di level CDN. Selain validasi panjang atau tipe sederhana, misalnya angka atau tanggal, tidak ada alasan memvalidasi field input di CDN
    Backend harus mampu menangani isi byte arbitrer dari field input, dan tidak boleh rentan terhadap SQL injection hanya karena tidak ada pra-filtering di lapisan CDN
  • Jika WAF terpicu hanya karena string "/etc/hosts" muncul apa adanya di bagian mana pun dari konten resource yang diminta, sepertinya itu jelas-jelas rusak

• Saya jadi teringat kisah sebuah platform e-commerce. Seseorang membuat webshop yang mengalami memory leak, dan sebagai workaround, aplikasi disetel untuk restart jika string "OutOfMemoryException" muncul di log
  Lalu developer lain ingin mencatat kata kunci pencarian pelanggan ke log, dan ketika seseorang mengetik "OutOfMemoryException" di kotak pencarian…

  • Menganalisis log teks format bebas secara ceroboh adalah jalur eksploitasi sistem yang diremehkan. Menakutkan melihat banyak software yang begitu saja menulis data ke log tanpa escaping out-of-band atau sanitasi
  • Saya benar-benar beberapa kali mengalami hal seperti ini karena WAF. Pengguna meninggalkan catatan berisi string "system(...)", lalu WAF menganggapnya sebagai PHP injection dan memblokir IP

• Saya penasaran apakah /etc//hosts atau /etc/./hosts juga diblokir. Permainan whack-a-mole seperti ini pasti gagal
  Orang-orang yang membuat hal seperti ini harus tahu bahwa penyerang lebih pintar dan lebih gigih daripada mereka, dan hanya boleh bergantung pada cara keamanan yang sudah teruji, misalnya tidak mengeksekusi input yang tidak tepercaya

  • Benar. Ini terlihat seperti checkbox wajib yang umum di Fortune 500. Web application firewall harus ada, aturan apa yang dipakai tidak penting, yang penting ada beberapa
    Saya pernah diberi tahu bahwa sebuah aplikasi yang tidak memakai database SQL tetap membutuhkan WAF untuk mencegah serangan SQL injection
    Kalau membantah, selalu saja mendapat ceramah “defense in depth”, dan ketika saya bilang mengetuk meja sekali setiap Kamis pagi lalu berputar di tempat tiga kali akan lebih efektif, mereka menatap saya seperti orang gila. Padahal saya melakukannya setiap minggu dan tidak pernah diretas, jadi bukankah itu defense in depth? Tidak ada ruginya, kan
  • Mendaftar hal-hal buruk adalah strategi yang kalah. Sekitar 5 menit setelah memulai pekerjaan pertama saya pada 1995, saya sudah tahu itu ide buruk
  • Saya baru saja membuat akun di Substack untuk mengujinya, dan sepertinya mereka sudah memperbaiki masalahnya atau mematikan WAF sepenuhnya
  • Saya tidak mengerti mengapa itu sulit. Fungsi untuk mendapatkan absolute path dari string ada di hampir semua standard library bahasa. Cukup cari string yang mengandung slash dan coba interpretasikan
    Interpretasi wildcard memang lebih rumit, tetapi jika ada daftar file terlarang, itu cukup mungkin dilakukan
    https://nodejs.org/api/path.html#pathresolvepaths
    Edit: realpath di C bekerja sedikit berbeda, jadi saya mengganti tautannya
  • Apakah solusi keamanan tidak bernilai jika tidak bisa menghentikan penyerang yang berdedikasi? Banyak aturan WAF digunakan untuk memblokir request probing dari vulnerability scanner siap pakai

• Bagaimana Substack bisa memperbaiki situasi ini untuk penulis teknis?
  Cukup jangan memasang web application firewall yang sebodoh batu pada endpoint penyuntingan tulisan yang harus bisa membahas topik apa pun, bahkan string yang memicu WAF bodoh sekalipun.
  Ini seperti forum pengembangan web yang memasang filter XSS sehingga anggotanya tidak bisa membicarakan XSS. Mereka perlu belajar cara melakukan escaping konten dengan benar.

  • Mereka berada dalam posisi harus menjalankan WAF agar lolos sertifikasi keamanan. WAF open source praktis hanya modsecurity dan penerus beta-nya, coraza.
    Keduanya bodoh, dan hanya memakai tumpukan sampah sulit dibaca bernama coreruleset dari OWASP.
  • Mereka perlu mempekerjakan orang keamanan siber. Sepertinya tidak ada.

• Sulit untuk setuju dengan pernyataan bahwa kasus ini menunjukkan ketegangan menarik antara proteksi dan kegunaan dalam keamanan web. Ini cuma bug, dan bug yang bodoh pula. Ini hanya menunjukkan bahwa orang-orang yang semestinya lebih tahu ternyata tidak.
  Ketegangan antara keamanan dan kegunaan memang nyata, tetapi ini bukan itu. Biasanya komprominya berupa menerapkan keamanan yang baik namun membuat pengguna tidak nyaman. Seperti autentikasi dua faktor, penguncian setelah 3 kali gagal, atau rate limiting untuk mencegah DoS: keamanan naik membuat pengalaman pengguna memburuk, dan pengalaman pengguna naik membuat keamanan menurun.
  Ini bukan keduanya. Ini keamanan yang buruk sekaligus pengalaman pengguna yang buruk. Saya tidak tahu di mana letak ketegangannya.

  • Secara umum, menerapkan WAF secara menyeluruh ke semua endpoint lalu menghapusnya secara selektif ketika masalah seperti ini muncul adalah praktik keamanan yang berguna menurut saya. Terutama saat meng-host software pihak ketiga seperti Wordpress dengan plugin, mengevaluasi setiap endpoint publik satu per satu jauh lebih sulit.
  • Ini mengingatkan pada masa PHP 3. Seingat saya PHP dulu “membersihkan” isi request URL secara menyeluruh karena ingin memblokir SQL injection, atau mungkin itu pengaturan yang sering diaktifkan di shared hosting.
    Tentu saja para pembuat situs PHP segera menyadarinya, berbagai teknik bypass dipakai, dan secara keseluruhan kemungkinan hasilnya lebih buruk daripada jika “pembersihan” semacam itu tidak ada.

• Setelah pernah kena sekali dulu, begitu melihat kata “network error”, penyebabnya langsung terbayang.
  Saat mengajar tim competitive programming, separuh siswa di kelas mendapat halaman kosong ketika mengirim solusi. Setelah satu jam debugging, kami mempersempitnya ke beberapa tipe dan keyword C++ yang jika muncul di kode akan memicu 403, dan semuanya juga bermakna di JavaScript.
  Saat bekerja di bank juga ada API yang mengharuskan mengirim file Python; kebanyakan file Python mendapat 403, sedangkan file pendek lolos. Setelah berjam-jam debugging, kami mempersempitnya ke satu keyword yang sesekali muncul di kode.
  Beberapa bulan kemudian hal yang sama terjadi di lingkungan cloud baru, dan kami kembali membuang beberapa jam. Setelah kejadian kedua, seorang rekan membuat skrip deployment mencetak "HAHAHA YOU'VE BEEN WAFFED" kalau menerima 403, dan saya masih berterima kasih karena error itu muncul jauh lebih sering dari yang diperkirakan.

  • Penasaran apakah Anda ingat itu Cloudflare, atau WAF lain?

• Kami juga mengalami hal serupa di aplikasi kami. Red team internal mem-posting data yang berisi upaya XSS dan serangan injeksi lainnya.
  Serangannya sendiri tidak berhasil, tetapi karena item-item itu ada, firewall perusahaan memblokir request jaringan yang memuat payload tersebut, sehingga halaman admin internal tidak bisa dimuat. Pada akhirnya serangan XSS yang gagal berubah menjadi serangan DoS yang efektif.

• Hal lama menjadi baru lagi. Dulu hal seperti ini disebut Scunthorpe problem.
  https://en.m.wikipedia.org/wiki/Scunthorpe_problem

  • Saya ingat di forum Eve Online lama, kata cockpit selalu diubah menjadi c***pit. Cukup lucu.
  • Ini juga mengingatkan pada kejadian baru-baru ini ketika situs web pemerintah AS menghapus kata-kata seperti “diversity”, “equity”, dan “inclusion”.
    Kalau sedang menulis tentang biologi, keuangan, atau geologi? Ya nasib buruk saja.
    Filtering bodoh sudah cukup buruk meski ditulis oleh orang pintar dan berniat baik.
  • Sekarang saatnya menambahkan kasus Substack ini ke artikel Wikipedia.

• Tadi malam saya juga menemui masalah serupa di OpenRouter. OpenRouter adalah layanan bergaya “switchboard” yang memungkinkan memakai berbagai LLM dari satu endpoint, jadi sangat bagus, dan tadi malam saya mulai menguji model mana yang bagus untuk memproses HTML mentah dengan berbagai cara.
  Namun karena API OpenRouter dilindungi Cloudflare, jika body request POST berisi potongan HTML mentah dan JavaScript tertentu, banyak request—meski tidak semuanya—diblokir. Jika prompt yang sama dikirim langsung ke OpenAI atau Anthropic, tidak ada masalah.
  Kalau model gratis, saya bisa memahami pembatasan keras untuk mencegah penyalahgunaan, tetapi ini lebih mengganggu karena request tersebut ditagihkan untuk model komersial.

  • Penasaran apakah Anda sudah melaporkannya.

• Saya pernah mengalami masalah ini dulu dan sangat frustrasi. Karena "Network error", saya tidak bisa memperbarui tulisan yang sudah saya kerjakan selama berbulan-bulan, dan karena tulisan itu menjadi lebih panjang akibat pengeditan, saya mengira itulah penyebabnya dan tidak menemukan akar masalahnya.
  Menghubungi tim dukungan juga sulit karena chatbot AI, dan ketika akhirnya bisa tersambung ke manusia, “dukungan teknis” mereka tampaknya tidak berniat memeriksanya dalam waktu yang wajar.
  Baru setelah seseorang di Twitter menyarankan kemungkinan adanya string ajaib yang menyentuh logika keamanan bodoh, saya menemukan masalahnya, dan akhirnya bisa memperbaiki tulisan tersebut.