क्या कोडइग्निटर में "बार-बार" xss-clean डेटा ठीक है?

Question

Codeigniter में XSS साफ आंकड़ों के अनुसरण कर रहे हैं तरीके:

• TRUE
• उपयोग xss_clean()
• एक सत्यापन नियम
• में TRUE से पीछे नहीं पैरामीटर सेट के रूप में उपयोग करने के लिए xss_clean config में global_xss_filtering सेट $this->input->post('something', TRUE)

क्या डेटा के एक टुकड़े पर उनमें से एक या अधिक का उपयोग करना ठीक है?

उदाहरण के लिए, यह अगर मैं अभी भी $this->input->post('something', TRUE) इस्तेमाल किया डेटा पहले से ही global_xss_filtering और xss_clean सत्यापन नियम से साफ कर दिया गया है, भले ही ठीक हो सकता है?

Answer 1

हां। मान लें, आपका इनपुट 'ए' है। फिर, मान लीजिए कि आपने XSS-सुरक्षित सामग्री प्राप्त करने के लिए एक xss_clean चलाएँ:

B = xss_clean(A) 

अब, मान लीजिए कि मैं इसे फिर से प्राप्त करने के लिए सी कार्य करें:

C = css_clean(B) 

अब, अगर B और C भिन्न होते हैं, तो इसका मतलब यह होना चाहिए कि B में कुछ xss-unsafe सामग्री थी। जिसका स्पष्ट अर्थ है कि xss_clean टूट गया है क्योंकि यह A को ठीक से साफ़ नहीं किया गया है। तो जब तक आप मान लें कि फ़ंक्शन xss- सुरक्षित सामग्री देता है, तो आप जाने के लिए अच्छे हैं।

एक तर्क जो बनाया जा सकता है वह यह है कि यदि फ़ंक्शन xss- सुरक्षित सामग्री को भी संशोधित करता है तो क्या होगा? खैर, वह चूस जाएगा और इसका मतलब यह होगा कि समारोह टूट गया है, लेकिन यह मामला नहीं है (मेरे अनुभव से बाहर कह रहा है, जैसा कि यह कभी ऐसा नहीं लगता है)।

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

इसके अलावा, अगर मैं जोड़ सकता हूं, तो कोडनिर्देशक xss स्वच्छ वास्तव में HTML को पार्स नहीं करता है और टैग और सामान को छोड़ देता है। यह बस < और > से < और > को परिवर्तित करता है। तो इस बात को ध्यान में रखते हुए, मुझे कुछ भी नहीं दिख रहा है जो गलत हो सकता है।

Answer 2

यह आपको चोट पहुंचाने वाला नहीं है, लेकिन यह निश्चित रूप से व्यर्थ है।

अंततः, आप एक ऐसे बिंदु तक पहुंच जाएंगे जहां वैश्विक एक्सएसएस फ़िल्टर बोझिल होने जा रहा है। चूंकि इसे व्यापक हैक्स के बिना प्रति नियंत्रक को अक्षम नहीं किया जा सकता है, और कच्चे $_REQUEST डेटा तक पहुंच असंभव हो जाएगी, आपको इसे वैश्विक रूप से अक्षम करने की आवश्यकता होगी। यह वह क्षण होगा जब आप विश्वसनीय डेटा के एक टुकड़े को संसाधित करना चाहते हैं, या डेटा जो HTML आउटपुट नहीं है और इसे बरकरार रखना चाहिए।

इसे एक फॉर्म सत्यापन नियम के रूप में उपयोग करना व्यर्थ और संभावित विनाशकारी भी है। कल्पना करें कि यह साइट कैसा होगा यदि हर बार आपने <script> टाइप किया था तो इसे [removed] के साथ बदल दिया गया था, भविष्य में इसे वापस करने का कोई तरीका नहीं था।एक और उदाहरण के लिए, यदि उपयोगकर्ता उपयोगकर्ता अपने पासवर्ड में कुछ "XSS" सामग्री को उपयोगकर्ता करता है? आपका आवेदन चुपचाप इनपुट को बदल देगा।

बस उस XSS फ़िल्टर का उपयोग करें जहां आपको इसकी आवश्यकता है: अपने HTML आउटपुट पर, जहां जावास्क्रिप्ट को निष्पादित किया जा सकता है।

Answer 3

xss_clean का उपयोग करना एक बार भी बुरा है, जहां तक ​​मेरा संबंध है। यह दिनचर्या भागों को हटाने या भागों को प्रतिस्थापित करके अपने डेटा को स्वच्छ करने का प्रयास करता है। यह हानिकारक है और कई बार चलाने पर एक ही सामग्री को वापस करने की गारंटी नहीं है। भविष्यवाणी करना भी मुश्किल है और हमेशा उचित कार्य नहीं करेगा। एक स्ट्रिंग को स्वच्छ करने की कोशिश करने के लिए जो चीजें होती हैं, उन्हें देखते हुए इनपुट पर इसका उपयोग करने के लिए भारी प्रदर्शन किया जाता है। यहां तक ​​कि t = t = जैसे इनपुट का सबसे छोटा सा हिस्सा xss_clean के लिए गतिविधि की झुकाव का कारण बनता है।

मैं यह कहना चाहूंगा कि आपको xss_clean का कभी भी उपयोग नहीं करना चाहिए, लेकिन वास्तव में मैं यह नहीं कह सकता। यह प्रणाली अनुभवहीन डेवलपर्स के लिए बनाई गई है जो उपयोगकर्ता सामग्री को सुरक्षित रूप से प्रबंधित करने के बारे में नहीं जानते हैं। मैं एक अनुभवी डेवलपर हूं इसलिए मैं कह सकता हूं कि जिस परियोजना पर मैं काम कर रहा हूं उसे कभी भी xss_clean का उपयोग करना चाहिए। तथ्य यह है कि, भ्रष्टाचार के मुद्दों को सरल उपयोग के साथ अनुभवहीन डेवलपर्स के लिए कम समस्याग्रस्त हो जाएगा और आखिरकार यह संभवतः अपने कोड को और अधिक सुरक्षित बनाएगा, भले ही उन्हें त्वरित गंदे और सस्ते हैक्स पर भरोसा करने के बजाय अपने कोड को और अधिक सुरक्षित बनाना चाहिए। दूसरी तरफ, xss_clean को आपके कोड को पूरी तरह से सुरक्षित बनाने की गारंटी नहीं है और अंततः सुरक्षा की झूठी भावना देकर चीजों को और खराब कर सकता है। आपको यह सुनिश्चित करने के लिए वास्तव में अध्ययन करने की अनुशंसा की जाती है कि आप यह सुनिश्चित कर लें कि आपका कोड वास्तव में सब कुछ करता है ताकि आप इसे वास्तव में सुरक्षित बना सकें। xss_clean कोड त्रुटियों के लिए क्षतिपूर्ति नहीं करता है, यह कोडर त्रुटियों के लिए क्षतिपूर्ति करता है।

आदर्श रूप से xss_clean केवल आउटपुट पर किया जाना चाहता है (और htmlentities, आदि के साथ प्रतिस्थापित होना चाहता है) लेकिन अधिकांश लोग इस से परेशान नहीं हैं क्योंकि उनके लिए फ़िल्टरिंग आउटपुट के बजाय सभी इनपुट फ़िल्टर करके डेटा शुद्धता का उल्लंघन करना आसान है (कुछ बार इनपुट हो सकता है लेकिन आउटपुट दस बार)। फिर, एक अनुशासित डेवलपर आउटपुट के उन दस मामलों में से एक के लिए xss_clean नहीं डाल सकता है।

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

इनपुट पर xss_clean के साथ समस्याओं में से कई लोग एक ही या मैजिक_कोट्स के लिए जैसे ही होते हैं: http://en.wikipedia.org/wiki/Magic_quotes

सारांश: आप इसे का उपयोग करना चाहिए नहीं बल्कि उपयोगकर्ता इनपुट पर बुरा डेटा ब्लॉक और उत्पादन पर ठीक से भाग जाते हैं। यदि आप उपयोगकर्ता डेटा को स्वच्छ करना चाहते हैं, तो यह क्लाइंट (ब्राउज़र, फॉर्म सत्यापन) में होना चाहिए ताकि उपयोगकर्ता इसे देख सके। आपके पास अदृश्य डेटा परिवर्तन कभी नहीं होना चाहिए। यदि आपको xss_clean चलाना होगा। आपको आउटपुट पर केवल एक बार इसे चलाने चाहिए।यदि आप इनपुट के सत्यापन के लिए इसका उपयोग करने जा रहे हैं, तो $ post_data! == xss_clean ($ post_data) तो अस्वीकार करें।