Kodokon kodokon.com

HTML-पक्ष सुरक्षा: XSS, sandbox, noopener और CSP

मार्कअप के लिए विशिष्ट XSS वैक्टर की पहचान करें और HTML की नेटिव सुरक्षा को तैनात करें: sandbox, noopener और Content Security Policy।

11 मिनट · 3 प्रश्न

इस पाठ को Kodokon में खोलें

एस्केपिंग संदर्भ ही पूरा अंतर पैदा करता है: एक मान जो टेक्स्ट नोड में हानिरहित होता है, एट्रिब्यूट में निष्पादन योग्य बन जाता है। बिना उद्धरण वाला एट्रिब्यूट सबसे बुरी स्थिति है: इंजेक्ट किए गए डेटा में एक अकेली जगह एक नया एट्रिब्यूट बनाने के लिए पर्याप्त है, उदाहरण के लिए एक onmouseover हैंडलर। ठीक से उद्धृत होने पर भी, एक मान संवेदनशील sinks में खतरनाक बना रहता है: href और src javascript: स्कीम स्वीकार करते हैं, formaction किसी फ़ॉर्म के सबमिशन को हाईजैक कर लेता है, और srcdoc डिकोड होने पर अपनी एंटिटीज़ को HTML के रूप में व्याख्यायित करता है।

HTML
<!-- userName = x onmouseover=alert(1) -->
<img src="avatar.png" alt=x onmouseover=alert(1)>
<!-- The unquoted attribute lets a handler in -->
बिना उद्धरण वाले एट्रिब्यूट में बिना एस्केप किया गया डेटा कोड बन जाता है।

किसी iframe का sandbox एट्रिब्यूट सभी विशेषाधिकार छीन लेता है, और फिर आप उन्हें एक-एक करके वापस देते हैं: allow-scripts, allow-forms, allow-popups... allow-same-origin के बिना, एम्बेडेड दस्तावेज़ को एक opaque origin मिलता है: कोई कुकी नहीं, कोई स्टोरेज नहीं, पैरेंट DOM तक कोई पहुँच नहीं - भले ही इसे आपके अपने डोमेन से परोसा जाए।

HTML
<iframe
  src="https://widget.example.com"
  sandbox="allow-scripts allow-forms"
  referrerpolicy="no-referrer">
</iframe>
एक तृतीय-पक्ष विजेट जो स्क्रिप्ट चला सकता है, फिर भी एक opaque origin तक सीमित है।

एक target=_blank लिंक ऐतिहासिक रूप से खोले गए पेज को आपके टैब का window.opener संदर्भ देता था: यह आपके पेज को किसी फ़िशिंग क्लोन पर पुनर्निर्देशित कर सकता था, इस आक्रमण को tabnabbing के नाम से जाना जाता है। आधुनिक ब्राउज़र अब target=_blank पर noopener को अंतर्निहित रूप से लागू करते हैं, लेकिन JavaScript में window.open के लिए और इरादे को प्रलेखित करने के लिए इसे स्पष्ट रूप से लिखना आवश्यक बना रहता है; Referer हेडर को भी दबाने के लिए noreferrer जोड़ें।

HTML
<a href="https://external.example"
   target="_blank"
   rel="noopener noreferrer">
  View the external resource
</a>
खोले गए पेज को window.opener === null प्राप्त होता है।

एक Content Security Policy निष्पादन योग्य कोड के स्रोतों को प्रतिबंधित करती है और अधिकांश XSS को निष्क्रिय कर देती है, तब भी जब इंजेक्शन सफल हो गया हो। एक <meta http-equiv> टैग के माध्यम से घोषित, फिर भी इसके अंधे बिंदु हैं: frame-ancestors, report-uri और sandbox निर्देश वहाँ अनदेखे कर दिए जाते हैं और उन्हें HTTP हेडर की आवश्यकता होती है। डोमेन अनुमति-सूचियों के बजाय हर प्रतिक्रिया पर पुनर्जनित किए गए nonces को प्राथमिकता दें, जिन्हें strict-dynamic निर्देश वैसे भी अप्रचलित बना देता है।

HTML
<meta http-equiv="Content-Security-Policy"
      content="default-src 'self';
               script-src 'self' 'nonce-r4nd0m'">
केवल सर्वर के nonce को धारण करने वाली स्क्रिप्ट ही चलती हैं।

ज्ञान जांच

सुनिश्चित करें कि आपको इस पाठ के मुख्य बिंदु याद हैं।

  1. किसी same-origin iframe पर allow-scripts और allow-same-origin को मिलाने से sandbox रद्द क्यों हो जाता है?
    • एम्बेडेड दस्तावेज़, जो स्क्रिप्ट योग्य है और आइसोलेटेड नहीं है, पैरेंट DOM तक पहुँच सकता है और खुद ही sandbox एट्रिब्यूट हटा सकता है
    • दोनों टोकन असंगत हैं और ब्राउज़र पूरे एट्रिब्यूट को अनदेखा कर देता है
    • allow-same-origin अपने आप बाकी सभी टोकन को अक्षम कर देता है
  2. rel=noopener किस आक्रमण से बचाता है?
    • खोले गए पेज द्वारा सत्र कुकीज़ की चोरी
    • खोले गए पेज में स्क्रिप्ट इंजेक्शन
    • Tabnabbing: खोला गया पेज आपके टैब को फ़िशिंग साइट पर पुनर्निर्देशित करने के लिए window.opener का उपयोग करता है
  3. जब CSP <meta http-equiv> के माध्यम से घोषित की जाती है तो कौन सा निर्देश अनदेखा किया जाता है?
    • script-src
    • frame-ancestors
    • default-src
    • img-src