के साथ मान्य है, मैंने इसे "फिल्टर इनपुट, आउटपुट आउटपुट" से पहले पढ़ा है, लेकिन जब मैं PHP के साथ पीडीओ का उपयोग करता हूं तो इनपुट इनपुट वास्तव में आवश्यक है? मैंने पीडीओ के साथ सोचा कि मुझे इनपुट फ़िल्टर करने की आवश्यकता नहीं है क्योंकि तैयार कथन एसक्यूएल इंजेक्शन का ख्याल रखता है। मुझे लगता है कि "बचाना आउटपुट" अभी भी मान्य है, लेकिन "फ़िल्टर इनपुट" अभी भी मान्य है?क्या "फ़िल्टर इनपुट, एस्केप आउटपुट" अभी भी पीडीओ
हां, यह अभी भी मान्य है।
फ़िल्टरिंग सुरक्षा भेद्यता को रोकने के बारे में नहीं है, यह कचरे के साथ आपके डेटाबेस को पॉप्युलेट करने के बारे में नहीं है। यदि आप किसी तारीख की अपेक्षा कर रहे हैं, तो सुनिश्चित करें कि कम से कम इसे संग्रहीत करने से पहले एक तिथि की तरह दिखता है।
सुरक्षा से बचने की सुरक्षा कमजोरियों (अर्थात् एक्सएसएस या क्रॉस साइट स्क्रिप्टिंग) को रोकने के बारे में है।
तो हाँ, दोनों काफी महत्वपूर्ण हैं और पूरी तरह से SQL इंजेक्शन से संबंधित नहीं हैं (हालांकि डेवलपर्स का एक उचित संख्या अभी भी एसक्यूएल प्रश्नों के लिए भागने के साथ छानने भ्रमित है और इसलिए अभी भी कमजोरियों के अधीन किया जा सकता है) ...
आपके द्वारा सहेजे जा रहे डेटा के आधार पर, हाँ यह अभी भी मान्य हो सकता है।
उदाहरण के लिए, मान लीजिए कि आपके पास एक टिप्पणी बॉक्स है और उपयोगकर्ता HTML मार्कअप वाला संदेश लिखता है। इस मामले में आप अक्सर टिप्पणी टेक्स्ट से कहा गया HTML मार्कअप को हटाना चाहते हैं, भले ही यह बच निकला हो (भले ही, यह शायद बहुत अच्छा न लगे)।
अन्य मामले भी हैं, जैसे कि आपके पास फ़ोन नंबर फ़ील्ड है, तो आप इसे फ़िल्टर करना चाहेंगे ताकि यह आपके एप्लिकेशन का उपयोग करने वाले विशिष्ट प्रारूप में हो और इसी तरह।
हमेशा उपयोगकर्ता इनपुट फ़िल्टर करें। हमेशा। हो सकता है कि आप हमलों के खिलाफ सुरक्षा कर रहे हों, या हो सकता है कि आप व्यवसाय नियम सत्यापन कर रहे हों, ध्यान रखें कि ऐसी कोई तकनीक या प्रक्रिया नहीं है जो सभी हमलों को रोक देगी, केवल हमलों को रोकने के लिए इसे विशेष रूप से डिजाइन किया गया था। एसक्यूएल इंजेक्शन से बचने के लिए एकमात्र समस्या नहीं है।
क्या आप मुझे एक विचार दे सकते हैं कि आपका क्या मतलब है "एसक्यूएल इंजेक्शन एकमात्र समस्या नहीं है"। मैं समझता हूं कि मुझे आउटपुट से बचने की जरूरत है, लेकिन इनपुट के लिए, एसक्यूएल इंजेक्शन के अलावा वास्तव में और क्या है? मैंने कुछ नहीं सोचा। – sami
@sami: आप जो कर रहे हैं उस पर बहुत निर्भर करता है और आप इसे कैसे कर रहे हैं, लेकिन सामान्य रूप से सिस्टम में उपयोगकर्ता इनपुट बफर ओवरफ़्लो हमलों या अन्य चीजों के अधीन हो सकता है जो डेवलपर भी सोच नहीं सकता है, लेकिन मंच स्वयं को ठीक से संभालने के लिए सुसज्जित नहीं हो सकता है। यह दुर्लभ है, लेकिन अंगूठे का नियम बना रहता है। इस बात पर भरोसा न करें कि उपयोगकर्ता सिस्टम को क्या भेजता है। – David
एसक्यूएल इंजेक्शन और सुरक्षा के अनुसार, यदि आप बाध्य चर के साथ पीडीओ का सही ढंग से उपयोग कर रहे हैं, तो आपको स्वच्छता की आवश्यकता नहीं है। लेकिन जैसे ही जनी ने बताया कि आपके द्वारा सहेजे जा रहे डेटा के आधार पर, जैसे टेक्स्ट फ़ील्ड जो एचटीएमएल की अनुमति नहीं देता है, हो सकता है कि आप अपने डेटा को sanitize करना चाहें, या यदि फ़ील्ड एक संख्या होनी चाहिए, उस पर parseInt() चलाना या कुछ कुछ। लेकिन सुरक्षा के लिए यह आवश्यक नहीं है, लेकिन आपके डेटाबेस की सैनिटी के लिए। यह किसी तरह की बदसूरत है जब कोई टिप्पणी में एचटीएमएल डालने का प्रयास करता है और आप इसे थूकते हैं और आप > < आदि
हाँ , यह इनपुट से बच रहा है, लेकिन magic_quotes_gpc की तरह तुरंत नहीं। जादू उद्धरण एक भयानक सुरक्षा के लिए दृष्टिकोण है। भेद्यताएं इस बात पर अत्यधिक निर्भर हैं कि कैसे खराब डेटा का उपयोग किया जा रहा है, आपके पास कभी भी 1 फ़ंक्शन नहीं हो सकता है जो हर समय सबकुछ ठीक करता है। आवेदन के प्रवाह के दौरान भी एक मामला हो सकता है जब कोई अन्य कार्य magic_quotes को कम करता है, जैसे stripslashes(), base64_decode(), urldecode(), htmlspecialchars_decode($var,ENT_QUOTES); और यहां तक कि substr()।
संक्षेप में, आपको उपयोग के समय इनपुट से हमेशा बचाना होगा। pdo और adodb यह करता है, और यह पूरी तरह से करता है।
"फ़िल्टरिंग सुरक्षा भेद्यता को रोकने के बारे में नहीं है"। यह अतिस्तरीय नहीं किया जा सकता है। –
@ ircmaxell और @JW, तो मुझे लगता है कि फ़िल्टरिंग इनपुट आंशिक रूप से एसक्यूएल इंजेक्शन को रोकने के लिए गलत है? आप कह रहे हैं कि वे 2 अलग-अलग मुद्दे हैं? – sami
@ सैमी: बिल्कुल। इंजेक्शन को रोकने के लिए आपको फ़िल्टर करने की आवश्यकता नहीं है (वास्तव में यदि आप हैं, तो यह संभवतः सभी मामलों में काम नहीं करेगा), और आपको इंजेक्शन को फ़िल्टर करने से रोकने की आवश्यकता नहीं है। वे पारस्परिक रूप से समावेशी नहीं हैं (हालांकि आक्रामक फ़िल्टरिंग इंजेक्शन को रोक सकती है, जो इसका मतलब नहीं है) ... – ircmaxell