`/etc/hosts` dosya yolunun yazılması Substack editöründe hataya neden oluyor

• Substack editöründe belirli sistem yolları girildiğinde ağ hatası oluşuyor
• Web uygulaması güvenlik duvarı (WAF), bu tür yolları dizin geçişi saldırıları ve komut ekleme saldırılarını önlemek için engelliyor
• Güvenlik ile kullanılabilirlik arasındaki denge önemli bir sorun olarak öne çıkıyor
• Teknik yazarlar için daha iyi bir çözüme ihtiyaç var
• Sorun, alternatif bir yol gösterimi kullanılarak aşılabiliyor

---

/etc/h*sts Substack editörünü bozduğunda: web içerik filtrelemesinin macerası

Gizemli ağ hatası

• DNS çözümlemesi hakkında teknik bir yazı hazırlanırken beklenmedik bir hata ortaya çıktı
• /etc/h*sts yolu girildiğinde ağ hatası oluştu ve otomatik kaydetme başarısız oldu
• Substack’in durum sayfası her şeyin normal çalıştığını gösteriyordu

İnceleme başlıyor

• Belirli bir dosya yolu yazıldığında hata oluşuyor, yol değiştirildiğinde ise normal çalışıyordu
• /etc/h*sts gibi yollar hata üretirken, değiştirilmiş sürümlerinde sorun yaşanmıyordu

İçeride neler oluyor?

• Tarayıcı geliştirici araçlarında 403 Forbidden yanıtı görüldü
• Olayda Cloudflare’ın rol oynadığı anlaşıldı

Web uygulaması güvenlik filtrelerini anlamak

Kısaca WAF

• Web uygulaması güvenlik duvarı (WAF), bir web sitesinin güvenlik görevlisi gibi çalışır
• Şüpheli istekleri engeller

Dizin geçişi saldırıları: neden dikkat çekiyor?

• Dizin geçişi saldırıları, hassas sistem dosyalarına erişme girişimleridir
• /etc/h*sts gibi yollar bu yüzden saldırı hedefi olarak değerlendirilebilir

Komut ekleme: bir başka güvenlik sorunu

• Komut ekleme saldırıları, sistem komutlarının çalıştırılmasını hedefler
• Sistem yollarından söz edildiğinde filtreler bunu engelleyebilir

Gizem derinleşiyor: tarihsel örnekler

• Başka Substack gönderilerinde benzer yol kullanım örnekleri bulundu
• Filtreleme davranışının belirli bir noktada değişmiş olabileceği düşünülüyor

Güvenlik ve kullanılabilirlik: hassas denge

• Substack’in filtreleri koruma amacı taşısa da teknik yazarlar için bir engele dönüşüyor
• İyileştirme alanları var: daha açık hata mesajları, teknik içeriği tanıma, belgelenmiş geçici çözümler sunma

HTTP yanıtına bakış

• API seviyesinde 403 Forbidden durum kodu doğrulandı

Teknik içerik platformları için daha iyi çözümler

1. Bağlamsal filtreleme: kod blokları veya teknik tartışmalarda sistem yollarını tanıyabilme
2. Açık hata mesajları: "ağ hatası" yerine engellemenin güvenlik filtresinden kaynaklandığını belirtme
3. Belgelenmiş geçici çözümler: hassas yolların nasıl tartışılabileceğine dair yöntemler sunma

Sonuç: güvenlik ile teknik yazının kesişimi

• Substack editöründeki sorun, güvenlik ile teknik yazım arasındaki karmaşık zorlukları ortaya koyuyor

• Güvenlik filtreleri açısından saldırı kalıbı gibi görünen bir şey, gerçekte meşru içerik olabilir

• Sorun, alternatif bir yol gösterimi kullanılarak çözülebilir

• Benzer filtreleme sorunlarını başka platformlarda yaşayıp yaşamadığınızı yorumlarda paylaşmanız isteniyor

[GN⁺]

Hacker News görüşleri

• CDN’de WAF kuralları yapılandıran kişilerin, teknik içerikle uğraşan site ve hizmetleri çoğu zaman doğru anlamadığı oluyor. Bu yalnızca Cloudflare’a özgü bir sorun değil; Akamai’de de benzer durumlar var.
  Veritabanlarının tartışıldığı bir sitede temel SQL enjeksiyonu önleme kurallarını açarsanız site bozulur; dosya dahil etme kural setleri de /etc/hosts, /etc/passwd gibi dizeleri engeller.
  Bunun güvenlik ile kullanılabilirlik arasında bir denge yönü de var. Hangi hizmetin zayıf uygulanmış olduğunu bilemeyeceğiniz için tüm WAF kurallarını eklemek bir açıdan daha güvenli hale getirebilir. Ancak güvenli uygulanmış bir hizmetin teknik kavramları tartışması gerektiğinde aynı kural setleri çok can sıkıcı olur.
  Kuralları ince ayarlamak çok zaman alır. Sorgu parametresinde /etc/hosts olduğu için sayfanın açılmamasını düzeltirsiniz; bu kez yönlendiren bilgide /etc/hosts bulunduğu için XHR kaynağı yüklenmez, ardından analiz için kullanılan JS kütüphanesi ziyaret URL’sini çereze koyduğu için yine bozulur; sonunda kuralları tamamen kapatmak istersiniz.

  • Güvenlik ve kullanılabilirliğin yanında ekonomik yön de var. Dışarıdan aptalca görünen güvenlik politikaları çoğu zaman sigorta şirketlerinin taleplerinden doğuyor.
    Sigorta şirketi “çalışan parolalarını 90 günde bir değiştirtmezseniz priminizi %20 artırırız” derse, NIST’in 10 yıldan da önce periyodik parola değişimini önermeyecek şekilde güncelleme yaptığını ve bunun kötü bir uygulama olduğunu ne kadar doğru şekilde anlatsanız da prim artar.
    Bu yüzden iç çekerek parola süresi dolma politikasını uygular ve çalışanların sizi beceriksiz diye şikâyet etmesini dinlersiniz. log4shell çok meşhur olduğu için, sigorta şirketlerinin artık sunucuların /etc/hosts, /etc/passwd, jndi: gibi yaygın “hackleme dizelerini” reddetmesini istemesine de şaşırmam.
  • “Ne olur ne olmaz” en kötü güvenlik yaklaşımıdır ve tüm sistemi aslında daha az güvenli hale getirir. Güvenlik için parolaları her ay değiştirmek, 20 karakterlik alfanümerik ve 5 sembollü parola istemek, yüzlerce sayfalık kontrol listeleriyle gelen her türlü 3 harfli uyumluluk sürecinden geçmek, kontrol listesinde olduğu için sunucuda WAF’ı da açmak gibi şeylere dönüşür.
    CIO’ya bunun gerçekte hangi tehdidi engellediğini sorarsanız karşılık olarak boş bir bakış alırsınız.
    Bir mühendis açısından her giriş formunun nereye gittiğini anlayıp anlamlı şekilde temizlemeye çaba göstermek için teşvik yoktur. Para kazandıran iş, kutucukları işaretleyip geçmektir; yeni başlayanlar da bunu çabucak öğrenir. Böyle organizasyonlar güvenliği iyileştirmeye değil, ihlal yaşandıktan sonra sorumluluktan kaçmaya odaklanır.
  • Bu, filtrenin fazla saf ve agresif şekilde, üstelik yanlış içeriğe uygulanmış olduğu Scunthorpe probleminin bir çeşidi gibi görünüyor.
    Sunucuya gidip gelen ya da sunucular arasında aktarılan “başka şeylere” filtre uygulamak mantıklı olabilir; ama blog içeriği olarak gösterilecek gerçek metin gövdesini filtrelemenin güvenlik açısından bir faydası varmış gibi görünmüyor. Bana oldukça açık bir hata gibi geliyor.
    https://en.wikipedia.org/wiki/Scunthorpe_problem
  • CDN seviyesinde giriş alanlarında neden SQL enjeksiyonu filtrelemesi yapıldığını anlamıyorum. Uzunluk ya da sayı/tarih gibi basit tür doğrulamaları dışında giriş alanı doğrulamasını CDN’de yapmak için bir sebep yok.
    Backend, giriş alanlarındaki rastgele bayt içeriğini işleyebilmelidir; CDN katmanında ön filtreleme yok diye SQL enjeksiyonuna açık olmamalıdır.
  • İstenen kaynağın içeriğinde herhangi bir yerde "/etc/hosts" dizesi aynen geçti diye tetiklenen bir WAF ise, oldukça bariz şekilde bozuk görünüyor.

• Aklıma bir e-ticaret platformuyla ilgili bir hikâye geldi. Biri bellek sızıntısı olan bir web mağazası yapmıştı; geçici çözüm olarak loglarda "OutOfMemoryException" dizesi görünürse uygulamayı yeniden başlatacak şekilde ayarlamışlardı.
  Sonra başka bir geliştirici müşteri arama terimlerini loglamak istedi; biri arama kutusuna "OutOfMemoryException" yazarsa…

  • Serbest biçimli metin loglarını dikkatsizce analiz etmek, hafife alınan bir sistem istismarı yolu. Bant dışı kaçış ya da temizleme olmadan veriyi gelişigüzel loglayan çok yazılım var; bu ürkütücü.
  • WAF yüzünden bunu gerçekten birkaç kez yaşadım. Kullanıcı "system(...)" dizesi içeren bir not bırakmıştı; WAF bunu PHP enjeksiyonu sayıp IP engellemesi uyguladı.

• /etc//hosts ya da /etc/./hosts da engelleniyor mu merak ediyorum. Bu tür köstebek avı kaçınılmaz olarak başarısız olur.
  Bunu yapanların, saldırganların kendilerinden daha zeki ve daha inatçı olduğunu bilmesi ve yalnızca doğrulanmış güvenlik yöntemlerine, örneğin güvenilmeyen girdiyi çalıştırmamaya dayanması gerekir.

  • Doğru. Bu, Fortune 500 şirketlerinde yaygın olan zorunlu bir kutucuk gibi görünüyor. Web uygulaması güvenlik duvarı mutlaka olmalı; kuralların ne olduğu önemli değil, birkaç tane olması yeterli.
    Bir keresinde SQL veritabanı kullanmayan bir uygulama için SQL enjeksiyon saldırılarını engellemek üzere WAF gerektiği bile söylenmişti.
    İtiraz edince her zaman “katmanlı savunma” nutku dinlersiniz; her perşembe sabahı masaya bir kez vurup olduğunuz yerde üç tur dönmenin daha etkili olduğunu söylerseniz size gerçekten deliymişsiniz gibi bakarlar. Bunu her hafta yaptım ve hiç hacklenmedim; katmanlı savunma değil mi yani? Zararı yok ya.
  • Kötü şeyleri listelemek kaybettiren bir stratejidir. 1995’te ilk işime başladıktan yaklaşık 5 dakika sonra bunun kötü bir fikir olduğunu anlamıştım.
  • Az önce Substack’te hesap açıp test ettim; ya sorunu çoktan düzeltmişler ya da WAF’ı tamamen kapatmışlar gibi görünüyor.
  • Bunun neden zor olduğunu bilmiyorum. Bir dizenin mutlak yolunu elde etme işlevi neredeyse her dilin standart kütüphanesinde var. İçinde eğik çizgi olan dizeleri bulup yorumlamak yeterli.
    Joker karakter çözümleme daha zor, ama yasaklı dosyalar listesi varsa gayet mümkün.
    https://nodejs.org/api/path.html#pathresolvepaths
    Düzenleme: C’deki realpath biraz farklı çalışıyor; bağlantıyı değiştirdim.
  • Adanmış bir saldırganı durduramıyorsa bir güvenlik çözümünün değeri yok mudur? Birçok WAF kuralı, hazır zafiyet tarayıcılarının keşif isteklerini engellemek için kullanılır.

• Substack’in teknik yazarlar için bu durumu nasıl iyileştirebileceğini mi soruyorsunuz?
  Herhangi bir konuyu, hatta aptal bir WAF’i tetikleyecek dizgileri bile ele alabilmesi gereken yazı düzenleme endpoint’ine taş kadar aptal bir web uygulaması güvenlik duvarı koymayarak.
  Bu, bir web geliştirme forumunun XSS filtresi koyup üyelerin XSS hakkında konuşmasını engellemesine benziyor. İçeriği düzgün şekilde escape etmeyi öğrenmeleri gerekiyor

  • Güvenlik sertifikasyonundan geçmek için WAF çalıştırmak zorunda oldukları bir durumdalar. Açık kaynak WAF olarak aşağı yukarı yalnızca modsecurity ve onun beta halindeki ardılı coraza var
    Bunlar aptal ve yalnızca OWASP’nin coreruleset adlı okunması zor çöp yığınını kullanıyor
  • Siber güvenlikten sorumlu birini işe almaları gerekiyor. Görünüşe göre yok

• Bu örneğin web güvenliğinde koruma ile kullanılabilirlik arasındaki ilginç gerilimi gösterdiği görüşüne katılmak zor. Bu sadece bir bug, hem de aptalca bir bug. Daha iyisini bilmesi gereken insanların bilmediğini gösteriyor sadece
  Güvenlik ile kullanılabilirlik arasındaki gerilim gerçekten var, ama bu o değil. Genelde iyi güvenlik uygulayıp kullanıcıyı rahatsız eden türden bir ödünleşimdir. İki aşamalı kimlik doğrulama, 3 başarısız denemeden sonra kilitleme, DoS’u önlemek için hız sınırlaması gibi güvenliği artırınca kullanıcı deneyimi kötüleşir; kullanıcı deneyimini artırınca güvenlik düşer
  Bu ikisi de değil. Kötü güvenlik ve kötü kullanıcı deneyimi. Burada gerilimin nerede olduğunu anlamıyorum

  • Genel olarak tüm endpoint’lere WAF’i topluca uygulayıp, böyle sorunlar çıktığında seçerek kaldırmanın faydalı bir güvenlik pratiği olduğunu düşünüyorum. Özellikle eklentili Wordpress gibi üçüncü taraf yazılımları barındırırken tüm açık endpoint’leri tek tek değerlendirmek çok daha zor
  • PHP 3 dönemini hatırlatıyor. PHP’nin SQL injection’ı topluca engellemek için URL isteği içeriklerini “temizlediğini” hatırlıyor gibiyim; ya da paylaşımlı hostinglerde sıkça açık olan bir ayar da olabilir
    Elbette PHP sitesi yazarları bunu kısa sürede fark etti ve çeşitli bypass teknikleri kullanıldı; genel olarak bu “temizleme” hiç olmasaydı muhtemelen sonuç daha iyi olurdu

• Daha önce bir kez başıma geldikten sonra, “ağ hatası” ifadesini görür görmez sebep hemen aklıma geldi
  Yarışmalı programlama takımına ders verirken sınıftaki öğrencilerin yarısı çözüm gönderdiklerinde boş sayfa alıyordu; bir saatlik debugging’den sonra, kodda görününce 403’e yol açan birkaç C++ tipi ve anahtar sözcüğe kadar daralttık, hepsi JavaScript’te de anlamı olan şeylerdi
  Bankada çalışırken de Python dosyası göndermem gereken bir API vardı; çoğu Python dosyası 403 veriyor, kısa dosyalar geçiyordu. Saatlerce debugging’den sonra kodda ara sıra görünen tek bir anahtar sözcüğe kadar daralttık
  Birkaç ay sonra yeni bir bulut ortamında da aynı şey oldu ve yine birkaç saat harcadık. İkincisinden sonra bir iş arkadaşım dağıtım script’ine 403 alırsa "HAHAHA YOU'VE BEEN WAFFED" yazdıracak şekilde ekleme yaptı; bu hatayı beklediğimden çok daha sık gördüğüm için hâlâ minnettarım

  • Bunun Cloudflare mı, yoksa başka bir WAF mi olduğunu hatırlayıp hatırlamadığını merak ediyorum

• Bizim uygulamamızda da benzer bir şey yaşadık. Dahili red team, XSS ve başka injection saldırısı denemeleri içeren veriler yayımlıyordu
  Saldırının kendisi başarılı olmadı, ama bu öğelerin varlığı nedeniyle şirket güvenlik duvarı, o payload’u içeren ağ isteklerini engelledi ve dahili yönetici sayfası yüklenmedi. Sonuçta başarısız XSS saldırısı etkili bir DoS saldırısına dönüşmüş oldu

• Eski olan yeniden yeni olmuş gibi. Eskiden buna Scunthorpe problemi denirdi
  https://en.m.wikipedia.org/wiki/Scunthorpe_problem

  • Eski Eve Online forumlarında cockpit kelimesinin her zaman c***pite dönüştüğünü hatırlıyorum. Epey komikti
  • Yakın zamanda ABD hükümet sitelerinde “diversity”, “equity”, “inclusion” gibi kelimelerin silinmesi de akla geliyor
    Biyoloji, finans ya da jeoloji hakkında yazıyorsanız? Şansınıza küsün
    Akıllı ve iyi niyetli biri tarafından yazılsa bile aptal filtreleme yeterince kötüdür
  • Artık bu Substack örneğini Wikipedia maddesine ekleme zamanı geldi

• Dün gece OpenRouter’da da benzer bir sorunla karşılaştım. OpenRouter, birden çok LLM’i tek bir endpoint üzerinden kullanmayı sağlayan “santral” tarzı bir servis olduğu için harika; dün gece ham HTML’i çeşitli şekillerde işlemek için hangi modelin iyi olduğunu test etmeye başladım
  Ancak OpenRouter API’si Cloudflare ile korunduğu için, POST isteği gövdesinde belirli ham HTML ve JavaScript parçaları olunca isteklerin tamamı değil ama çoğu engelleniyor. Aynı prompt’u doğrudan OpenAI veya Anthropic’e gönderince sorun yok
  Ücretsiz modellerde kötüye kullanımı önlemeyi sıkı tutmalarını anlarım, ama bu ticari modeller için ücretlendirilen bir istek olduğundan daha da can sıkıcı

  • Bildirip bildirmediğini merak ediyorum

• Daha önce bu sorunu yaşadım ve inanılmaz sinir bozucuydu. "Network error" yüzünden aylar boyunca yazdığım bir yazıyı güncelleyemedim; düzenlemelerle yazı uzadığı için olduğunu sanıp sebebini bulamadım
  Destek ekibine ulaşmak da yapay zeka chatbot’u yüzünden zordu; nihayet bir insana ulaştığımda bile “teknik destek”lerinin makul bir süre içinde bakmaya niyeti yok gibi görünüyordu
  Twitter’daki bir kişi aptal güvenlik mantığını tetikleyen bir sihirli dizge olasılığını öne sürene kadar sorunu bulamadım; sonunda yazıyı düzeltebildim