पीएस डाटाबेस सबसे अच्छा अभ्यास पीडीओ के माध्यम से है, इसलिए एसक्यूएल इंजेक्शन का कोई खतरा नहींउपयोगकर्ता नामों पर मुझे क्या प्रतिबंध लगाए जाएंगे
धन्यवाद
ठीक है, तो मान लीजिए कि आप अपने सभी स्ट्रिंग-एन्कोडिंग कार्यों को सही कर रहे हैं। आपके पास कोई एसक्यूएल इंजेक्शन, एचटीएमएल इंजेक्शन, या वे जगह नहीं हैं जहां आप यूआरएल-एन्कोडिंग नहीं कर रहे हैं जो आपको चाहिए। तो हमें कुछ संदर्भों में "< &% \ जादू होने वाले पात्रों के बारे में चिंता करने की आवश्यकता नहीं है। और आप कुछ भी के लिए यूटीएफ -8 का उपयोग कर रहे हैं ताकि यूनिकोड सभी खेल सकें। उपयोगकर्ता नामों को सीमित करने के लिए अन्य कारण क्या हैं?
के साथ, सभी नियंत्रण वर्ण प्रारंभ करने के लिए विवेक के लिए। वहाँ वर्ण के लिए कोई कारण नहीं है U + 0000 के लिए U + 001F या U + 007F एक उपयोगकर्ता नाम में U + 009F करने के लिए।
इसके बाद, इनकार या अप्रत्याशित सामान्य व्हाईटस्पेस। आप उपयोगकर्ता नाम में एक स्थान की अनुमति दे सकते हैं, लेकिन आप लगभग निश्चित रूप से अग्रणी रिक्त स्थान, पीछे की जगहों, या एक पंक्ति में एक से अधिक स्थान की अनुमति नहीं देना चाहते हैं। वे HTML में इसे प्रस्तुत कर सकते हैं, लेकिन शायद उपयोगकर्ता त्रुटि जो भ्रमित होगी।
यदि आप उस उपयोगकर्ता नाम को HTTP मूल प्रमाणीकरण के माध्यम से लॉगिन करने के लिए उपयोग करने का इरादा रखते हैं, तो आपको : वर्ण को अस्वीकार करना होगा, क्योंकि मूल एथ योजना उपयोगकर्ता नाम में कोई कॉलन होने पर बचने के साथ 'उपयोगकर्ता नाम: पासवर्ड' जोड़ी को एन्कोड करता है या नहीं पारण शब्द।तो कम से कम उपयोगकर्ता नाम और पासवर्ड में कोलन को छोड़ दिया जाना चाहिए, और यह बेहतर है कि यह उपयोगकर्ता नाम है क्योंकि पासवर्ड की लोगों की पसंद को प्रतिबंधित करना उपयोगकर्ता नामों की तुलना में एक बहुत ही बदतर चीज है।
मूल प्रमाणीकरण के लिए आप सभी गैर-ASCII वर्णों को भी अक्षम करना चाहते हैं, क्योंकि उन्हें विभिन्न ब्राउज़रों द्वारा अलग-अलग संभाला जाता है। आईई सिस्टम कोडपेज का उपयोग कर उन्हें एन्कोड करता है; फ़ायरफ़ॉक्स आईएसओ -885 9 -1 का उपयोग करके उन्हें एन्कोड करता है; ओपेरा उन्हें यूटीएफ -8 का उपयोग करके एन्कोड करता है। गैर-ASCII नामों को चुनने से पहले उपयोगकर्ताओं को कम से कम चेतावनी दी जानी चाहिए यदि HTTP एथ उपलब्ध होने जा रहा है, वास्तव में उनका उपयोग करना बहुत अविश्वसनीय होगा।
अगला अन्य यूनिकोड नियंत्रण अनुक्रमों पर विचार करें, bidi ओवरराइड जैसी चीजें और सूचीबद्ध अन्य वर्ण मार्कअप में उपयोग के लिए अनुपयुक्त हैं। शायद आप उन्हें मार्कअप में डालने के लिए खत्म होने जा रहे हैं और आप अपने पृष्ठ में आरएलओ वाले किसी व्यक्ति को अपने पृष्ठ में पाठ का भार बदलने के लिए नहीं चाहते हैं।
इसके अलावा, यदि आप यूनिकोड को तारों पर सामान्यीकरण करने की अनुमति देते हैं। अन्यथा किसी के पास एक रचनाकृत ओ-उमलॉट चरित्र ö के साथ उपयोगकर्ता नाम हो सकता है, और आश्चर्य हो सकता है कि वे मैक पर क्यों लॉग इन नहीं कर सकते हैं, जो डिफ़ॉल्ट रूप से अलग o वर्ण का उपयोग करते हैं, जिसके बाद umlaut संयोजन होता है। वेब पर बनाये गये फॉर्म एनएफसी को सामान्य बनाना सामान्य बात है। आप फॉर्म एनएफकेसी का उपयोग कर संगतता अपघटन भी कर सकते हैं; इससे उपयोगकर्ता क्रिस को फुलविड्थ रोमाजी मोड टाइपिंग क्रिस में जापानी कीबोर्ड से लॉग इन करने की अनुमति देगा। ये सामान्य मुद्दे हैं जो आपके सभी वेबपैड इनपुट के लिए हल करना अच्छा है, लेकिन उपयोगकर्ता नाम जैसे पहचानकर्ताओं के लिए यह सही होने के लिए और अधिक महत्वपूर्ण हो सकता है।
अंत में, सुनिश्चित करें कि नाम बदलने के लिए चुपचाप बिना किसी चुप छेड़छाड़ के डेटाबेस में फिट होना ठीक है, खासकर यदि आप यूटीएफ -8 बाइट्स के रूप में संग्रहित हैं जो आप बाइट अनुक्रम के माध्यम से आधा रास्ते नहीं छीनना चाहते हैं। उपयोगकर्ता नाम छंटनी सामान्य रूप से एक सुरक्षा समस्या भी हो सकती है।
यदि आप पहचान के अद्वितीय साधन के रूप में उपयोगकर्ता नाम का उपयोग कर रहे हैं, तो आपके पास चिंता करने के लिए बहुत कुछ है: Сhris (एक सिरिलिक ए С के साथ) की रूपरेखा की पहले से ही उल्लिखित समस्या। उचित रूप से संभालने के लिए इनमें से बहुत सारे हैं; या तो ASCII तक सीमित है या उपयोगकर्ताओं की पहचान करने का एक अतिरिक्त माध्यम है। (या परवाह नहीं है, जैसे एसओ नहीं करता; जब मैं आसानी से खुद को क्रिस कह सकता हूं तो मुझे खुद को С -hris कॉल करने की आवश्यकता नहीं है।)
महाकाव्य पद के लिए धन्यवाद :) यह मेरे निलंबन की पुष्टि करता है कि प्रतिबंधों का वैध कारण है। – Chris
मैं उपयोगकर्ता नाम करने के लिए प्रतिबंध जोड़ने में बात कभी नहीं देखा। यदि आपका कोड एसक्यूएल इंजेक्शन हमलों के लिए प्रतिरोधी है तो उन्हें अपनी इच्छानुसार कुछ भी डालने दें।
केवल प्रतिबंध मैं जोड़ना होगा एक अधिकतम लंबाई एक इतना है कि यह एक डीबी तालिका में संग्रहीत किया जा सकता है
उन्हें अपने उपयोगकर्ता नाम में किसी भी यूनिकोड वर्ण का उपयोग करते हैं है। अनुमत वर्णों पर प्रतिबंध जोड़ना शायद लोगों को गैर-असीसी भाषा का उपयोग करके परेशान करेगा।
तो मुझे उपयोगकर्ताओं को उपयोगकर्ता नाम व्यवस्थापक के साथ पंजीकरण करने देना चाहिए? :) इस सवाल के पीछे बिल्कुल बिंदु: डी – Chris
क्यों नहीं। सिर्फ इसलिए कि उपयोगकर्ता नाम "व्यवस्थापक" है, यह उन्हें व्यवस्थापक नहीं बनाता है। उदाहरण के लिए स्टैकओवरफ्लो में 2 व्यवस्थापक हैं जिन्हें "व्यवस्थापक" कहा जाता है और 3 "व्यवस्थापक" कहा जाता है। यदि आपके पास कुछ उपयोगकर्ता नाम हैं जिन्हें आप उपयोग नहीं करना चाहते हैं, तो कोड प्रतिबंध न बनाएं, केवल उपयोगकर्ताओं को स्वयं बनाएं और आप कर चुके हैं। यह एक त्वरित और सरल फिक्स – Glen
भ्रम/गलतियों से बचने के लिए और भी कुछ है। उपयोगकर्ताओं को यह सोचने में गुमराह नहीं किया जाना चाहिए कि एक गैर-व्यवस्थापक एक व्यवस्थापक है, या वे पासवर्ड को रीसेट करने जैसे अनुचित प्रश्नों को निर्देशित कर सकते हैं। सोशल इंजीनियरिंग समग्र सुरक्षा का हिस्सा है, केवल मेरे 2 सेंट। – Chris
उदाहरण के लिए, यदि उपयोगकर्ताओं के पास अपना स्वयं का यूआरएल होगा, तो आप सावधान रहना चाहते हैं कि उपयोगकर्ता नाम "% 41llan" नामक उपयोगकर्ता के साथ "एलन" नामक उपयोगकर्ता के साथ संघर्ष नहीं करता है, जबकि अग्रेषण-स्लैश की समस्याएं समस्याएं पैदा कर सकती हैं। उन बाधाओं के लिए देखो।
"% 41llan" के साथ अच्छा बिंदु। हालांकि उपयोगकर्ताओं को अपने स्वयं के यूआरएल की आवश्यकता नहीं है, मैं सोच रहा हूं कि आप इसे कैसे ठीक करते हैं? – Chris
% 41llan का URL% 2541llan पर सही ढंग से एन्कोड किया जाएगा। यह सिर्फ एक और भागने वाला मुद्दा है, जो SQL या HTML इंजेक्शन के समान है। – bobince
इस पर निर्भर करता है कि आप इसका इलाज कैसे करते हैं। मैं ऐसी साइट पर काम कर रहा हूं जहां मैं "बदसूरत" यूआरएल नहीं चाहता था, इसलिए मैंने बस इस तरह के पात्रों को तोड़ दिया।इससे एक ही यूआरएल वाले दो उपयोगकर्ताओं की समस्या खुलती है, इसलिए आपको यह जांचना होगा कि नए उपयोगकर्ता मौजूदा लोगों के साथ संघर्ष नहीं करते हैं। – Artelius
एसक्यूएल इंजेक्शन सुरक्षा एक जरूरी है, लेकिन यह शायद आपके कोड में होना चाहिए, न कि उपयोगकर्ता नाम प्रतिबंधों में। कुछ पात्रों को निश्चित रूप से बचाना चाहिए, जैसे \,%, आदि
यह किस प्रकार की साइट पर चल रहा है, इस पर होगा, लेकिन मुझे लगता है कि कुछ अश्लील शब्द प्रतिबंध आपकी साइट को और अधिक पेशेवर दिखेंगे। अगर कोई देखता है कि लोगों को उपयोगकर्ता नाम के रूप में "विस्तृत" के साथ जाने की अनुमति है, तो आपकी साइट बचपन में दिखाई देगी। यह किशोरों को आपकी पुस्तक स्टोर आईएमएचओ में रैंपिड चलाने की इजाजत देता है। आपको शायद उससे ज्यादा चुनने की जरूरत नहीं है, हालांकि यह पूरी तरह से आपके ऊपर है।
यह थोड़ा सा विषय है, लेकिन उपयोगकर्ता नाम सलाह का एक और टुकड़ा के रूप में, किसी भी वेबसाइट की एक महान विशेषता उपयोगकर्ताओं को बदलने के लिए अनुमति दे रही है, वे समय के साथ उपयोगकर्ता नाम हैं। आपके पास केवल प्राथमिक कुंजी के रूप में एक संख्या हो सकती है, और उन्हें ऐसा करने की इजाजत मिलती है जिससे बहुत सारी चीजें और लोग नए खाते बना सकते हैं क्योंकि वे अपना उपयोगकर्ता नाम बदलना चाहते हैं। : डी
किसी भी स्वचालित खराब शब्द फ़िल्टर विफलता के लिए बर्बाद हो गया है। आप वास्तव में उस समस्या को बना सकते हैं जिसे आप रोकने की कोशिश कर रहे हैं क्योंकि लोग इसे फ़िल्टर को रोकने के लिए एक गेम पाते हैं। एक सामान्य नियम के रूप में, ब्लैकलिस्ट कभी काम नहीं करते हैं। – rmeador
मुझे यह मानना है कि बुरे शब्द उन चीजों में से एक थे जिनके बाद मैं था। दर्शकों को बड़ा नहीं होने वाला है, लेकिन मैं इसे साफ रखने की कोशिश कर रहा हूं लेकिन बिना अति उत्साही होने के। – Chris
इसके लिए एक फिक्स पंजीकरण की अनुमति देना होगा, लेकिन समीक्षा करने के लिए इसे मॉडरेटर के लिए ध्वजांकित करें। यह उपयोगकर्ता को "स्कन्थोरपे" या नापसंद "विशेषज्ञ एक्सचेंज" पंजीकृत करने की अनुमति देगा, लेकिन फिर भी आपको डोडी नामों को स्थानांतरित करने की अनुमति देता है। वास्तव में डीबी में उपयोगकर्ता नामों के माध्यम से आवधिक (दैनिक) ट्रैवल करना और किसी भी को पसंद नहीं करना आसान है। "विशेषज्ञों के आदान-प्रदान" के लिए – Glen
ध्यान रखें कि आपको स्क्रिप्ट और एचटीएमएल इंजेक्शन के बारे में चिंता करने की भी आवश्यकता है , सिर्फ एसक्यूएल इंजेक्शन नहीं। लेकिन यदि आप इसे प्रदर्शित करने से पहले हमेशा उपयोगकर्ता नाम एन्कोड कर रहे हैं, जैसा कि आप होना चाहिए, तो यह एक गैर-मुद्दा है। – rmeador