मैं एमवीसी को एक एएसपी.NET एप्लिकेशन पोर्ट कर रहा हूं और एक ऑटिनेटेड उपयोगकर्ता से संबंधित दो वस्तुओं को स्टोर करने की आवश्यकता है: भूमिकाओं की एक सूची और दृश्य आइटम आईडी की एक सूची, यह निर्धारित करने के लिए कि उपयोगकर्ता क्या देख सकता है या नहीं देख सकता है।उपयोगकर्ता भूमिकाएं - सत्र में क्यों स्टोर नहीं करते?
हमने अतीत में एक वेब सेवा के साथ डब्ल्यूएसई का उपयोग किया है और इससे चीजों को अविश्वसनीय रूप से जटिल और असंभव तरीके से डीबग करना असंभव हो गया है। अब हम उस वेब सेवा को मिट रहे हैं जो मैं सत्र में इन चीजों को स्टोर करने के लिए समाधान को काफी सरल बनाने के लिए उत्सुक दिख रहा था। एक सहयोगी ने भूमिकाओं और सदस्यता प्रदाताओं का उपयोग करने का सुझाव दिया लेकिन इस पर ध्यान देने पर मुझे कई समस्याएं मिलीं:
ए) यह डब्ल्यूएसई के समान लेकिन अलग-अलग समस्याओं से ग्रस्त है जिसमें इसे बहुत ही सीमित तरीके से उपयोग किया जाना चाहिए परीक्षण लिखने के लिए भी मुश्किल है;
बी) RolesProvider के लिए एकमात्र कैशिंग विकल्प कुकीज़ पर आधारित है जिसे हमने सुरक्षा आधार पर खारिज कर दिया है;
सी) इसमें जटिलताओं और अतिरिक्त अवांछित सामान का कोई अंत नहीं है;
हम सब कुछ करना चाहते हैं, संक्षेप में, उपयोगकर्ता के सत्र में दो स्ट्रिंग चर या एक सुरक्षित तरीके से समतुल्य कुछ स्टोर करते हैं और जब हमें आवश्यकता होती है तो उन्हें संदर्भित करें। क्या एक दस मिनट काम अब तक जांच के कई दिन ले लिया है और समस्या को हम अब पता चला है कि सत्र आईडी जाहिरा तौर पर नाटक किया जा सकता है मिश्रित करने के लिए हो सकता है, को देखने के
http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/
मैं बाईं सोच है कर रहा हूँ लगता है यह बहुत आसान काम करने का कोई आसान तरीका नहीं है, लेकिन मुझे विश्वास करना असंभव लगता है।
किसी को भी कर सकते हैं:
क) कैसे ASP.NET MVC सत्र सुरक्षित बनाने के लिए पर सरल जानकारी प्रदान करते हैं, जैसा कि मैंने हमेशा माना है कि वे कर रहे थे?
बी) ऊपर वर्णित अनुसार एक जटिल दुःस्वप्न को प्रतिस्थापित किए बिना उपयोगकर्ता की भूमिकाओं में लॉग इन करने के लिए इन दो स्ट्रिंग चर को स्टोर करने का एक और आसान तरीका सुझाता है?
धन्यवाद।
मुझे कहना चाहिए था, हम एसएसएल का उपयोग करते हैं, इसलिए कोई समस्या नहीं है। इसके अलावा हमें सत्रों को पुनः प्राप्त करने में कोई समस्या नहीं है, इसलिए मैं इसके बारे में चिंतित नहीं हूं। – Phil
सत्र चर के लिए पूरी तरह से सुरक्षित होने के कारण: मैंने जो सोचा था, लेकिन मैंने जो आलेख लिंक किया है, वह सुझाव देता है कि कोई उपयोगकर्ता मौजूदा सत्र में शामिल होने के लिए कई तरीकों से चाल कर सकता है, और इस प्रकार इसे प्रमाणीकृत उपयोगकर्ता के साथ साझा कर सकता है जो बाद में लॉग इन करता है और इस प्रकार दूसरे व्यक्ति द्वारा उपयोग किए जाने के लिए अपनी सभी भूमिकाएं संग्रहीत करता है। इसका स्पष्ट समाधान सत्र में आईपी पते को स्टोर करना था और हर बार इसे जांचना था, लेकिन जाहिर है कि अनुरोध में नकली भी आसान है। जबकि मैं मौजूदा सत्र कार्य में शामिल होने के – Phil
के सुझाए गए तरीकों में से कोई भी बनाने में असमर्थ रहा हूं, मैं जानना चाहूंगा कि वे हैकर के रूप में मेरे स्पष्ट रूप से कम कौशल पर भरोसा करने के बजाय क्यों नहीं। अगर मुझे उस पर भरोसा था तो मुझे लगता है कि हमने समस्या हल कर ली है लेकिन अब तक मैं नहीं हूं। – Phil