पहुँच नियंत्रण परत से पहले सत्यापन परत होना ठीक है

Question

मैं एक एपीआई स्ट्रैचर्ड वेब एप्लिकेशन बना रहा हूं और इस एप्लिकेशन में हमारी अलग-अलग परतें हैं जो अपना काम कर रही हैं।

पहली परत मान्यकरण परत है जो उपयोगकर्ता इनपुट को मान्य करती है और यदि यह सत्यापन पास करता है तो हम इसे दूसरी परत तक ले जाते हैं (जो एक्सेस कंट्रोल लेयर है) अन्यथा त्रुटि संदेश लौटाएं

दूसरी परत एक्सेस कंट्रोल है जो यह जांचता है कि उपयोगकर्ता को उस कार्य को करने की अनुमति है जिसे वह प्रदर्शन करना चाहता है, यदि उपयोगकर्ता की अनुमति है तो वह अनुरोध को अगली परत पर ले जाता है अन्यथा त्रुटि संदेश लौटाता है

थर्ड लेयर कंट्रोलर लेयर है जहां हमारे पास आवेदन का तर्क है

मेरा प्रश्न यह है कि क्या अभिगम नियंत्रण से पहले सत्यापन परत होना ठीक है? क्या होगा यदि उपयोगकर्ता किसी ऐसे कार्य को करने की कोशिश कर रहा है जिसे उपयोगकर्ता की अनुमति नहीं है और हम सत्यापन त्रुटि संदेश भेज रहे हैं? उपयोगकर्ता एक समापन बिंदु के लिए अनुरोध भेज रहा होगा और सत्यापन परत के साथ बात कर रहा होगा और एक बार जब यह सत्यापन पारित हो जाएगा, तभी वह संदेश देखेगाYou can't access this!

यह मुझे अजीब लगता है इसलिए क्या यह इस तरह ठीक है या बुनियादी ढांचे में मेरे अन्य विकल्प क्या हो सकते हैं?

Comments

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

— ग्रेग बरगार्ड

मेरे मामले में वही एक्सेस कंट्रोल मिडिलवेयर के लिए जाता है, यह एक संसाधन की जांच करता है और देखता है कि क्या संसाधन का प्रकार उपयोगकर्ता द्वारा सुलभ है, अगर यह सुलभ है तो मैं एक्सेस की अनुमति देता हूं अन्यथा नहीं

— मुहम्मद

यह सच है। DDoS के दौरान वह परत अभी भी आपके डेटा स्टोर से टकराएगी। उस लेयर को चलाने से पहले आप मान्यताओं और एक्सेस कंट्रोल के लिए अपने डेटा स्टोर पर नहीं पहुंचेंगे - आप इसे एक्सेस कंट्रोल के लिए मारेंगे। यह सुनामी के आकार को कम करता है, लेकिन इसे समुद्र तट से टकराने से नहीं रोकता है। यह आपको या आपके सर्वर टीम को पूरे सिस्टम से टकरा जाने से पहले किसी हमले का जवाब देने के लिए लड़ने का मौका देता है।

— ग्रेग बरगार्ड

एक व्यावहारिक दृष्टिकोण से, पहुँच नियंत्रण वैसे भी सत्यापन से पहले आना चाहिए - यदि आप पहली जगह में अनुरोध का उपयोग नहीं कर सकते हैं तो आप किसी उपयोगकर्ता के अनुरोध की शुद्धता को कैसे मान्य करेंगे?

— ज़िबोबोज़

@ZIBBZ सत्यापन सरल है अगर उपयोगकर्ता सही स्कीमा भेज रहा है, तो यह जाँचना आसान है कि पैरामीटर जो पूर्णांक होना चाहिए पूर्णांक या कुछ और है

— मुहम्मद

Answer 1

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

अनधिकृत उपयोगकर्ता के लिए एकमात्र सुरक्षित प्रतिक्रिया "पहुंच अस्वीकृत" है। यदि कभी-कभी प्रतिक्रिया "बुरा अनुरोध" है और अन्य बार "एक्सेस अस्वीकृत" है, तो आप एक अनधिकृत उपयोगकर्ता को जानकारी भेज रहे हैं।

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

Comments

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

— किलन फ़ॉथ

@caleth वास्तव में यह आपको यह बताने की अनुमति नहीं देगा कि एक निश्चित दस्तावेज़ सिस्टम में है या नहीं, इस प्रकार की जानकारी केवल तब दी जाती है जब आप कंट्रोलर लेयर तक पहुँचते हैं। सत्यापन केवल स्कीमा की जांच करते हैं, यह डेटाबेस तक नहीं पहुंचता है - केवल एक्सेस कंट्रोल और गहरी परतें डेटाबेस एक्सेस का उपयोग करती हैं। इसके अलावा, एक्सेस कंट्रोल लेयर आपको केवल वही सामान दिखाती है, जबकि कोई संसाधन मौजूद है या नहीं। एकमात्र समझौता करने वाली बात स्कीमा है जो मैं सोच रहा हूं कि क्या यह ठीक है या नहीं

— मुहम्मद

@ कैलाथ आप अपनी अंतिम टिप्पणी पर विस्तार से बता सकते हैं? मैं यह नहीं देखता कि ओप्स की टिप्पणी पर यह मामला कैसा है। अगर किसी स्कीमा को सार्वजनिक रूप से प्रलेखित किया जाता है तो किसी भी मामले में केवल सूचना वापस भेज दी जाती है।

— रोटेम

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

— कामिल दकरी

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

— mfrankli

Answer 2

वैसे, सत्यापन कई प्रकार के होते हैं:

1. सस्ता बुनियादी विवेक-जाँच, जो यह पुष्टि करता है कि अनुरोध स्पष्ट रूप से विकृत नहीं है।

   यह आमतौर पर कम से कम आंशिक रूप से डुप्लिकेट क्लाइंट-साइड है, व्यर्थ राउंड-ट्रिप से बचने के लिए।

   वैसे भी, यह चीजों को आसान और कम त्रुटि वाले बनाने के लिए एक्सेस-कंट्रोल से पहले किया जाना चाहिए, क्योंकि यह किसी भी सूचना-रिसाव का जोखिम नहीं उठाता है।

2. अधिक महंगी मान्यता जो अभी भी किसी भी संरक्षित एप्लिकेशन-डेटा पर निर्भर नहीं करती है।

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

   यदि पहले चरण के सभी सत्यापन को डुप्लिकेट किया गया है, तो यह इस क्लाइंट-साइड के डुप्लिकेट भागों को भी समझ सकता है।

3. संरक्षित एप्लिकेशन-डेटा के आधार पर अतिरिक्त सत्यापन।

   पहुँच-नियंत्रण से पहले ऐसा करना स्पष्ट रूप से सूचना-लीक का जोखिम रखता है। इस प्रकार, पहले पहुंच-नियंत्रण करते हैं।

Comments

यह आपके एपीआई तक पहुंचने से पहले ही अपने बुनियादी ढांचे में एक नीति प्रवर्तन बिंदु पर पहुंच नियंत्रण करने के लिए आदर्श होगा। सत्यापन का एक मूल स्थैतिक सेट (Ex: OpenAPI) पहले होगा, उसके बाद गहरा व्यापार सत्यापन होगा। यहां तक ​​कि कुछ स्थैतिक सत्यापन भी संभावित रूप से आपके ऐप की उपलब्धता पर प्रभाव डाल सकते हैं- पूर्व ReDOS हमले।

— felickz

@felickz: हाँ, DOS हमले प्रमाणीकरण के बाद सत्यापन को स्थगित करने का एक वैध कारण हैं। यह एक संतुलन-कार्य है। वैसे भी, मैंने अपने पहले बिंदु को ठीक से विभाजित करने के लिए विभाजित किया है।

— Deduplicator

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

— रेयान

@ लाइरियन: वह सब कारण है जो एक्सेस-कंट्रोल से पहले संभावित रूप से मान्य है जो संरक्षित एप्लिकेशन डेटा पर बिल्कुल भी निर्भर नहीं करता है।

— डिडुप्लिकेटर

Answer 3

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

ओटोह, जैसा कि कैलथ और ग्रेग ने उल्लेख किया है, अभिगम नियंत्रण से पहले अधिक व्यापक सत्यापन करना एक संभावित सुरक्षा जोखिम है।

तो कठिन नियम हैं

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

इन दोनों नियमों का पालन करने का मतलब हो सकता है कि आपके पास एक्सेस कंट्रोल से पहले और कुछ के बाद कुछ सत्यापन होना चाहिए।

Comments

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

— एसडी

यह मानते हैं कि उत्तर सार्वजनिक हैं। मैंने बहुत सारी एपीआई कहने की हिम्मत की है, जिससे आपको डेटा के साथ प्रमाणीकरण भी नहीं मिलेगा।

— टॉम टॉम

Answer 4

इनपुट को मान्य करने के बाद एक 'अस्वीकृत' प्राप्त करने की संभावित हताशा के अलावा ; यह भी ध्यान रखें कि सत्यापन परत, जब तक कि यह बहुत ही सरल न हो, हमेशा नियंत्रक से जानकारी की आवश्यकता हो सकती है । इसे ध्यान में रखते हुए, मेरा मानना ​​है कि एक्सेस कंट्रोल के पीछे स्थिति सत्यापन , नियंत्रक के करीब अधिक समझ में आता है।

Answer 5

यह इस बात पर निर्भर करता है कि आप सत्यापन परत से क्या मतलब रखते हैं - यदि इसके द्वारा आप केवल अनुरोध के वाक्यविन्यास की जाँच कर रहे हैं, तो यह सुरक्षित है और आपको कुछ भी करना है। यदि आपका 'सत्यापन' ऐसी किसी भी जानकारी का उपयोग करता है जो एक अप्रभावित उपयोगकर्ता के पास नहीं है, तो यह अब सुरक्षित नहीं है।

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

पवित्रता जाँचकर्ता के लिए एक पवित्रता की जाँच के रूप में, यह वास्तव में आपके कोड के किसी भी हिस्से पर किसी भी निर्भरता को कम नहीं करना चाहिए और पाइप लाइन को नीचे रखना चाहिए और अपने स्वयं के पैकेज में अलग होना चाहिए जो बिना किसी समस्या के (सार्वजनिक कानूनी मुद्दों के अलावा) सार्वजनिक रूप से युवा होना चाहिए। । यदि आप ऐसा नहीं कर सकते हैं, तो आपकी 'सत्यापन परत' बहुत कुछ कर रही है (या आपका कोडबेस गड़बड़ है)।

Answer 6

नहीं, यह ठीक नहीं है।

यदि आपकी मान्यता परत में बग है तो यह सुरक्षा परत को बायपास कर सकता है।

सुरक्षा को व्यावसायिक आवश्यकताओं के हिस्से के रूप में मानना ​​एक सामान्य गलती है। "केवल बिक्री भूमिका वाले उपयोगकर्ता, त्रैमासिक आंकड़ों को देखने में सक्षम होना चाहिए" एक व्यापार नियम की तरह लगता है।

लेकिन अगर आप सुरक्षित होना चाहते हैं, तो आपको इस तरह के नियम को पढ़ना होगा जैसे कि "केवल उपयोगकर्ता ही बिक्री भूमिका में हैं, इस एंडपॉइंट पर कोड चलाने में सक्षम होना चाहिए" आपने यह सुनिश्चित कर लिया है कि आपके सर्वर को हमेशा "एक्सेस निषेध" से पहले ही रिटर्न करना होगा। किसी भी तरह का कोड आपने सर्वर पर लिखा या फाइल किया है।