"/etc/hosts" फ़ाइल लिखने पर Substack एडिटर में त्रुटि

• Substack एडिटर में कुछ विशेष system path लिखने पर network error होता है
• web application firewall (WAF) ऐसे path को path traversal attack और command injection attack रोकने के लिए block करता है
• security और usability के बीच संतुलन एक अहम मुद्दे के रूप में उभरता है
• technical writers के लिए बेहतर समाधान की ज़रूरत है
• alternative path का उपयोग करके समस्या हल की जा सकती है

---

जब /etc/h*sts Substack एडिटर को बाधित करता है: web content filtering का रोमांच

रहस्यमय network error

• DNS resolution पर एक technical post लिखते समय unexpected error हुआ
• /etc/h*sts path दर्ज करते ही network error हुआ और autosave विफल हो गया
• Substack का status page दिखाता है कि सब सामान्य रूप से चल रहा है

जांच की शुरुआत

• किसी खास file path को लिखने पर error होता है, जबकि path को बदलने पर सामान्य रूप से काम करता है
• /etc/h*sts जैसे path error पैदा करते हैं, जबकि बदले हुए path में कोई समस्या नहीं होती

अंदर क्या हो रहा है?

• browser developer tools में 403 Forbidden response दिखा
• Cloudflare इसमें शामिल है

web application security filter को समझना

WAF संक्षेप में

• web application firewall (WAF) वेबसाइट के security guard की तरह काम करता है
• यह संदिग्ध request को block करता है

path traversal attack: सावधानी की वजह

• path traversal attack संवेदनशील system file तक पहुंचने की कोशिश होती है
• /etc/h*sts जैसे path attack target बन सकते हैं

command injection: एक और security समस्या

• command injection attack system command चलवाने की कोशिश करता है
• system path का ज़िक्र होने पर filter उसे block कर सकता है

रहस्य और गहरा होता है: ऐतिहासिक उदाहरण

• दूसरे Substack post में ऐसे ही path के इस्तेमाल का उदाहरण मिला
• संभव है कि filtering behavior किसी खास समय पर बदल गया हो

security बनाम usability: नाज़ुक संतुलन

• Substack का filter सुरक्षा के लिए है, लेकिन technical writers के लिए यह रुकावट बन जाता है
• सुधार की गुंजाइश है: स्पष्ट error message, technical content की पहचान, और documented workaround उपलब्ध कराना

HTTP response पर नज़र

• API स्तर पर 403 Forbidden status code की पुष्टि हुई

technical content platform के लिए बेहतर समाधान

1. contextual filtering: code block या technical discussion में system path को पहचानना
2. स्पष्ट error message: "network error" की जगह यह बताना कि security filter के कारण block हुआ
3. documented workaround: sensitive path पर चर्चा कैसे करें, यह बताना

निष्कर्ष: security और technical writing का संगम

• Substack एडिटर की यह समस्या security और technical writing की जटिल चुनौतियों को उजागर करती है

• जो चीज़ security filter को attack pattern लगती है, वह वास्तव में legitimate content भी हो सकती है

• alternative path का उपयोग करके समस्या का समाधान संभव है

• पाठकों से अनुरोध है कि यदि उन्होंने दूसरी platforms पर भी ऐसी filtering समस्या देखी हो तो comments में साझा करें

[GN⁺]

Hacker News की राय

• CDN पर WAF rules सेट करने वाले लोग अक्सर tech content से जुड़ी sites और services को ठीक से नहीं समझते। यह सिर्फ Cloudflare की समस्या नहीं है, Akamai भी काफ़ी हद तक ऐसा ही है
  अगर database पर चर्चा करने वाली किसी site पर basic SQL injection prevention rule चालू कर दिया जाए, तो site टूट जाती है, और file inclusion ruleset /etc/hosts, /etc/passwd जैसी strings को block कर देता है
  security और usability के बीच balance का पहलू भी है। किसी service को कितनी कमज़ोर तरह से implement किया गया है यह पता नहीं होता, इसलिए सभी WAF rules चढ़ा देने से कुछ मायनों में सुरक्षा बढ़ती है। लेकिन जब कोई सुरक्षित तरीके से implement की गई service को technical concepts पर चर्चा करनी हो, तो यही ruleset बेहद परेशान करने वाला हो जाता है
  rules को बारीकी से tune करने में बहुत समय लगता है। query parameter में /etc/hosts होने से page नहीं खुलने की समस्या ठीक करो, तो अब referrer में /etc/hosts होने की वजह से XHR resource नहीं खुलता, उसके बाद analytics JS library visit URL को cookie में डालती है और फिर वही टूट जाता है, तो बस rules बंद कर देने का मन करता है

  • security और usability ही नहीं, आर्थिक पक्ष भी है। ऊपर से बेवकूफ़ाना दिखने वाली security policies अक्सर insurer की requirements की वजह से बनती हैं
    अगर insurer कहे कि “कर्मचारियों से 90 दिन में password change नहीं करवाया तो premium 20% बढ़ा देंगे”, तो NIST ने 10 साल से भी पहले periodic password changes की recommendation वापस ले ली थी और यह बुरी practice है—यह सब सही होने पर भी premium बढ़ ही जाएगा
    इसलिए लोग भारी मन से password expiration policy implement करते हैं, और फिर कर्मचारियों की यह शिकायत सुनते हैं कि सिस्टम कितना अक्षम है। log4shell इतना मशहूर हो चुका है कि अब अगर insurer यह माँगें कि server /etc/hosts, /etc/passwd, jndi: जैसी आम “hacking strings” को reject करे, तो हैरानी नहीं होगी
  • “क्या पता ज़रूरत पड़ जाए” सबसे खराब security approach है, और यह पूरे system को उल्टा कम सुरक्षित बनाती है। सुरक्षा के नाम पर हर महीने password बदलवाना, 20 alphanumeric characters और 5 symbols माँगना, सैकड़ों पन्नों वाली checklist के साथ हर तरह की 3-letter compliance pass करवाना, और checklist में लिखा है इसलिए server पर WAF भी चालू करना—ऐसा ही होता है
    अगर CIO से पूछो कि इससे असल में कौन-सा threat रुकता है, तो सिर्फ खाली नज़र मिलती है
    engineer के नज़रिए से देखें तो हर input form कहाँ जाता है, इसे समझने और meaningful तरीके से sanitize करने की मेहनत करने का कोई incentive नहीं बचता। पैसे checkbox भरने और आगे बढ़ने के लिए मिलते हैं, और नए लोग भी यह बात जल्दी सीख जाते हैं। ऐसे संगठन security सुधारने पर नहीं, बल्कि breach के बाद ज़िम्मेदारी से बचने पर ध्यान देते हैं
  • यह filter को बहुत भोलेपन और आक्रामक तरीके से, वह भी गलत content पर लागू करने वाले Scunthorpe problem के एक variant जैसा लगता है
    server तक आने-जाने वाली या servers के बीच भेजी जाने वाली “दूसरी चीज़ों” पर filter लगाना समझ में आ सकता है, लेकिन blog content के रूप में दिखने वाले असली text body को filter करके कोई security benefit मिलता नहीं दिखता। यह काफ़ी हद तक एक साफ़ bug के करीब लगता है
    https://en.wikipedia.org/wiki/Scunthorpe_problem
  • समझ नहीं आता कि CDN level पर input fields की SQL injection filtering क्यों की जाती है। length या simple type validation, जैसे numbers या dates, को छोड़ दें तो input field validation CDN पर करने की कोई वजह नहीं है
    backend को input field के arbitrary byte contents को संभाल पाना चाहिए, और CDN layer पर pre-filtering न होने का मतलब यह नहीं होना चाहिए कि वह SQL injection के प्रति vulnerable है
  • अगर कोई WAF सिर्फ इस वजह से trigger हो जाए कि requested resource के content में कहीं भी string "/etc/hosts" जस की तस मौजूद है, तो वह काफ़ी साफ़ तौर पर टूटा हुआ लगता है

• इससे एक e-commerce platform का किस्सा याद आता है। किसी ने memory leak वाला web shop बना दिया था, और workaround के तौर पर log में "OutOfMemoryException" string दिखते ही app restart हो जाए, ऐसा सेट कर दिया था
  फिर किसी दूसरे developer ने customer search queries को log करना चाहा, और अगर कोई search box में "OutOfMemoryException" डाल दे तो…

  • free-form text logs का लापरवाही से analysis करना एक कम आंका गया system abuse vector है। बहुत-सा software बिना out-of-band escaping या sanitization के data को सीधे log में लिख देता है, जो डरावना है
  • WAF की वजह से मैंने भी ऐसी चीज़ें कई बार देखी हैं। किसी user ने "system(...)" string वाला note छोड़ा, और WAF ने उसे PHP injection मानकर IP block कर दिया

• सोच रहा हूँ कि /etc//hosts या /etc/./hosts को भी block करते हैं या नहीं। इस तरह का whack-a-mole शुरू से ही असफल होने वाला है
  यह बनाने वालों को समझना चाहिए कि attacker उनसे ज़्यादा चालाक और ज़िद्दी होगा, और उन्हें सिर्फ proven security practices पर निर्भर रहना चाहिए, जैसे untrusted input को execute न करना

  • सही कहा। यह Fortune 500 कंपनियों में आम mandatory checkbox जैसा लगता है। web application firewall तो होना ही चाहिए, rules क्या हैं यह मायने नहीं रखता, बस कुछ होने चाहिए
    एक बार मैंने यह तक सुना कि SQL database इस्तेमाल न करने वाले application को भी SQL injection attacks रोकने के लिए WAF चाहिए
    अगर आप तर्क दो, तो हमेशा “defense in depth” पर lecture सुनना पड़ता है, और अगर कहो कि हर गुरुवार सुबह desk पर एक बार थपकी मारकर अपनी जगह पर तीन चक्कर लगा लेना ज़्यादा असरदार होगा, तो लोग आपको सचमुच पागल समझते हैं। मैंने हर हफ्ते ऐसा किया है और कभी hack नहीं हुआ, तो यह भी defense in depth ही हुआ न। नुकसान तो नहीं है
  • बुरी चीज़ों की सूची बनाना हारने वाली strategy है। 1995 में अपनी पहली नौकरी शुरू करने के करीब 5 मिनट बाद ही समझ गया था कि यह बुरा idea है
  • मैंने अभी Substack पर account बनाकर test किया, लगता है या तो उन्होंने समस्या ठीक कर दी है या WAF पूरी तरह बंद कर दिया है
  • समझ नहीं आता कि यह मुश्किल क्यों है। string का absolute path निकालने की सुविधा लगभग हर language standard library में होती है। slash वाली string खोजकर उसे resolve कर सकते हैं
    wildcard resolution ज़्यादा पेचीदा है, लेकिन अगर banned files की list हो तो यह भी पूरी तरह संभव है
    https://nodejs.org/api/path.html#pathresolvepaths
    संपादन: C का realpath थोड़ा अलग तरह से काम करता है, इसलिए link बदल दिया
  • क्या अगर कोई security solution dedicated attackers को नहीं रोक सकता, तो वह बेकार है? बहुत-से WAF rules तैयारशुदा vulnerability scanners के probing requests को block करने के लिए इस्तेमाल होते हैं

• तकनीकी लेखकों के लिए Substack इस स्थिति को कैसे बेहतर बना सकता है?
  बस किसी web application firewall को, जो पत्थर जितना बेवकूफ हो, ऐसे लेख-संपादन endpoint पर मत लगाइए जहाँ किसी भी विषय पर लिखा जा सकता है, यहाँ तक कि ऐसे strings भी जो किसी बेवकूफ WAF को trigger कर दें
  यह वैसा ही है जैसे किसी web development forum में XSS filter लगा दिया जाए ताकि सदस्य XSS के बारे में बात ही न कर सकें। उन्हें content को सही तरीके से escape करना सीखना चाहिए

  • security certification पास करने के लिए WAF चलाना पड़ता है। open source WAF में लगभग सिर्फ modsecurity और उसका beta उत्तराधिकारी coraza ही हैं
    ये बेवकूफ हैं, और बस OWASP के coreruleset नाम के पढ़ने में मुश्किल कचरे के ढेर का इस्तेमाल करते हैं
  • इन्हें cybersecurity प्रभारी को hire करना चाहिए। लगता नहीं कि कोई है

• इस मामले को web security में protection और usability के बीच दिलचस्प तनाव दिखाने वाला कहना मानना मुश्किल है। यह बस एक bug है, और वह भी बेवकूफी भरा bug। यह सिर्फ दिखाता है कि जिन्हें बेहतर पता होना चाहिए, उन्हें पता नहीं है
  security और usability के बीच तनाव सचमुच मौजूद है, लेकिन यह वह मामला नहीं है। आमतौर पर यह ऐसा trade-off होता है जहाँ अच्छी security लागू करने से user को असुविधा होती है। जैसे 2-factor authentication, 3 बार fail होने पर lockout, या DoS रोकने के लिए rate limiting—security बढ़ाने पर user experience खराब होता है, और user experience बढ़ाने पर security घटती है
  यह दोनों में से कोई नहीं है। यह खराब security भी है और खराब user experience भी। समझ नहीं आता इसमें तनाव कहाँ है

  • आम तौर पर सभी endpoints पर एक साथ WAF लागू कर देना और फिर ऐसी समस्या आने पर चुनकर हटाना, एक उपयोगी security practice लगती है। खासकर जब आप plugins लगे Wordpress जैसे third-party software host कर रहे हों, तब हर public endpoint का एक-एक करके मूल्यांकन करना कहीं ज़्यादा मुश्किल होता है
  • इससे PHP 3 के दिन याद आ गए। लगता है PHP SQL injection को एक साथ रोकने के लिए URL requests की सामग्री को “sanitize” करता था, या शायद shared hosting में अक्सर चालू रहने वाली कोई setting थी
    बेशक, PHP sites लिखने वालों ने जल्दी ही यह समझ लिया, तरह-तरह के bypass तरीके इस्तेमाल हुए, और कुल मिलाकर संभवतः यह “sanitization” न होने की तुलना में और भी बुरा साबित हुआ

• पहले एक बार यह झेल चुका हूँ, इसलिए “network error” शब्द देखते ही कारण तुरंत समझ आ गया
  जब मैं competitive programming team को पढ़ाता था, तो आधी class को solution submit करने पर blank page मिल रहा था। एक घंटे की debugging के बाद इसे कुछ C++ types और keywords तक सीमित किया, जो code में आने पर 403 देते थे, और उन सबका JavaScript में भी मतलब था
  बैंक में काम करते समय भी एक API था जिसमें Python files submit करनी होती थीं, लेकिन ज्यादातर Python files पर 403 आता था और छोटी files पास हो जाती थीं। कई घंटे debug करने के बाद इसे एक ऐसे keyword तक सीमित किया जो code में कभी-कभी आता था
  कुछ महीनों बाद नए cloud environment में भी यही हुआ और फिर कई घंटे बर्बाद हुए। दूसरी बार के बाद एक सहकर्मी ने deployment script में यह जोड़ दिया कि 403 मिलने पर "HAHAHA YOU'VE BEEN WAFFED" प्रिंट हो, और यह error उम्मीद से कहीं ज़्यादा बार दिखा, इसलिए आज तक उसका आभारी हूँ

  • याद है कि वह Cloudflare था, या कोई दूसरा WAF?

• हमारे application में भी ऐसा ही कुछ हुआ। अंदर की red team ऐसा data पोस्ट कर रही थी जिसमें XSS और दूसरी injection attacks की कोशिशें थीं
  हमला खुद सफल नहीं हुआ, लेकिन सिर्फ उन entries के मौजूद होने की वजह से company firewall ने ऐसे network requests रोक दिए जिनमें वह payload शामिल था, और internal admin page load ही नहीं हुआ। आखिरकार असफल XSS हमला एक प्रभावी DoS attack बन गया

• पुरानी चीज़ फिर से नई बन गई है। पहले इसे Scunthorpe problem कहा जाता था
  https://en.m.wikipedia.org/wiki/Scunthorpe_problem

  • पुराने Eve Online forums में cockpit शब्द हमेशा c***pit में बदल जाता था, यह याद है। काफी मज़ेदार था
  • हाल में अमेरिकी सरकारी websites से “diversity”, “equity”, “inclusion” जैसे शब्द हटाए जाने की बात भी याद आती है
    अगर आप biology, finance, या geology के बारे में लिख रहे हों तो? बस आपकी किस्मत खराब है
    समझदार और नेकनीयत लोग भी लिखें, तब भी बेवकूफ filtering काफी बुरी हो सकती है
  • अब समय आ गया है कि इस Substack मामले को Wikipedia लेख में जोड़ दिया जाए

• कल रात OpenRouter में भी इसी तरह की समस्या मिली। OpenRouter एक शानदार “switchboard” सेवा है जो एक ही endpoint से कई LLMs इस्तेमाल करने देती है, और कल रात मैंने देखना शुरू किया कि raw HTML को अलग-अलग तरीकों से process करने में कौन सा model अच्छा है
  लेकिन OpenRouter API को Cloudflare से protect किया गया है, इसलिए अगर POST request body में कुछ खास raw HTML और JavaScript snippets हों, तो हर request नहीं लेकिन बहुत-सी requests block हो जाती हैं। वही prompt अगर सीधे OpenAI या Anthropic को भेजें तो कोई समस्या नहीं होती
  मुफ्त models के लिए abuse prevention कड़ा रखना समझ में आता है, लेकिन यह paid commercial models पर बिल होने वाली requests में हो रहा था, इसलिए और खटकता है

  • क्या आपने इसकी report की?

• मैंने पहले यह समस्या झेली है और यह बेहद frustrating थी। "Network error" की वजह से मैं कई महीनों से लिखे जा रहे लेख को update नहीं कर पाया, क्योंकि edits से लेख लंबा होता जा रहा था, इसलिए कारण समझ नहीं पाया
  support team से संपर्क करना भी AI chatbot की वजह से मुश्किल था, और जब किसी इंसान तक पहुँचा भी, तो उनका “technical support” इसे उचित समय में देखने का इच्छुक नहीं लगा
  आखिरकार Twitter पर किसी ने इस संभावना का सुझाव दिया कि कोई magic string उस बेवकूफ security logic को trigger कर रही है, तभी समस्या पकड़ में आई और मैं आखिरकार लेख को edit कर सका