"क्रॉस-साइट स्क्रिप्ट अटैक" से कैसे बचें

Question

आप क्रॉस-साइट स्क्रिप्ट हमलों से कैसे बचते हैं?

Cross-site script attacks (या क्रॉस-साइट स्क्रिप्टिंग) है अगर आप उदाहरण के लिए अपने मुखपृष्ठ पर एक अतिथि पुस्तिका और एक ग्राहक पदों कुछ जावास्क्रिप्ट कोड जो fx अन्य वेबसाइट पर आप पुनर्निर्देश या एक के लिए एक ईमेल में अपनी कुकी भेजता है दुर्भावनापूर्ण उपयोगकर्ता या यह कई अन्य सामान हो सकता है जो आपके लिए और आपके पृष्ठ पर आने वाले लोगों के लिए वास्तविक हानिकारक साबित हो सकते हैं।

मुझे यकीन है कि यह एफएक्स किया जा सकता है। में फॉर्म मान्य करने पर मुझे एफएक्स के लिए पर्याप्त अनुभव नहीं हुआ है। जावास्क्रिप्ट या अन्य चीजों को प्रतिबंधित करें जो आपको नुकसान पहुंचा सकते हैं।

मुझे आशा है कि आप मेरे प्रश्न को समझें और आप मेरी मदद कर सकें।

Answer 1

मुझे यकीन है कि यह fx किया जा सकता है कर रहा हूँ:

स्वयं को सुरक्षित रखने पर पूरी तरह से संसाधन के लिए यह लिंक देखें। फॉर्म

वास्तव में नहीं। एक्सएसएस मुद्दों को संबोधित करने के लिए इनपुट चरण पूरी तरह गलत जगह है।

यदि उपयोगकर्ता टाइप करते हैं, तो <script>alert(document.cookie)</script> एक इनपुट में कहें, इसमें स्वयं के साथ कुछ भी गलत नहीं है। मैंने अभी इस संदेश में किया है, और यदि स्टैक ओवरफ्लो ने इसे अनुमति नहीं दी है तो हमें साइट पर जावास्क्रिप्ट के बारे में बात करने में बड़ी कठिनाई होगी! ज्यादातर मामलों में आप किसी इनपुट (*) को अनुमति देना चाहते हैं, ताकि उपयोगकर्ता < वर्ण का उपयोग शाब्दिक रूप से कम से कम संकेत के लिए कर सकें।

बात यह है कि, जब आप किसी HTML पृष्ठ में कुछ टेक्स्ट लिखते हैं, तो आपको उस संदर्भ के लिए इसे सही ढंग से बचाना होगा। पीएचपी के लिए, कि उत्पादन चरण पर htmlspecialchars() का उपयोग कर का अर्थ है:

<p> Hello, <?php echo htmlspecialchars($name); ?>! </p> 

[पीएचपी संकेत: क्या, अपने आप को छोटे नाम के साथ एक समारोह echo htmlspecialchars करने के लिए परिभाषित कर सकते हैं के बाद से यह काफी हर करने के लिए टाइपिंग का एक बहुत है समय आप कुछ एचटीएमएल में एक चर डालना चाहते हैं।]

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

उदाहरण के लिए यदि आप एक जावास्क्रिप्ट स्ट्रिंग शाब्दिक में पाठ डालें, आप उद्धरण कैरेक्टर, बैकस्लैश और नई-पंक्तियों से बचने के लिए होगा। यदि आप किसी URL में क्वेरी घटक में टेक्स्ट डालते हैं, तो आपको अधिकांश गैर-अल्फान्यूमेरिक्स को %xx अनुक्रमों में परिवर्तित करने की आवश्यकता होगी। प्रत्येक संदर्भ के अपने नियम हैं; आपको यह जानना होगा कि आपकी चुनी भाषा/ढांचे में प्रत्येक संदर्भ के लिए सही कार्य कौन सा है। आप इन चरणों को इनपुट चरण में फॉर्म सबमिशन को मैंगलिंग करके हल नहीं कर सकते हैं-हालांकि कई भद्दा PHP प्रोग्रामर आज़माते हैं, यही कारण है कि इतने सारे ऐप्स कोने के मामलों में आपके इनपुट को गड़बड़ कर देते हैं और अभी भी सुरक्षित नहीं हैं।

(*: ठीक है, लगभग कोई भी। सबमिट किए गए पाठ से ASCII नियंत्रण वर्णों को फ़िल्टर करने के लिए एक उचित तर्क है। यह बहुत ही असंभव है कि उन्हें कोई अच्छा करने की इजाजत है। बेशक आपके पास एप्लिकेशन-विशिष्ट सत्यापन होंगे क्या आप वाकई एक ई-मेल क्षेत्र एक ई-मेल पते की तरह या कि संख्या वास्तव में संख्यात्मक हैं लग रहा है बनाने की तरह है, क्या करना चाहता हूँ। लेकिन यह कुछ सभी इनपुट को कंबल से लागू आप मुसीबत से बाहर निकलना हो सकता है कि नहीं है।)

Answer 2

क्रॉस-साइट स्क्रिप्टिंग हमले (एक्सएसएस) तब होता है जब कोई सर्वर क्लाइंट से इनपुट स्वीकार करता है और फिर अंधेरे से पृष्ठ पर इनपुट लिखता है। इन हमलों से अधिकांश सुरक्षा में आउटपुट से बचने में शामिल है, इसलिए जावास्क्रिप्ट सादे HTML में बदल जाता है।

ध्यान में रखना एक बात यह है कि यह न केवल उस ग्राहक से आने वाला डेटा है जिसमें हमला हो सकता है। संग्रहीत XSS हमले में दुर्भावनापूर्ण जावास्क्रिप्ट को डेटाबेस में लिखना शामिल है, जिनकी सामग्री वेब एप्लिकेशन द्वारा पूछे जाने वाले हैं। यदि डेटाबेस क्लाइंट से अलग से लिखा जा सकता है, तो एप्लिकेशन यह सुनिश्चित करने में सक्षम नहीं हो सकता है कि डेटा ठीक से बच गया था। इस कारण से, वेब एप्लिकेशन को क्लाइंट को लिखने वाले सभी डेटा का इलाज करना चाहिए जैसे कि इसमें कोई हमला हो। http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet