फ़िल्टर_इनपुट का उपयोग कब करें()

Question

यह प्रश्न मूल रूप से एक टिप्पणी here पर पूछा गया था।

क्या filter_input() अभी भी आवश्यक है यदि आप किसी भी उपयोगकर्ता द्वारा प्रदत्त डेटा मुद्रित करने से पहले पैरामीटरयुक्त प्रश्नों और htmlspecialchars() का उपयोग कर रहे हैं?

यह मेरे लिए अनावश्यक लगता है, लेकिन मुझे हमेशा "फ़िल्टर इनपुट, एस्केप आउटपुट" कहा जाता है। तो, किसी डेटाबेस (या भंडारण का एक अन्य रूप) से अलग, क्या इनपुट डेटा फ़िल्टर करने की कोई आवश्यकता है?

Answer 1

ठीक है, अलग-अलग राय होने जा रहे हैं।

मेरा लेना यह है कि आपको हमेशा इसका उपयोग करना चाहिए (या, filter सामान्य रूप से एक्सटेंशन)। इसके लिए कम से कम 3 कारण हैं:

1. इनपुट को स्वच्छ करना कुछ ऐसा करना है जो आपको हमेशा करना चाहिए। चूंकि फ़ंक्शन आपको यह क्षमता देता है क्योंकि इनपुट को स्वच्छ करने के अन्य तरीकों को खोजने का वास्तव में कोई कारण नहीं है। चूंकि यह एक विस्तार है, इसलिए फ़िल्टर बहुत तेज होगा और अधिकतर PHP समाधानों की तुलना में अधिक सुरक्षित होगा, जो निश्चित रूप से चोट नहीं पहुंचाता है। एकमात्र अपवाद यह है कि यदि आपको अधिक विशिष्ट फ़िल्टर की आवश्यकता है। फिर भी आपको FILTER_UNSAFE_RAW फ़िल्टर का उपयोग करके मान लेना चाहिए (देखें # 3)।

2. filter एक्सटेंशन में बहुत सारी चीज़ें हैं। यह आपको sanitizing और सत्यापन कोड लिखने के घंटे बचा सकता है। बेशक, यह प्रत्येक मामले को कवर नहीं करता है, लेकिन पर्याप्त है ताकि आप विशिष्ट फ़िल्टरिंग/सत्यापन कोड पर अधिक ध्यान केंद्रित कर सकें।

3. फ़ंक्शन का उपयोग करना आपके कोड को डिबगिंग/ऑडिटिंग करने के लिए बहुत अच्छा है। जब फ़ंक्शन का उपयोग किया जाता है तो आप जानते हैं कि इनपुट वास्तव में क्या होगा। उदाहरण के लिए, यदि आप FILTER_SANITIZE_NUMBER_INT फ़िल्टर का उपयोग करते हैं तो आप सुनिश्चित कर सकते हैं कि इनपुट एक संख्या होगी - कोई एसक्यूएल इंजेक्शन नहीं, कोई HTML या जावास्क्रिप्ट कोड इत्यादि नहीं। यदि आप दूसरी तरफ FILTER_UNSAFE_RAW जैसे कुछ का उपयोग करते हैं तो आप जानते हैं कि इसका सावधानीपूर्वक इलाज किया जाना चाहिए, और यह आसानी से सुरक्षा समस्याओं का कारण बन सकता है।

Answer 2

जैसा कि सेवररी एम ओल्सन कहते हैं, इस पर अलग-अलग राय हैं।

मैं दर्शन फ़िल्टर इनपुट के साथ बहुत ज्यादा सहमत हूँ, एस्केप आउटपुट।

filter_input() अभी भी आवश्यक आप पैरामिट्रीकृत प्रश्नों और htmlspecialchars उपयोग कर रहे हैं है() इससे पहले कि आप किसी भी उपयोगकर्ता के आपूर्ति डेटा मुद्रित?

लघु जवाब: IMO, नहीं, यह आवश्यक नहीं है, लेकिन कुछ मामलों में उपयोगी हो सकता है।

---

filter_input समारोह में कई उपयोगी फिल्टर है, और मैं उनमें से कुछ (अर्थात FILTER_VALIDATE_EMAIL) का उपयोग करते हैं। इनपुट को मान्य करने के लिए उपयोगी हैं। हालांकि, आईएमओ, डेटा को केवल आउटपुट पर इस्तेमाल किया जाना चाहिए।

कुछ लोग इनपुट से बचने के लिए प्रोत्साहित करते हैं।दरअसल, filter_input मैनुअल पृष्ठ पर दिए गए उदाहरण इस रूप में अच्छी तरह प्रोत्साहित करने के लिए लग रहे हैं।

$search_html = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_SPECIAL_CHARS); 
$search_url = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_ENCODED); 

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

मैं इनपुट से बचने के साथ दृढ़ता से असहमत हूं। मैं पहले से ही असली दुनिया की परिस्थितियों में आया हूं जहां डेटा को बहुत जल्दी बदलना एक समस्या है।

उदाहरण के लिए, गूगल एनालिटिक्स इस तरह खड़ी कर रहा है कि मेरे इनकोडिंग एम्परसेंड्स (% 26) क्वेरी करने के लिए मानकों को बाहर रखा जा रहा से पहले डीकोड किया जा करने के लिए इनपुट संसाधित करता है। नतीजा यह है कि मेरे पास क्वेरी पैरामीटर के आंकड़े हैं जो वास्तव में मेरे यूआरएल में भी मौजूद नहीं हैं। इस समस्या के बारे में my question देखें जो अनसुलझे बनी हुई है।

तुम भी Why escape-on-input is a bad idea से पढ़ सकते हैं। यहां कुछ अंश दिए गए हैं जिनसे मैं सहमत हूं, अगर लेख गायब हो जाता है [मूल में जोर]।

[...] से बचने-ऑन-इनपुट सिर्फ गलत [...] यह एक लेयरिंग उल्लंघन है है - यह एक उत्पादन इनपुट से निपटने में चिंता स्वरूपण घुलमिल। लेयरिंग उल्लंघन, अपने कोड बहुत कठिन समझते हैं और बनाए रखने के लिए बनाने क्योंकि तुम बजाय दे प्रत्येक घटक और परत का अपना काम करने के अन्य स्तर को ध्यान में रखना है।

और

आप डिफ़ॉल्ट रूप से अपने डेटा दूषित है। प्रणाली [...] अब कौन-सा डेटा में आ गया है के बारे में झूठ बोल रही है।

और

इनपुट पर पलायन केवल एक से अधिक उत्पादन की समस्याओं, यह से निपटने के लिए असफल नहीं हो वास्तव में आपके डेटा गलत कई आउटपुट के लिए बनाते हैं।

और

पीएचपी एक सुविधा मैजिक कोट नामक किया करते थे। यह एक बचने वाली इनपुट सुविधा थी जो [...] सभी प्रकार की समस्याओं का कारण बनती है। [...] लेरडोर्फ़ के अनुसार, बहुत नया PHP 'फ़िल्टर' एक्सटेंशन "magic_quotes सही किया गया है"। लेकिन यह अभी भी यहां वर्णित लगभग सभी समस्याओं से ग्रस्त है।

तो फिल्टर विस्तार मैजिक कोट (वास्तव में यह कई अलग अलग फिल्टर है कि अन्य की तुलना में) की तुलना में बेहतर है? फ़िल्टरों में से कई मुद्दों का कारण बनता है जो जादू उद्धरण करते थे।

---

यहाँ कोडिंग सम्मेलनों मैं का उपयोग कर रहे हैं: $ _POST में

• मूल्यों, $ _GET, $ _REQUEST, आदि नहीं किया जाना चाहिए और हमेशा असुरक्षित विचार किया जाना चाहिए
• मान को डेटाबेस में लिखे जाने से पहले या $ _SESSION
• में संग्रहीत होने से पहले मूल्यवान होना चाहिए, संख्यात्मक या बूलियन होना चाहिए से पहले डेटाबेस के लिए लिखित या में संग्रहीत $ _SESSION
• विश्वास है कि डेटाबेस से सांख्यिक और बूलियन मूल्यों और $ _SESSION वास्तव में संख्यात्मक या बूलियन हैं किया जा रहा
• स्ट्रिंग मान एसक्यूएल-भाग निकले किसी भी SQL क्वेरी में सीधे इस्तेमाल किया जा रहा से पहले किया जाना चाहिए (गैर स्ट्रिंग मान स्वच्छ होना चाहिए) या का उपयोग तैयार बयान
• स्ट्रिंग मान HTML आउटपुट में इस्तेमाल किया जा रहा से पहले एचटीएमएल-भाग निकले किया जाना चाहिए (गैर स्ट्रिंग मूल्यों स्वच्छ होना चाहिए)
• स्ट्रिंग मान चाहिए क्वेरी स्ट्रिंग्स में इस्तेमाल होने से पहले प्रतिशत-एन्कोडेड हो (गैर स्ट्रिंग मूल्यों स्वच्छ होना चाहिए)
• ) जैसे * _url, * _html, * _sql (एक चर नामकरण परंपरा का उपयोग तब्दील डेटा

स्टोर करने के लिए शब्दावली

के लिए मेरी यहां उद्देश्यों, इस प्रकार मैं ऊपर इस्तेमाल की गई शर्तों को परिभाषित करता हूं।

1. किसी भी मान्यताओं की पुष्टि करने के साधन मान्य करने के लिए इस तरह के एक विशिष्ट स्वरूप होने के रूप में डेटा या आवश्यक फ़ील्ड एक मूल्य
2. होने की पुष्टि करने के मूल्यों बिल्कुल अपेक्षा के अनुरूप (यानी $ ID_NUM चाहिए रहे हैं साधन को साफ़ करने में के बारे में बनाया जा रहा है लेकिन अंक कुछ भी नहीं)

सारांश

सामान्य तौर पर होते हैं (कुछ अपवाद हो सकता है), मैं सलाह देते हैं निम्नलिखित:

• उपयोग उत्पादन
• पर validate filters पर इनपुट
• उपयोग sanitize filters याद TIMTOWDI - उदाहरण के लिए, मैं htmlspecialchars() FILTER_SANITIZE_FULL_SPECIAL_CHARS या FILTER_SANITIZE_SPECIAL_CHARS से अधिक (जो और अधिक विकल्प हैं) (पसंद करते हैं जो लाइन ब्रेक से बच निकलता है)