2010-09-03 13 views
5

मैं कुछ पर बहुत उलझन में हूं और सोच रहा था कि कोई समझ सकता है या नहीं।उपयोगकर्ता इनपुट मान्य?

PHP में मैं उपयोगकर्ता इनपुट को मान्य करता हूं इसलिए htmlentitiies, mysql_real_escape_string का उपयोग डेटाबेस में डालने से पहले किया जाता है, सबकुछ पर नहीं, क्योंकि मैं नियमित अभिव्यक्तियों का उपयोग करना पसंद करता हूं, हालांकि मैं उन्हें काम करने में कठोर महसूस करता हूं। अब स्पष्ट रूप से मैं mysql_real_escape_string का उपयोग करूंगा क्योंकि डेटा डेटाबेस में जा रहा है, लेकिन मुझे यकीन नहीं है कि मैं डेटाबेस से डेटा प्राप्त करते समय और वेबपृष्ठ पर इसे प्रदर्शित करने के दौरान htmlentities() का उपयोग कर रहा हूं क्योंकि हाथ से पहले ऐसा करने से पहले किसी व्यक्ति द्वारा दर्ज डेटा को बदल दिया जाता है। यह मूल रूप नहीं रख रहा है जो समस्या का कारण बन सकता है अगर मैं बाद में किसी अन्य चीज़ के उपयोग के लिए उस डेटा का उपयोग करना चाहता हूं।

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

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

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

क्या कोई अंततः मेरे लिए इस भ्रम को बंद कर सकता है और मुझे बता सकता है कि मुझे क्या करना चाहिए और सबसे अच्छा अभ्यास क्या है?

किसी भी व्यक्ति को धन्यवाद जो समझा सकता है।

चीयर्स!

उत्तर

2

यह एक लंबे सवाल है, लेकिन मुझे लगता है कि क्या आप वास्तव में पूछ रहे हैं करने के लिए नीचे फोड़े: "मैं अपने डेटाबेस में डालने से पहले बच चाहिए HTML, या जब मैं इसे प्रदर्शित करने के लिए जाना"

इस सवाल का आम तौर पर स्वीकार जवाब यह है कि आप HTML यह डेटाबेस में डालने से पहले बच चाहिए (htmlspecialchars के माध्यम से) जब आप उपयोगकर्ता के लिए यह प्रदर्शित करने के लिए जाते हैं, और नहीं है।

कारण यह है: डेटाबेस डेटा स्टोर करता है। आप जो भी डाल रहे हैं वह उपयोगकर्ता द्वारा टाइप किया गया है।जब आप mysql_real_escape_string पर कॉल करते हैं, तो यह डेटाबेस में जो भी डाला जाता है उसे परिवर्तित नहीं करता है; यह केवल उपयोगकर्ता के इनपुट को SQL कथन के रूप में व्याख्या करने से बचाता है। htmlspecialchars एचटीएमएल के लिए एक ही बात करता है; जब आप उपयोगकर्ता के इनपुट को प्रिंट करते हैं, तो यह HTML के रूप में व्याख्या करने से बच जाएगा। यदि आप डालने से पहले htmlspecialchars पर कॉल करना चाहते थे, तो आप अब वफादार नहीं रह रहे हैं।

आपको हमेशा अधिकतम-निष्ठा प्रतिनिधित्व प्राप्त करने का प्रयास करना चाहिए। चूंकि आपके डेटाबेस में "दुर्भावनापूर्ण" कोड को संग्रहीत करने से कोई नुकसान नहीं होता है (असल में, यह आपको कुछ जगह बचाता है, क्योंकि एचटीएमएल से बचने से अनचाहे से अधिक लंबा होता है!), और आप भविष्य में चाहते हैं कि HTML (यदि आप एक उपयोगकर्ता टिप्पणियों पर एक्सएमएल पार्सर, या कुछ दिन भरोसेमंद उपयोगकर्ताओं को उनकी टिप्पणियों में एचटीएमएल का सबसेट है, या कुछ ऐसे?), ऐसा क्यों नहीं होने दें?

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

एक और नोट पर, PHP से बचने वाले डेटाबेस को करने का सबसे अच्छा तरीका संभवतः mysql_real_escape_string पर कॉल करने के बजाय पीडीओ का उपयोग करना है। पीडीओ में टाइपिंग जांच सहित अधिक उन्नत कार्यक्षमता है।

1

mysql_real_escape_string() आपको डेटाबेस संचालन के लिए आवश्यक सभी चीजें हैं। यह सुनिश्चित करेगा कि एक दुर्भावनापूर्ण उपयोगकर्ता डेटा में कुछ एम्बेड नहीं कर सकता है जो आपके प्रश्नों को "तोड़ देगा"।

htmlentities() और htmlspecialchars() जब आप क्लाइंट/ब्राउज़र पर सामान भेजने के साथ काम कर रहे हों तो खेलें। यदि आप संभावित रूप से शत्रुतापूर्ण HTML को साफ़ करना चाहते हैं, तो आप HTMLPurifier का उपयोग करना बेहतर कर देंगे, जो डेटा को बिस्तर के किनारे पर पट्टी कर देगा और इसे ब्लीच के साथ दबाएगा और इसे ठीक से पुनर्निर्माण करेगा।

+0

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

+0

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

+0

धन्यवाद मार्क और हर कोई, वास्तव में मेरे सभी सवालों का जवाब दिया है और अधिक, मैंने इस पोस्ट को बनाने से बहुत कुछ सीख लिया है और अब कम से कम कहने में आराम महसूस कर रहा हूं :) आप सभी को बहुत मदद मिली है इसलिए आप सभी को धन्यवाद। – PHPLOVER

0

डेटाबेस में दुर्भावनापूर्ण जावास्क्रिप्ट कोड होने की चिंता करने का कोई कारण नहीं है यदि आप बाहर आने पर HTML से बच रहे हैं। बस सुनिश्चित करें कि आप हमेशा डीबी से बाहर आने वाली किसी भी चीज से बचें।

संबंधित मुद्दे