क्या मुझे अपेक्षित अपेक्षा से अधिक URL को अस्वीकार कर देना चाहिए?

Question

मैं एक एप्लीकेशन विकसित कर रहा हूं, और www.example.com/some_url/some_parameter/some_keyword प्रारूप में यूआरएल है। मुझे डिज़ाइन द्वारा पता है कि अधिकतम URL है कि इन यूआरएल (और अभी भी वैध हो) होगा। क्या मुझे बफर ओवरफ़्लो/इंजेक्शन हमलों से बचाने के लिए प्रत्येक अनुरोध के साथ यूआरएल लंबाई मान्य करनी चाहिए? मेरा मानना ​​है कि यह एक स्पष्ट हां है लेकिन मैं सुरक्षा विशेषज्ञ नहीं हूं इसलिए शायद मुझे कुछ याद आ रहा है।

Answer 1

यदि आप उस इनपुट की अपेक्षा नहीं कर रहे हैं, तो इसे अस्वीकार करें।

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

Answer 2

आप कैसे सुनिश्चित हैं कि सभी एन से अधिक URL अमान्य है? यदि आप सुनिश्चित हो सकते हैं, तो इसे सैनिटी चेक के रूप में सीमित करने के लिए इसे चोट पहुंचाना नहीं चाहिए - लेकिन इस मूर्ख को आपको यह सोचने में न दें कि आपने शोषण की कक्षा को रोका है।

Answer 3

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

Answer 4

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

इसके अलावा, यह भविष्य का सबूत नहीं है।

Answer 5

हां। यदि यह बहुत लंबा है और आप निश्चित हैं तो इसे जल्द से जल्द अस्वीकार कर दें। यदि आप इसे अपने आवेदन तक पहुंचने से पहले अस्वीकार कर सकते हैं (उदाहरण के लिए IISLockdown यह करेगा)।

हालांकि चरित्र एन्कोडिंग के लिए खाते को याद रखें।

Answer 6

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

Answer 7

क्या आप जानते मान्य URL को तो से अधिक एन बाइट्स यह एक अच्छा तरीका जल्दी से भी बहुत प्रयास के बिना क्रॉस साइट स्क्रिप्टिंग-प्रयास को अस्वीकार करने की तरह लगता है नहीं किया जा सकता है।

Answer 8

केवल एक चीज जो मैं देख सकता हूं जो समस्याएं पैदा कर सकती है वह है कि आज आपका यूआरएल एन से अधिक नहीं होगा, आप गारंटी नहीं दे सकते कि यह हमेशा के लिए मामला नहीं होगा। और एक वर्ष में, जब आप एक यूआरएल लंबाई में एन + वाई होने की अनुमति देने के लिए एक संपादन करने के लिए वापस जाते हैं, तो आप यूआरएल अस्वीकृति कोड को संशोधित करना भूल सकते हैं।

आप हमेशा उपयोग करने से पहले यूआरएल पैरामीटर को सत्यापित करने से बेहतर रहेंगे।

Answer 9

मान्य URL लंबाई की तुलना में अनुरोध में क्या मान्य करना बेहतर है।

भविष्य में आपकी ज़रूरतें बदल सकती हैं, जिस बिंदु पर आपको यूआरएल लंबाई सत्यापन को हटाने या बदलने की संभावना है, संभवतः बग पेश करना।

यदि यह एक सिद्ध सुरक्षा भेद्यता के रूप में समाप्त होता है, तो आप इसे कार्यान्वित कर सकते हैं।

Answer 10

गहराई में रक्षा एक अच्छा सिद्धांत है। लेकिन झूठी सुरक्षा उपायों का एक बुरा सिद्धांत है। अंतर बहुत सारे विवरणों पर निर्भर करता है।

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

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

Answer 11

ठीक है, मान लें कि ऐसा एन मौजूद है। जैसा कि वनबीन ने इंगित किया है, एन विकृत से अधिक लंबा एक विकृत यूआरएल अन्य इनपुट सत्यापन द्वारा अस्वीकार कर दिया जाएगा। हालांकि, मेरी आंखों में, यह सोचने के लिए एक पूरी नई चीज़ खुलती है:

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

Answer 12

सफारी, इंटरनेट एक्सप्लोरर, और फ़ायरफ़ॉक्स में अलग-अलग अधिकतम लंबाई होती है जो इसे स्वीकार करती है।

मैं वोट तीनों में से सबसे कम के लिए जाता हूं।

http://www.boutell.com/newfaq/misc/urllength.html

लिंक से खींचा -

"माइक्रोसॉफ्ट इंटरनेट एक्सप्लोरर (ब्राउज़र) - 2,083 पात्रों

फ़ायरफ़ॉक्स (ब्राउज़र) - 65,536 के बाद वर्ण, स्थान पट्टी प्रदर्शित नहीं होता विंडोज फ़ायरफ़ॉक्स 1.5.x में यूआरएल। हालांकि, लंबे यूआरएल काम करेंगे। मैंने 100,000 अक्षरों के बाद परीक्षण बंद कर दिया।

सफारी (ब्राउज़र) - कम से कम 80,000 वर्ण काम करेंगे। "

Answer 13

ओह मेरे, बहुत सारे जवाब, बहुत अच्छे अंक, इसलिए फैल गए, इसलिए मुझे यह सब समेकित करने का प्रयास करें। टीएल; डी आईएमओ, यह बहुत कम स्तर पर एप्लिकेशन लेयर कोड के लिए चिंता का विषय है।

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

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

ठीक है, स्ट्रिंग लंबाई के आधार पर केवल अस्वीकार करने के बारे में क्या? इस पर प्रमुख ड्रॉ सुरक्षा की झूठी भावना के लिए संभावित है। ऐसा कहने के लिए, कोड के कुछ क्षेत्रों को 'मैला' हो सकता है और उन बहुत से शोषणों के प्रति संवेदनशील हो सकता है जिन्हें आप टालने की कोशिश कर रहे हैं। आपको यह सुनिश्चित करने के लिए सावधान रहना होगा कि यह 'वैश्विक' सीमा वास्तव में पर्याप्त है, लेकिन आपके यूआरआई प्रारूप पर विचार करने के बाद, आप उन 'पार्ट्स' रिपोर्ट को वापस ले सकते हैं जो उनकी अधिकतम लंबाई और केंद्रीय लंबाई की जांच (दोनों के लिए पूरी स्ट्रिंग, और इसके घटक); कम से कम इस तरह, यदि एक भाग को लंबी स्ट्रिंग की अनुमति देने की आवश्यकता है, तो परिवर्तन को संभालना आसान है।

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

किसी कारण से, आपको यह नहीं लगता कि आप किस भाषा का उपयोग कर रहे हैं। जावा या पायथन जैसे उच्च स्तरीय भाषाओं में 'वेब सामान' से निपटने के लिए कुछ बहुत अच्छी पुस्तकालय हैं। जावा आपको यूआरआई के लिए पैटर्न निर्दिष्ट करने देगा, जिसमें उस पैटर्न के लिए रेगेक्स के उपयोग शामिल हैं, इसलिए यदि आप यूआरएल में कोई नाम चाहते हैं, तो आपके पास पैरामीटर को 100 अक्षरों तक सीमित करने के लिए @Path("/person/(.{0..100}") जैसे कुछ हो सकता है। मुझे आश्चर्य होगा कि रूबी या पायथन की पसंद बराबर नहीं थी, वे खुद को अच्छी 'वेबबी' भाषाओं के रूप में प्रचारित करना पसंद करते हैं।

अंत में, लंबाई के बावजूद, कई चीजें हैं जिन्हें आपको सत्यापित करने की आवश्यकता होगी, केवल लंबाई नहीं। यूआरआई की लंबाई के बारे में चिंता करने के कारण बफर ओवरफ्लो बहुत कम स्तर की बात है, और इसे बहुत सामान्य होने की आवश्यकता होगी, यानी किसी भी अनुरोध को संभालने की आवश्यकता है, यहां तक ​​कि 1 जीबी यूआरआई के साथ भी संभावित रूप से; ध्यान दें मैंने कहा 'इसे' संभाल 'नहीं है, इसे स्वीकार करें इसे एप्लिकेशन परत तक पास करें', यह उस निम्न स्तर पर इसे अस्वीकार कर सकता है, सिस्टम सिस्टम की घटनाओं को भी ट्रिगर कर सकता है।