एमवीसी के साथ यूआरएल मैनिपुलेशन हमलों को रोकना?

Question

यूआरएल हेरफेर को रोकने के लिए कोई अच्छी रणनीतियां, कोड स्निपेट आदि?

उदाहरण के लिए मेरे पास यह यूआरएल है, http://localhost/profile/edit/5 आईडी को आसानी से कुछ भी बदला जा सकता है और इस प्रकार लोग प्रोफ़ाइल को संपादित कर सकते हैं जिन्हें वे भी नहीं मानते हैं।

यहाँ कुछ विचारों मैं के बारे में सोचा है लेकिन वे सब वहाँ कमियां हैं:

1. GUID प्राथमिक कुंजी का उपयोग करने के लिए अपने सिस्टम को बदलें - यह लगभग असंभव कुंजी का अनुमान लगाना आसान हो गया है - लेकिन लोग अभी भी ले जा सकते हैं ऐप के एक हिस्से से GUID और इसे बाद में किसी अन्य यूआरएल में उपयोग करें।

2. कुंजी स्टोर करने के लिए टेम्पडडेटा का उपयोग करें - यूआरएल को बाद में के आसपास भेजा जा रहा है।

3. पृष्ठ प्रदर्शित करने से पहले नियंत्रक में चेक करें - इसका मतलब है कि आप संचालन की जांच के लिए हर जगह 'adminy' कोड करना है।

क्या करना सबसे अच्छा काम है? इनमें से एक या कुछ और?

Answer 1

संख्या 3 करना सही काम है। सर्वर-साइड सुरक्षा सत्यापन हमेशा आपको चाहिए, क्योंकि यह वह तंत्र है जिसे आप पूरी तरह से नियंत्रित करते हैं और भरोसा कर सकते हैं।

संख्या 1 अस्पष्टता से सुरक्षा है, और यदि कोई गलती से कहीं भी अपना यूआरएल पोस्ट करता है (जैसे लोग अक्सर लिंक-पेस्ट कॉपी करते समय सत्र-आईडी के साथ करते हैं), तो आपकी "सुरक्षा" टूट जाती है।

संख्या 2 एक कमजोर सुरक्षा की तरह लगता है - यदि आप परेशानी से गुजरते हैं, तो बेहतर सुरक्षा लागू करें। इससे लोगों को पृष्ठ को बुकमार्क करने की अनुमति मिलती है।

Answer 2

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

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

Answer 3

अंतर्निहित कार्यक्षमता की रक्षा के लिए आपको अपने यूआरएल "मैनिपुलेशन-सबूत" नहीं बनाना चाहिए। इसके अलावा: अधिकांश वेबसाइटें उदाहरण के लिए http://stackoverflow.com/questions/741653/preventing-url-manipulation-attacks-with-mvc जैसे URL को अधिक पठनीय बनाती हैं - obfuscation पीछे एक कदम होगा।

इसके बजाय अपने नियंत्रकों के भीतर अनुमतियों की जांच करें और यदि उपयोगकर्ता को प्रोफ़ाइल संपादित करने की अनुमति नहीं है तो अपवाद बढ़ाएं 6. यदि आप हर जगह "चेक" नहीं चाहते हैं, तो आप उन्हें ActionFilter में डाल सकते हैं, या Profile.FindById(id) के बजाय CurrentUser.FindProfileToEditById(profileId) जैसे कुछ सहायक विधि बनाएं (जो कार्रवाई की अनुमति नहीं है तो अपवाद फेंकता है)।

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

Answer 4

मैं भूमिका-और मालिक-आधारित पहुंच नियंत्रण को लागू करने के लिए कस्टम प्राधिकरण फ़िल्टर का उपयोग करता हूं। मानक प्रमाणीकरण फ़िल्टर आपको नामांकित भूमिकाओं या उपयोगकर्ताओं को निर्दिष्ट करने की अनुमति देगा जिनके पास एक क्रिया तक पहुंच हो सकती है। मैंने इसे विस्तारित करने के लिए इसे विस्तारित करने के लिए विस्तारित किया है कि वर्तमान उपयोगकर्ता के पास पहुंच हो सकती है यदि वे डेटा के "स्वामी" हैं।मेरे पास दो अतिरिक्त फ़िल्टर हैं, RoleOrOwnerAuthorizationFilter और RoleOrOwnerAssociatedAuthorizationFilter। पहला चेक करता है कि रूटडेटा में पारित कॉन्फ़िगर करने योग्य पैरामीटर (आमतौर पर id) मेरे उपयोगकर्ता तालिका में वर्तमान उपयोगकर्ता की आईडी है या यदि वर्तमान उपयोगकर्ता किसी भी सूचीबद्ध भूमिका में है। यदि ऐसा है तो चेक सफल होता है, यदि नहीं, तो यह एक प्राधिकरण त्रुटि दृश्य देता है।

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