Firefox 148 में setHTML के आने से XSS सुरक्षा और मजबूत

• वेब की प्रमुख कमजोरी XSS हमलों को रोकने के लिए Firefox ने पहली बार मानकीकृत Sanitizer API को सपोर्ट किया है
• मौजूदा innerHTML की जगह setHTML() मेथड का उपयोग करने पर, अविश्वसनीय HTML को DOM में डालने से पहले अपने-आप sanitize किया जाता है और malicious script हट जाते हैं
• अगर डिफ़ॉल्ट सेटिंग बहुत सख्त या बहुत ढीली लगे, तो डेवलपर custom settings के जरिए अनुमति देने वाले elements और attributes को नियंत्रित कर सकते हैं
• Firefox की यह सुविधा Trusted Types के साथ मिलकर पूरे वेब की सुरक्षा को बेहतर बनाती है और डेवलपर को अलग security team के बिना भी XSS रोकने में मदद करती है

---

XSS कमजोरी और Firefox की प्रतिक्रिया

• Cross-site scripting (XSS) तब होता है जब attacker, user input वाले content के जरिए मनमाना HTML या JavaScript inject कर देता है
  • attacker इसका उपयोग user interaction की निगरानी करने या data चुराने के लिए कर सकता है
  • XSS को लगभग 10 वर्षों से शीर्ष 3 वेब कमजोरियों (CWE-79) में गिना जाता रहा है
• Firefox 2009 से Content-Security-Policy (CSP) मानक को आगे बढ़ाते हुए XSS बचाव को मजबूत करता रहा है
  • CSP उन resources को सीमित करता है जिन्हें वेबसाइट load और execute कर सकती है
  • लेकिन इसमें मौजूदा साइट संरचना में बदलाव और लगातार security review की ज़रूरत होती है, इसलिए व्यापक अपनाने में सीमाएँ रही हैं

Sanitizer API और setHTML() की भूमिका

• Sanitizer API malicious HTML को harmless रूप में बदलने का मानकीकृत तरीका देता है
  • उदाहरण कोड में <img src="x" onclick="alert('XSS')"> element हटा दिया जाता है और केवल <h1>Hello my name is</h1> बचता है
• setHTML() मेथड HTML insert करते समय अपने-आप sanitize प्रक्रिया चलाता है, जिससे डिफ़ॉल्ट रूप से सुरक्षित व्यवहार सुनिश्चित होता है
  • मौजूदा innerHTML assignment को सिर्फ setHTML() से बदल देने भर से मजबूत XSS सुरक्षा मिल सकती है
• अगर डिफ़ॉल्ट सेटिंग बहुत सख्त या बहुत ढीली हो, तो डेवलपर custom settings के जरिए अनुमति वाले HTML elements और attributes को परिभाषित कर सकते हैं
  • प्रयोग के लिए Sanitizer API playground टूल का उपयोग किया जा सकता है

Trusted Types के साथ संयोजन

• Trusted Types API HTML parsing और insertion को केंद्रीकृत तरीके से नियंत्रित करके अतिरिक्त security layer देता है
  • setHTML() का उपयोग करते समय Trusted Types policy आसानी से लागू की जा सकती है
  • सख्त policy केवल setHTML() को अनुमति देकर अन्य जोखिमभरे insertion तरीकों को रोक सकती है, जिससे भविष्य में XSS regression रोकने में मदद मिलती है

Firefox 148 के सुरक्षा सुधार का प्रभाव

• Firefox 148 Sanitizer API और Trusted Types दोनों को सपोर्ट करता है, जिससे डिफ़ॉल्ट सुरक्षा स्तर में बड़ा सुधार होता है
• डेवलपर जटिल security policy या अलग security team के बिना भी सिर्फ सरल code changes से XSS रोक सकते हैं
• इस मानक के आने से सभी browsers में सुरक्षित वेब वातावरण के प्रसार की उम्मीद है

सारांश

• Firefox 148, setHTML() मेथड और Sanitizer API के जरिए वेब डेवलपर को आसानी से XSS हमले रोकने में सक्षम बनाता है
• यह सुविधा CSP की सीमाओं को पूरा करती है और डिफ़ॉल्ट रूप से सुरक्षित HTML insertion को वेब मानक के रूप में स्थापित करने का अवसर देती है
• Trusted Types के साथ मिलकर यह लंबे समय तक security बनाए रखने और XSS regression रोकने में मदद करती है
• नतीजतन, Firefox security को default मानने वाले वेब वातावरण की ओर बदलाव का नेतृत्व कर रहा है

[huiya]

ओह, निश्चित रूप से ऐसी चीज़ की ज़रूरत तो है। अगर यह सभी browsers में support हो जाए तो बहुत बढ़िया होगा

[GN⁺]

Hacker News की राय

• इस तरह की सुविधाएँ हमेशा थोड़ी चिंताजनक लगती हैं
  क्योंकि ऐसे methods का मिश्रण होता है जो user input को मनमाने रूप से देने पर भी सुरक्षित तरीके से handle करते हैं, और ऐसे भी जो नहीं करते; लेकिन सिर्फ नाम देखकर उनमें फर्क समझना मुश्किल होता है
  आदर्श रूप से, शुरू से ही खतरनाक functions का नाम ऐसा होना चाहिए जिससे जोखिम साफ़ दिखाई दे
  और HTML को “sanitize” करने का विचार भी अपने-आप में अस्पष्ट है, इसलिए यह तय करना कठिन है कि यह वास्तव में सुरक्षित है या नहीं

  • यह सही है कि “सुरक्षित” की परिभाषा अस्पष्ट हो सकती है, लेकिन यहाँ लक्ष्य XSS-safe होना है
    script चला सकने वाले elements या attributes को हटा दिया जाता है, और यह logic browser engine के अंदर काम करता है, इसलिए string-based sanitizer की तुलना में इसे ज़्यादा सटीक तरीके से handle किया जाता है
    अधिक जानकारी के लिए MDN setHTML दस्तावेज़ देखें
  • दरअसल, पहले से ही एक स्पष्ट अंतर मौजूद है
    elementNode.textContent अविश्वसनीय input के लिए भी सुरक्षित है, जबकि elementNode.innerHTML नहीं है
    पहला सभी characters को escape करता है, जबकि दूसरा कुछ भी escape नहीं करता
    कुछ लोगों का मानना है कि “HTML sanitization” मूल रूप से ऐसा problem है जिसे पूरी तरह हल नहीं किया जा सकता
    संबंधित चर्चा के लिए यह टिप्पणी देखें
    ऐसा API proposal stage से आगे बढ़ना ही नहीं चाहिए था
  • innerHTML और setHTML को मिलाकर इस्तेमाल करने के बजाय, innerHTML को पूरी तरह हटाकर पुराने behavior की ज़रूरत होने पर setHTMLUnsafe इस्तेमाल करने जैसा design होना चाहिए
  • अच्छा होता अगर web developers किसी global setting के ज़रिए innerHTML जैसे पुराने API को disable कर पाते
    हालाँकि ऐसा करने पर पुराने browsers में site चलना बंद भी कर सकती है
  • अगर page को Content-Security-Policy: require-trusted-types-for 'script' header के साथ serve किया जाए, तो sanitizer के बिना वाले methods में सामान्य strings पास करने से रोका जा सकता है

• अगर example की तरह user name में <h1> या <br> जैसे tags डाले जा सकते हैं, तो भले ही script execution रुक जाए, फिर भी मनमाना markup injection संभव रहता है
  <style> tag से CSS भी बदली जा सकती है, इसलिए उदाहरण के लिए PayPal profile page का design बदला जा सकता है
  तब सवाल उठता है कि ऐसा कौन चाहेगा

  • फिर भी, forum जैसी जगहों पर जहाँ users को Markdown इस्तेमाल करने देना हो, यह उपयोगी हो सकता है
    Markdown से बने HTML पर sanitizer की एक और layer लगाकर सिर्फ कुछ tags allow किए जा सकते हैं
  • ऐसे मामले में innerHTML नहीं बल्कि innerText या textContent इस्तेमाल होना चाहिए था
    setHTML का उद्देश्य innerHTML का replacement होना है
  • अगर setHTML() की default setting बहुत सख्त या बहुत ढीली हो, तो developer एक custom setting दे सकता है जिसमें allowed HTML elements और attributes खुद define किए जाएँ
  • सिर्फ CSS से भी security risk पैदा हो सकता है, इसलिए अब भी सावधानी ज़रूरी है
    संबंधित चर्चा के लिए यह thread देखें
  • उदाहरण के लिए

    .setHTML("<h1>Hello</h1>", new Sanitizer({}))
    

    ऐसा करने पर सभी elements हटा दिए जाएँगे
    आखिरकार backend में भी user name को standard तरीके से sanitize करना होगा, और output के समय HTML escape लागू करना होगा
    RFC 2119 के अनुसार यह “SHOULD” स्तर की requirement है

• यह feature आया, यह अच्छी बात है, लेकिन browser support पर्याप्त रूप से फैलने में समय लगेगा
  support status Can I use पर देखा जा सकता है

  • दूसरे browser APIs की तरह इसमें कुछ साल लग सकते हैं, और अगर केवल latest versions को target किया जाए तो कुछ महीनों में भी संभव हो सकता है
    तब तक polyfill इस्तेमाल किया जा सकता है

• शीर्षक थोड़ा सनसनीखेज़ था
  दरअसल innerHTML में देने से पहले input जाँचने वाला function बनाकर भी sanitization लागू किया जा सकता है
  लेकिन ऐसे प्रयास आख़िरकार फिर से पहिया बनाने जैसे लगते हैं
  और पुराने Firefox में hacks.mozilla.org खुलता ही नहीं, जबकि Pale Moon या SeaMonkey में MDN टूटा हुआ दिखता है
  मानो कोई “browser cartel” web को बर्बाद करना चाहता हो

  • “इसे input validation function से हल किया जा सकता है” कहना वैसा ही है जैसे “C language भी memory-safe है, बस उसमें bugs न हों”
    इसमें parser differential की समस्या को भी नज़रअंदाज़ किया गया है

• Sanitizer API का गलत इस्तेमाल इसे footgun बना सकता है
  खास तौर पर “remove” mode का उपयोग करते समय सावधानी चाहिए
  मुझे तो लगता है कि सिर्फ setText इस्तेमाल करना और user को HTML जोड़ने की अनुमति ही न देना बेहतर है

  • allowlist-आधारित Sanitizer इस्तेमाल करने पर जोखिम कम होता है, लेकिन setHTML इस्तेमाल करने पर भी XSS नहीं होगा
  • लेकिन जब page author को बड़े HTML fragments जोड़ने हों, तब क्या किया जाए
    innerHTML के आम उपयोग को देखते हुए, इसे पूरी तरह बाहर करना आसान नहीं है
  • उल्टा, ऐसा API लोगों में यह भ्रम भी पैदा कर सकता है कि यह “100% सुरक्षित” है, और यही इसे और खतरनाक बना सकता है

• यह प्रभावशाली है कि network access के हर पहलू को ठीक से नियंत्रित किया गया है, और अब security chain code पर trust से host configuration पर trust की ओर खिसक गई है
  defaults भी सुरक्षित रखे गए हैं

• मैं वास्तव में जिस चीज़ की चाहत रखता हूँ, वह है खतरनाक code को सुरक्षित तरीके से चलाने वाला <sandbox> element
  मतलब खतरनाक code को बदलना नहीं, बल्कि उसे isolated environment में चलाने देना
  iframe की सीमा यह है कि वह DOM के साथ स्वाभाविक रूप से flow नहीं कर पाता, और AI व dynamic content के बढ़ते दौर में composable encapsulation की ज़रूरत है

• setHTMLUnsafe नाम मुझे सच में बहुत पसंद आया
  security features तब विफल हो जाते हैं जब उन्हें developer के opt-in पर छोड़ दिया जाए
  इसके बजाय “खतरनाक रास्ता सचमुच खतरनाक महसूस हो” ऐसा बनाना ज़्यादा प्रभावी है

• set_html() नाम inner_html की तुलना में कहीं ज़्यादा सहज लगता है
  JavaScript के APIs सचमुच बहुत बेतरतीब हैं और कभी न कभी इन्हें व्यवस्थित किया जाना चाहिए
  यह चर्चा भले security-केंद्रित हो, लेकिन नया API जारी करते समय design भी साफ़-सुथरा होना चाहिए

  • सख्ती से देखें तो यह DOM API है
    DOM API को लेकर पहले भी, और आज भी, ऐसा महसूस होता है मानो इसे उन लोगों ने बनाया हो जिन्होंने कभी API design किया ही न हो

• 90 के दशक के developers:

  SQL("select * from user where name = " + name);
  

  2020 के दशक के developers:

  div.innerHTML = "Hello " + user.name;
  

  • 2030 के दशक के developers:

    "Summarize this email: " + email.contents
    

    prompt injection बस नई technology पर वही पुरानी समस्या है
    हमने 90 के दशक से कुछ भी नहीं सीखा