जहां कॉल स्टैक में भूमिका जांच की जानी चाहिए?

Question

मेरे विशिष्ट ऐप में, उपयोगकर्ता एएसपीएक्स पेज में एक बटन पर क्लिक करता है, एक सी # बिजनेस ऑब्जेक्ट को आमंत्रित करता है, फिर संग्रहीत प्रक्रिया चलाता है।

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

Page_Load() 
{ 
    if(p.IsInRole("Managers")) //or equivalent attribute 
    { 
    AddAccount.Visible =true; 
    } 
} 

AddAccount_OnClick() 
{ 
    if(p.IsInRole("Managers")) //or equivalent attribute 
    { 
    //Add the account 
    Account.Add(...); //and maybe another role check... 
    } 
} 

-- TSQL doesn't understand .NET authorization, this call is in a 'trusted' subsystem 
create proc Add_Account @user, @account_name 
If @user in (Select user from role_table where role='manager') 
-- Add the account 

Answer 1

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

यह तर्क डेटा स्रोत में सुरक्षा जांच को कॉल करने के लिए कॉल करेगा, अगर यह इसका समर्थन करता है (जैसे आपके पसंदीदा आरडीबीएमएस), या डेटा एक्सेस लेयर।

हालांकि, कुछ सुरक्षा बाधाओं में व्यावसायिक तर्क की गंध है; जैसे "यदि उपयोगकर्ता इस भूमिका में है और इन विनिर्देशों को पूरा करने वाले डेटा को संशोधित करने का प्रयास कर रहा है, तो ऑपरेशन की अनुमति दी जानी चाहिए, अन्यथा नहीं"। यह मुझे नीति की तरह लगता है, और ऐसा कुछ जो कि एक अलग नियम इंजन के बिजनेस लॉजिक लेयर में है।

I wrote about something similar in the context of WCF some time ago।

Answer 2

मैं वास्तव में संभावित खतरनाक/संवेदनशील सामान प्रदर्शन व्यापार वस्तुओं में भूमिका पहुँच चेकों जगह होगा:

यहाँ मेरे सवाल का वर्णन करने के लिए एक विशिष्ट कॉल स्टैक है।

अपने पृष्ठ लोड में भूमिका जांच जोड़ना और बटन क्लिक ईवेंट अपर्याप्त, IMHO होगा। इसके अलावा, यदि आप पृष्ठ की रक्षा करने जा रहे हैं, तो अपने web.config में घोषणात्मक स्थान निर्देशों का उपयोग करके पृष्ठ की रक्षा करें ... उदा। अपने सभी "व्यवस्थापक" पृष्ठों को एक अलग फ़ोल्डर में रखें और घोषणात्मक रूप से पूरे फ़ोल्डर की रक्षा करें।

लेकिन, आपको हमेशा कम से कम अपने व्यापार ऑब्जेक्ट विधियों पर चेक रखना चाहिए।

Answer 3

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

private void MyBypassingCall() 
{ 
    if(myLogic) 
    { 
    AddAccount_OnClick(); 
    } 
} 

तो Page_Load पर डालने पर्याप्त नहीं है। आपको PrincipalPermissionAttribute के साथ विधि को सजाने की भी जांच करनी चाहिए। यह बहुत सारे कोड पर कटौती करता है।

Answer 4

व्यावसायिक वस्तुएं।

लेकिन निर्माण समय पर। प्रत्येक उदाहरण को एक बहुत ही विशिष्ट भूमिका निभाने दें।

संपादित करें: इस तरह से अधिक संक्षिप्त।

Answer 5

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

Answer 6

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

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

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