2012-07-14 5 views
5

पर जावास्क्रिप्ट निष्पादन को अक्षम करें क्या किसी विशिष्ट पृष्ठ के लिए जावास्क्रिप्ट को अक्षम करने के लिए कोई HTTP-header है? मेरी वेबसाइट उपयोगकर्ता द्वारा जेनरेट की गई HTML-सामग्री प्रदान करती है (यही कारण है कि मैं केवल htmlenitities का उपयोग नहीं कर सकता) और मैं स्क्रिप्टिंग (जावास्क्रिप्ट इंजेक्शन) को रोकना चाहता हूं।विशिष्ट पृष्ठों (जावास्क्रिप्ट/PHP)

मैं पहले से ही मुख्य डोमेन पर प्रमाणीकरण के लिए सेट किया जा रहा है, जबकि उपयोगकर्ता सामग्री केवल उप डोमेन पर प्रदर्शित होती है जहां कुकी को पढ़ा नहीं जा सकता है। समस्या यह है कि जावास्क्रिप्ट को निष्पादित करने के लिए अभी भी कई संभावनाएं हैं - उदाहरण के लिए onclick जैसे ईवेंट विशेषताओं का उपयोग करना और इंटरनेट एक्सप्लोरर के पास जावास्क्रिप्ट निष्पादन (expression) की अनुमति देने के लिए सीएसएस में भी एक संपत्ति है, जिसे मैंने पहले कभी नहीं सुना था। मैंने एक और दिलचस्प विचार पढ़ा है, कोड को अवरुद्ध करने के लिए अपवाद फेंकने के बारे में था। एक और विचार सभी अनुमत टैग वाले एक सूची को परिभाषित करेगा और इसके अतिरिक्त प्रत्येक अनुमत विशेषता नाम के साथ एक सरणी होगी लेकिन यह बहुत कठिन काम है और मुझे लगता है कि यह सभी संभावित इंजेक्शन को कवर नहीं करेगा।

मुझे लगता है कि मैं इस समस्या वाले एकमात्र व्यक्ति नहीं हूं, तो क्या किसी को सभी संभावित हानिकारक कोड को कवर करने की संभावना है?

X-Scripting: disabled के समान एक साधारण काल्पनिक शीर्षलेख जीवन को इतना आसान बना देगा!

+0

क्या आपने कभी 'स्क्रिप्ट' टैग को अवरुद्ध करने और उपयोगकर्ता इनपुट में कुछ विशेषताओं को अवरुद्ध करने का विचार किया है? –

+0

यही मेरा मतलब है: "एक और विचार सभी अनुमत टैग वाले एक सूची को परिभाषित करेगा और इसके अलावा प्रत्येक अनुमत विशेषता नाम के साथ एक सरणी होगी लेकिन यह बहुत कठिन काम है और मुझे लगता है कि यह सभी संभावित इंजेक्शन को कवर नहीं करेगा।" (इसलिए मैं उदाहरण के लिए "div" या "span" जैसे हानिरहित टैगों को अनुमति देता हूं और "ऑनक्लिक", "ऑनमूसओवर" जैसे गुण अक्षम करता हूं, लेकिन ब्राउज़र में अलग-अलग, ब्राउज़र-विशिष्ट विशेषताओं और गुणों के बाद से यह सभी इंजेक्शन को कवर नहीं करेगा) –

उत्तर

2

हां, Content Security Policy नामक एक प्रयोगात्मक HTTP शीर्षलेख है जो आपको जावास्क्रिप्ट से कहां से नियंत्रित करने की अनुमति देता है, जिससे एक्सएसएस असंभव हो सकता है। हालांकि वर्तमान में यह केवल क्रोम और फ़ायरफ़ॉक्स द्वारा समर्थित है।

एचटीपीओनली-कुकीज़ को सक्षम करना एक अच्छा विचार है, हालांकि यह शून्य हमलों को रोक देगा। आप अभी भी reading CSRF tokens, and carrying out requests with an XHR द्वारा एक्सएसएस का फायदा उठा सकते हैं।

एक्सएसएस प्राप्त करने के कई तरीके हैं, और ShieldSeal जैसे भेद्यता स्कैनर उन सभी को (लगभग) पाएंगे। Skipfish एक खुला स्रोत भेद्यता स्कैनर है जो बहुत ही प्राचीन है, लेकिन यह मुफ़्त है। इस प्रकार अधिकांश वेब अनुप्रयोग व्यापक प्रसार भेद्यता से निपटते हैं। (मैं शेल्डसेल के लिए काम करता हूं और मैं अपनी भेद्यता स्कैनर बनाने में मदद करता हूं और मुझे अपना काम पसंद है।)

जब कोई समस्या मिलती है तो आपको इनपुट को स्वच्छ करने के लिए htmlspecialchars($var) या htmlspecialchars($var,ENT_QUOTES) का उपयोग करना चाहिए। ENT_QUOTES किसी हमलावर को ऑनक्लिक या अन्य जावास्क्रिप्ट ईवेंट शुरू करने से रोक सकता है।

+0

केवल समस्या यह है कि उपयोगकर्ताओं को अपनी HTML-सामग्री उत्पन्न करने में जितना संभव हो सके मुफ़्त होना चाहिए, लेकिन गतिशील क्लाइंट-साइड कोड निष्पादित किए बिना। एसक्यूएल-इंजेक्शन या PHP-इंजेक्शन कोई समस्या नहीं है क्योंकि कोड डेटाबेस में संग्रहीत है, न कि .php-files में। और SQL-स्टेटमेंट में किसी भी उपयोग से पहले सभी पैरामीटर साफ़ किए जाते हैं। उदाहरण के लिए 'img'-टैग' के लिए 'src' जैसे आवश्यक गुण हैं, मैं 'ENT_QUOTES' का उपयोग सरल नहीं कर सकता और सभी इनपुट को स्वच्छ कर सकता हूं। लेकिन मैं कम से कम फ़ायरफ़ॉक्स/क्रोम-उपयोगकर्ताओं के लिए अपनी साइट को सुरक्षित करने के लिए, सामग्री सुरक्षा नीति के बारे में और अधिक पढ़ूंगा। –

+0

@ बिर्क ओह, मैंने इसे गलत तरीके से पढ़ा है, तो आप HTMLPurifier का उपयोग करना चाहते हैं। इसके अलावा आपको आमतौर पर उपयोग के समय sanitize करना चाहिए, इसलिए xss के लिए आउटपुट पर sanitize।हालांकि, HTMLPurifier कई संसाधनों का उपयोग करता है, इसलिए आपको शायद डेटाबेस में डालने से पहले इसका उपयोग करना चाहिए। – Mikey

+0

@ बिर्क, आप एचटीएमएल/सीएसएस के सुरक्षित एम्बेडिंग के लिए Google काजा प्रोजेक्ट भी देखना चाहेंगे। https://developers.google.com/caja/ – JackWink