डेटाबेस में दुर्भावनापूर्ण कोड संग्रहीत करना - हमेशा से सही दृष्टिकोण से बचने पर आउटपुट है?

Question

बस यहां सोच को समझना चाहते हैं और इस मुद्दे के लिए एक सही और स्वीकार्य दृष्टिकोण पर पहुंचना चाहते हैं। संदर्भ के लिए यह एक वेब वातावरण में है और हम डेटाबेस में इनपुट से बचने के बारे में बात कर रहे हैं।

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

डेटाबेस में कुछ भी डालने से पहले हम सुनिश्चित करते हैं कि डेटाबेस की सुरक्षा के लिए कोई एसक्यूएल इंजेक्शन हमले नहीं हैं।

हालांकि following the principals set out here और here, वे उपयोगकर्ता इनपुट को सहेजने के दृष्टिकोण का सुझाव देते हैं। यह उपयोगकर्ता इनपुट SQL इंजेक्शन हमला नहीं हो सकता है, लेकिन यह अन्य दुर्भावनापूर्ण कोड हो सकता है। इन मामलों में जावास्क्रिप्ट आधारित एक्सएसएस हमलों को डेटाबेस में स्टोर करना ठीक है?

मैं सिर्फ यह जानना चाहता हूं कि मेरी धारणाएं सही हैं या नहीं, क्या हम डेटाबेस में दुर्भावनापूर्ण कोड संग्रहीत करने के साथ ठीक हैं, जब तक कि दुर्भावनापूर्ण कोड डेटाबेस को सीधे प्रभावित नहीं करता है? क्या यह डेटाबेस की समस्या नहीं होने का मामला है, यह दुर्भावनापूर्ण कोड के नुकसान से बचने के लिए इस दुर्भावनापूर्ण कोड और आउटपुट डिवाइस तक हो सकता है?

या क्या हमें इन प्रिंसिपल द्वारा सुझाए गए इनपुट से अधिक भागना चाहिए - क्या सुरक्षा चिंताएं आउटपुट से बचने के विचार से पहले आती हैं? क्या हमें इस दृष्टिकोण को लेना चाहिए कि डेटाबेस में कोई दुर्भावनापूर्ण कोड प्रवेश नहीं करता है? हम दुर्भावनापूर्ण कोड को फिर भी क्यों स्टोर करना चाहते हैं?

किसी वेब क्लाइंट/सर्वर वातावरण के संदर्भ में किसी डेटाबेस में दुर्भावनापूर्ण कोड सहेजने का सही तरीका क्या है?

[इस के प्रयोजनों के मैं किसी भी साइटों है कि विशेष रूप से कोड उन पर साझा करने की अनुमति अनदेखी कर रहा हूँ के लिए, मैं इस तरह के नाम, टिप्पणी और विवरण फ़ील्ड के रूप में "सामान्य" आदानों में सोच रहा हूँ।]

Answer 1

परिभाषा: मैं फ़िल्टर या भागने के बजाय "sanitize" शब्द का उपयोग करें, क्योंकि एक तीसरा विकल्प है: अमान्य इनपुट को अस्वीकार कर रहा है। उदाहरण के लिए, उपयोगकर्ता को एक त्रुटि लौटाने का कहना है कि "चरित्र‽ शीर्षक में उपयोग नहीं किया जा सकता है" इसे कभी भी स्टोर करने से रोकता है।

उपयोगकर्ता इनपुट की बचत के रूप में

की सुरक्षा सिद्धांत है "गहन सुरक्षा" पता चलता है कि आप किसी भी संभावित दुर्भावनापूर्ण इनपुट के रूप में जल्दी और अक्सर संभव के रूप में स्वच्छ करना चाहिए। व्हाइटलिस्ट केवल आपके आवेदन के लिए उपयोगी मूल्य और तार। लेकिन अगर आप ऐसा करते हैं, तो आपको इन मानों को एन्कोड/से बचाना होगा।

हम दुर्भावनापूर्ण कोड को क्यों स्टोर करना चाहते हैं?

ऐसे समय होते हैं जहां सटीकता पारानोआ से अधिक महत्वपूर्ण होती है। उदाहरण के लिए: उपयोगकर्ता प्रतिक्रिया में संभावित रूप से विघटनकारी कोड शामिल करने की आवश्यकता हो सकती है। मैं उपयोगकर्ता प्रतिक्रिया लिखने की कल्पना कर सकता हूं जो कहता है, "प्रत्येक बार जब मैं विकी शीर्षक के हिस्से के रूप में %00 टाइप करता हूं तो एप्लिकेशन क्रैश हो जाता है।" भले ही विकी शीर्षकों को %00 वर्णों की आवश्यकता न हो, फिर भी टिप्पणी को उन्हें सटीक रूप से प्रेषित करना चाहिए। टिप्पणियों में इसे अनुमति देने में विफल ऑपरेटरों को एक गंभीर मुद्दे के बारे में सीखने से रोकता है।देखें: Null Byte Injection

आउटपुट डिवाइस के लिए ऊपर दुर्भावनापूर्ण कोड

आप मनमाने ढंग से डेटा स्टोर करने के लिए की जरूरत है की नुकसान से बचने के लिए, सही दृष्टिकोण के रूप में आप किसी अन्य एन्कोडिंग प्रकार के लिए स्विच से बचने के लिए है । ध्यान दें कि आपको डीकोड करना होगा (अनदेखा) और फिर एन्कोड (बचें); गैर-एन्कोडेड डेटा जैसी कोई चीज नहीं है - यहां तक ​​कि बाइनरी कम से कम बिग-एंडियन या स्मॉल-एंडियन है। अधिकांश लोग स्ट्रिंग्स में निर्मित 'सबसे डीकोडेड' प्रारूप के रूप में भाषा का उपयोग करते हैं, लेकिन यूनिकोड बनाम ASCII पर विचार करते समय भी वह भद्दा हो सकता है। वेब अनुप्रयोगों में उपयोगकर्ता इनपुट URLEncoded, HTTP एनकोडेड, या "सामग्री-प्रकार" शीर्षलेख के अनुसार एन्कोड किया जाएगा। देखें: http://www.ietf.org/rfc/rfc2616.txt

अधिकांश सिस्टम अब आपके लिए टेम्पलेटिंग या पैरामीटरयुक्त क्वेरी के हिस्से के रूप में ऐसा करते हैं। उदाहरण के लिए, Query("INSERT INTO table VALUES (?)", name) जैसे पैरामीटरयुक्त क्वेरी फ़ंक्शन नाम में सिंगल कोट्स या किसी अन्य चीज़ से बचने की आवश्यकता को रोक देगा। यदि आपके पास ऐसी सुविधा नहीं है, तो यह और Decode() फ़ंक्शन जैसे निर्माता के साथ HTMLString जैसे डेटा प्रति एन्कोडिंग प्रकार को ट्रैक करने वाली ऑब्जेक्ट्स बनाने में मदद करता है।

क्या हमें यह दृष्टिकोण लेना चाहिए कि कोई दुर्भावनापूर्ण कोड डेटाबेस में प्रवेश न करे?

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

Answer 2

यह उपयोगकर्ता इनपुट SQL इंजेक्शन हमला नहीं हो सकता है, लेकिन यह अन्य दुर्भावनापूर्ण कोड हो सकता है। इन मामलों में डेटाबेस में जावास्क्रिप्ट आधारित XSS हमलों को स्टोर करना ठीक है?

यह अपने यूज-केस के आधार पर ठीक हो सकता है। सैद्धांतिक रूप से, डेटाबेस को संग्रहीत डेटा के उपयोग के अज्ञेय होना चाहिए। नतीजतन, डेटाबेस में कच्चे डेटा को स्टोर करना उचित होगा और उत्पादन आउटपुट मीडिया के आधार पर आउटपुट के दौरान उन्हें बचाना उचित होगा।

मैं सिर्फ यह जानना चाहते हैं मेरी मान्यताओं यहाँ सही हैं, हम इतने लंबे समय के रूप में है कि दुर्भावनापूर्ण कोड सीधे डेटाबेस को प्रभावित नहीं करता डेटाबेस में दुर्भावनापूर्ण कोड के भंडारण के साथ सभी ठीक हैं करना चाहते हैं? क्या यह का मामला है, यह डेटाबेस की समस्या नहीं है, यह दुर्भावनापूर्ण कोड के नुकसान से बचने के लिए इस दुर्भावनापूर्ण कोड और आउटपुट डिवाइस तक पहुंच सकता है?

जैसा ऊपर बताया गया है, क्या डेटा का एक टुकड़ा "दुर्भावनापूर्ण" संदर्भ के लिए अत्यधिक निर्भर है और जिस तरह से इसका उपयोग किया जाता है। उदाहरण देने के लिए, <script>...</script> डेटा के टुकड़े के रूप में एक HTML वेबपृष्ठ में प्रस्तुत किए जाने पर गंभीर समस्याएं पैदा कर सकती हैं। हालांकि, इसे मुद्रित दस्तावेज़/रिपोर्ट में दिखाए जाने के लिए संभावित रूप से एक वैध कानूनी पेलोड माना जा सकता है। कच्चे रूप में डेटा संग्रहित करने और आउटपुट माध्यम के आधार पर उन्हें बचने के सामान्य सुझाव के पीछे यह तर्क है। सीधे अपने प्रश्न का उत्तर देने के लिए, हाँ कोई तर्क दे सकता है कि डेटाबेस में इस डेटा को संग्रहीत करना बिल्कुल ठीक है, जहां तक ​​सभी संभावित मीडिया के लिए सभी भागने वाली तंत्र मौजूद हैं।

या क्या हम एक से अधिक इन प्रिंसिपलों ने सुझाव दिया इनपुट पर भागने करना चाहिए - सुरक्षा चिंताओं उत्पादन पर भागने के विचार से पहले आ जाता है? क्या हमें दृष्टिकोण लेना चाहिए कि कोई दुर्भावनापूर्ण कोड डेटाबेस में प्रवेश करता है? हम दुर्भावनापूर्ण कोड को फिर भी क्यों स्टोर करना चाहते हैं?

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