कौन सा पहले प्रदर्शन करना चाहिए? sanitizing या सत्यापन

Question

मेरे पास मेरे पंजीकरण फॉर्म में एक फ़ील्ड है जिसमें उदाहरण के लिए name फ़ील्ड है, इसे user_name varchar(20) नामक फ़ील्ड में डेटाबेस में संग्रहीत किया जाएगा। यह स्पष्ट है कि मैं उपयोगकर्ता इनपुट सत्यापित करना चाहिए अगर मैं नीचे दिए गए कोड के साथ इस क्षेत्र frist मान्य:

<?php 
if(emptiy($_pos['name']) || strlen($_post['name'])>20) 
//send an not valid input error 
else{ 
$name=htmlspcialchars($_post['name']); 
//check for sql injection; 
//insert name into database;} 
?> 

एक उपयोगकर्ता <i> some one </i> की तरह एक नाम सम्मिलित करता है, तो स्ट्रिंग लंबाई 17 है ताकि कोई और हिस्सा performe जाएगा और नाम होगा <i&gt some one </i> जो लंबाई 28 है जो इस समय db.in में डालने के दौरान त्रुटि उत्पन्न करेगी यदि मैं उपयोगकर्ता को एक त्रुटि भेजता हूं कि उसका इनपुट बहुत लंबा है तो वह भ्रमित हो जाएगा। मुझे क्या करना चाहिए? सबसे अच्छा तरीका क्या है?

Answer 1

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

इसके साथ, आप परिणामों को मान्य करते हैं - क्या नाम पहले से ही इस्तेमाल किया गया है (अद्वितीय फ़ील्ड के लिए), क्या यह सही आकार है, क्या यह खाली नहीं है?

आपके द्वारा प्रदान किए जाने का कारण सटीक सही है - उपयोगकर्ता अनुभव को अधिकतम करने के लिए। उपयोगकर्ता को भ्रमित न करें, अगर आप इससे बच सकते हैं। यह गूंगा प्रति & पेस्ट व्यवहार से बचाने में मदद करता है, लेकिन आपको सावधान रहना होगा - अगर मैं अपना नाम "के $ एच @" के रूप में दर्ज करना चाहता हूं, तो मैं इसे "केह" में बदलने के साथ ठीक हो सकता हूं या नहीं।

दूसरा, यह भी बग को रोकने के लिए है।

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

एक और उदाहरण न्यूनतम फ़ील्ड लंबाई है: यदि आपको कम से कम 3 अक्षरों की आवश्यकता होती है और केवल अक्षरों को स्वीकार करते हैं, और मैं "नहीं" दर्ज करता हूं तो आप इसे अस्वीकार कर देंगे; लेकिन अगर मैं "नहीं @ # $%" दर्ज करता हूं तो आप कह सकते हैं कि यह वैध था (लंबे समय तक पर्याप्त), इसे स्वच्छ करें, और अब यह मान्य नहीं है, आदि

इससे बचने का आसान तरीका पहले sanitize है , और फिर आपको सत्यापन के बारे में दोबारा सोचने की ज़रूरत नहीं है।

हालांकि, नाइट भंडारण से पहले डेटा एन्कोड करने के बारे में सही था; एचटीएमएल में आउटपुट को उचित रूप से एन्कोड किए जाने के रूप में आउटपुट सेट करना आम तौर पर आसान होता है, फिर इसे केवल डीकोड करना याद रखना होता है जब आप केवल सादे पाठ (टेक्स्ट बॉक्स में प्रवेश करने के लिए, JSON तारों आदि) चाहते हैं। आपके द्वारा उपयोग किए जाने वाले अधिकांश परीक्षण मामलों में HTML इकाइयों के साथ डेटा शामिल नहीं होगा, इसलिए आसानी से पकड़े गए मूर्खतापूर्ण बग को पेश करना आसान है।

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

इंजेक्शन से सुरक्षा अच्छी है, लेकिन ऐसा करने के लिए HTML एन्कोडिंग डिज़ाइन नहीं किया गया है (और उस पर भरोसा नहीं किया जाना चाहिए)।

Answer 2

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