डेटा सत्यापन / स्वच्छता के लिए प्लगइन्स किस संदर्भ में उत्तरदायी हैं?

Question

मैं यह सुनिश्चित करना चाहता हूं कि मेरे प्लग इन / थीम के सभी डेटा को डेटाबेस में प्रवेश करने से पहले और ब्राउज़र पर आउटपुट होने से पहले सुरक्षित रूप से संभाला जाए। मेरी समस्या यह है कि ऐसी परिस्थितियाँ हैं जहाँ एपीआई आपके लिए सैनिटाइजेशन को संभालता है - जैसे कि पोस्ट मेटा फ़ील्ड्स को सहेजते समय - और अन्य जहाँ प्लगइन / थीम लेखक इसे करने के लिए पूरी तरह से जिम्मेदार है - जैसे कि कस्टम सेटिंग्स को सहेजते समय।

इस प्रश्न के दायरे के लिए, मैं डोमेन स्तर पर डेटा को सत्यापित करने के बारे में चिंतित नहीं हूं - उदाहरण के लिए, यह जाँचना कि किसी फॉर्म पर आयु क्षेत्र 0 से 120 के बीच है, या यह कि ई-मेल पता मान्य है। मैं केवल सुरक्षा के बारे में चिंतित हूं - उदाहरण के लिए, डेटाबेस को सहेजते समय SQL इंजेक्शन से बचने के लिए SQL प्रश्नों से बचना, या XSS से बचने के लिए HTML टेम्पलेट्स के लिए आउटपुट डेटा को साफ करना।

आउटपुट सैनिटाइजेशन के लिए, मुझे पता है कि आपको HTML टेम्प्लेट में हमेशा वैरिएबल जैसे जब esc_html()और जैसे कार्यों का उपयोग करने की आवश्यकता होती है esc_attr()। लेकिन, टेम्प्लेट टैग का उपयोग करते समय क्या होगा ? क्या वे सभी पहले से ही उत्पादन को साफ करते हैं? यदि हां, तो किस संदर्भ के लिए (सामान्य HTML, टैग विशेषताएँ, आदि)? कुछ कार्यों में विभिन्न संदर्भों के लिए वेरिएंट होते हैं (जैसे the_title_attribute(), लेकिन अधिकांश नहीं।

इनपुट सैनिटाइजेशन के लिए, मुझे पता है कि मुझे $wpdb->prepare()मैन्युअल क्वेरी बनाते समय उपयोग करने की आवश्यकता है , लेकिन एक सेटिंग सेटिंग्स पेज बनाने के लिए सेटिंग्स एपीआई का उपयोग करते समय या कस्टम पोस्ट प्रकार के लिए पोस्ट मेटा फ़ील्ड को बचाने के बारे में क्या?

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

एपीआई मान्य / sanitizes

• सेविंग पोस्ट मेटा के साथ update_postmeta()
• के साथ उपयोगकर्ता मेटा सहेजा जा रहा है update_user_meta()
• पोस्ट शीर्षक का आउटपुट - के संदर्भ में उपयुक्त रूपांतर का उपयोग करें the_title()
• आदि

आपको मैन्युअल रूप से मान्य / स्वच्छता करना होगा

• सेटिंग्स एपीआई के साथ प्लगइन विकल्प की बचत। 3 के पैरामीटर के रूप में कॉलबैक पास करें register_setting()।
• डायरेक्ट डेटाबेस क्वेरीज़: इसमें क्वेरी लपेटें $wpdb->prepare()।
• HTML में आउटपुट चर। का उपयोग करें esc_attr(), esc_html()आदि
• आदि

मुझे यह समझने में भी दिलचस्पी होगी कि एपीआई कुछ स्थितियों में इसे क्यों प्रदान करता है, लेकिन दूसरों को नहीं। मुझे लगता है कि यह डेटा की अज्ञात प्रकृति के साथ कुछ करना है, लेकिन पूरी तरह से स्पष्टीकरण सुनना पसंद करेंगे।

Comments

मुझे यह सवाल पसंद है। मेरे पास आपके जैसा ही विचार है। मुझे लगता है कि अगर ऐसी कोई सूची है जब हमें मैन्युअल रूप से मान्य / सैनिटाइज़ करना होगा, तो यह बहुत अच्छा होगा। +1।

— अनह त्रान

@Rilwis, कृपया मेरा उत्तर देखें। आपको हमेशा मान्य होना चाहिए। '' सुरक्षित '' संदर्भ के रूप में निर्भर होने पर, संधिवादिता छल है। आम तौर पर, वर्डप्रेस-ज्ञात डेटा ( the_title(), the_permalink()आदि) के साथ वर्डप्रेस एपीआई का उपयोग करते समय आप ठीक हैं लेकिन कस्टम डेटा के साथ आप नहीं हैं (जैसे get_post_meta())। यदि संदेह है, तो अपने आप को पवित्र करें - यह चोट नहीं पहुंचा सकता है।

— स्टीफन हैरिस

@StephenHarris: मैंने आपकी टिप्पणी पढ़ी। मुझे पता है कि, भी। लेकिन इयान डन के बारे में मेरी भी यही राय है। मुझे लगता है कि मुख्य कारण वह पूछता है "पर्याप्त करो, और नहीं, कम नहीं"।

— ट्रान

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

— इयान डन

Answer 1

यहाँ दो अवधारणाएँ हैं:

• सत्यापन - यह सुनिश्चित करना कि डेटा वैध है , यानी एक पूर्णांक एक पूर्णांक है, एक तारीख एक तारीख है (सही प्रारूप आदि में)। यह डेटा को बचाने से पहले किया जाना चाहिए।
• sanitisation - वर्तमान संदर्भ में इसके उपयोग के लिए तिथि को सुरक्षित बनाना (जैसे SQL प्रश्नों से बचना, या आउटपुट पर HTML से बचना)।

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

संधिवात थोड़ा अधिक मिश्रित होता है। उस डेटा के साथ काम करना, जिसके बारे में वर्डप्रेस मूल रूप से जानता है (उदाहरण के लिए एक पोस्ट की टाइल) आप यह सुनिश्चित कर सकते हैं कि वर्डप्रेस पहले ही डेटा को सुरक्षित बना चुका है। हालांकि 'सुरक्षित' संदर्भ पर निर्भर करता है; एक पृष्ठ पर उपयोग के लिए जो सुरक्षित है, वह तत्व विशेषता के रूप में सुरक्षित नहीं है। इसलिए वर्डप्रेस अलग संदर्भ के लिए (जैसे विभिन्न कार्यों होगा the_title(), the_title_rss(), the_title_attribute()-) ताकि आप सही उपयोग करना ।

अधिकांश भाग के लिए आपका प्लग-इन पोस्ट मेटा के साथ सौदा कर सकता है - या शायद कस्टम टेबल से इवेंट डेटा। वर्डप्रेस को पता नहीं है कि यह डेटा क्या है या इसके लिए क्या है, इसलिए यह निश्चित रूप से नहीं जानता कि इसे सुरक्षित कैसे बनाया जाए। यह आप पर निर्भर है । इस का उपयोग करने में विशेष रूप से महत्वपूर्ण है esc_url(), esc_attr(), esc_textarea()आदि एम्बेड कोड करने में सक्षम होने से दुर्भावनापूर्ण इनपुट को रोकने के लिए। चूंकि वर्डप्रेस जानता next_posts()है कि पृष्ठ पर एक url प्रिंट करना है, यह लागू होता है esc_url()- लेकिन पोस्ट मेटा के साथ, कहते हैं, यह नहीं जानता कि यह एक url संग्रहीत करता है - या आप इसके साथ क्या करना चाहते हैं (यदि मुद्रण esc_url(), यदि रीडायरेक्ट हो esc_url_raw()। अगर डबट में - सावधानी के पक्ष में और इसे अपने आप से बचो - और जितना संभव हो उतना देर से करें।

अंत में - डेटा बचाने के बारे में क्या? क्या आपको इसे सुरक्षित बनाने की आवश्यकता है? जैसा कि आप का उल्लेख करना सुनिश्चित करें कि डेटा मान्य है बनाने के लिए की जरूरत है। लेकिन अगर वर्डप्रेस एपीआई ( आदि) का उपयोग कर रहे हैं wp_insert_post(), update_post_meta()तो आपको डेटा को सैनिटाइज़ करने की आवश्यकता नहीं है - क्योंकि जब डेटा को बचाने के लिए केवल सैनिटाइज़िंग करने की ज़रूरत होती है, तो एसक्यूएल स्टेटमेंट से बचना है - और वर्डप्रेस ऐसा करता है। यदि आप प्रत्यक्ष SQL स्टेटमेंट (कस्टम टेबल से डेटा पढ़ने / लिखने के लिए कहते हैं) चला रहे हैं, तो आपको $wpdbअपने प्रश्नों को स्पष्ट करने में मदद करने के लिए क्लास का उपयोग करना चाहिए ।

मैंने इस ब्लॉग पोस्ट को डेटा स्वच्छता और सत्यापन पर लिखा है, जो आपको उपयोगी लग सकता है - इसमें मैं इस बारे में बात करता हूं कि इस संबंध में आपसे क्या अपेक्षा है।

Comments

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

— इयान डन

मैंने केवल कुछ चीजों को स्पष्ट करने के लिए प्रश्न को अपडेट किया।

— इयान डन

Answer 2

सुनिश्चित नहीं है कि यह पूरी तरह से है, लेकिन किसी भी प्लगइन या थीम के साथ, उपयोगकर्ता इनपुट को साफ किया जाना चाहिए। $ Wpdb-> विधियों का उपयोग करके डेटाबेस संचालन किया जाना चाहिए। सभी $ _GET और $ _POST डेटा को सैनिटाइज़ किया जाना चाहिए।

यह वर्डप्रेस की तुलना में PHP प्रोग्रामिंग के लिए सबसे अच्छा अभ्यास है।

तो, निष्कर्ष में, यदि कोई वर्डप्रेस फ़ंक्शन है, तो इसका उपयोग करें, यदि नहीं, तो अपने चर और इनपुटों को स्वयं करें।

यदि मैं बहुत अधिक अस्पष्ट था, तो कृपया एक अधिक विशिष्ट प्रश्न पूछें।

Comments

मैं समझता हूं कि इसे हमेशा स्वच्छता की आवश्यकता है, लेकिन सवाल यह है कि प्रत्येक विशेष परिस्थिति में कौन करता है कभी-कभी वर्डप्रेस यह स्वचालित रूप से करता है, और कभी-कभी आपको इसे मैन्युअल रूप से करना पड़ता है। मैंने प्रश्न को अपडेट करने और इसे अधिक स्पष्ट बनाने के लिए अद्यतन किया है।

— इयान डन

यहां तक ​​कि अपडेट_सियर_मेटा () का उपयोग करते समय, आपको अभी भी इसे सत्यापित करने की आवश्यकता है, क्योंकि अपडेट किए गए मान एक उजागर रूप से या उपयोगकर्ता के इनपुट से आ सकते हैं। यदि यह एक स्क्रिप्ट से आने वाला मूल्य है, जैसे कि अंदर का निर्णय, यदि / if पाश से, तो आपको इसे साफ नहीं करना चाहिए।

— सिप्रियन

आप जिस मूल्य से गुजरते हैं, वह update_user_meta()गुजरता है stripslashes_deep()और sanitize_meta()भीतर update_metadata(), और फिर $wpdb->prepare()अंदर जाता है $wpdb->update()। इसलिए, मुझे नहीं लगता कि आपको इसे साफ करने की आवश्यकता है। क्या मैं कुछ भूल रहा हूँ?

— इयान डन