क्या एएसपी.नेट में सिक्योरस्ट्रिंग का उपयोग करने का कोई फायदा है?

Question

यदि मैं सही ढंग से समझता हूं, तो यह स्मृति के सादे पाठ को बाहर रखने के लिए है, ताकि ऐप मेमोरी, कचरा ढेर, या डिस्क पर पिक्चर मेमोरी पर गूढ़ हमलों के खिलाफ सुरक्षित हो। सिक्योरस्ट्रिंग को अप्रबंधित बाइट्स खिलाया जाता है और एक समय में एक अप्रबंधित बाइट खाया जाता है - तब स्ट्रिंग को स्मृति से मिटा दिया जाता है। (अगर मैं रास्ता बंद कर दूं तो मुझे सही करें!)

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

इस सिक्योरस्टिंग के साथ कुछ भी करने के लिए मुझे एक एपीआई चाहिए जो अप्रबंधित तारों को लेता है - इसलिए ऐसा लगता है कि मैं एक संग्रहित प्रो पैरामीटर या अन्य चीज़ों के लिए सुरक्षित स्ट्रिंग का उपयोग नहीं कर सकता।

क्या मैं यह गलत कर रहा हूं या क्या यह सिक्योरस्ट्रिंग का उपयोग करने की कोशिश करने के लिए मूर्खतापूर्ण है और असुरक्षित स्ट्रिंग की असीमित स्ट्रिंग की प्रतिलिपि नहीं है?

ओएथ या विंडोज ऑथ पर स्विच करना एक विकल्प नहीं है।

Answer 1

जैसा कि आपने सही ढंग से कटौती की है, और अन्य पहले से ही उल्लेख किए गए हैं, एएसपी.NET फॉर्म से आने वाले सुरक्षा-संवेदनशील डेटा को संग्रहीत करने के लिए SecureString का उपयोग करने में थोड़ा समझ नहीं आता है, क्योंकि वह डेटा पहले से ही सादा पाठ में स्मृति में मौजूद है।

अन्य परिदृश्य हैं, हालांकि, जहां SecureString का उपयोग अनुशंसित है, क्योंकि संवेदनशील डेटा प्रोग्राम द्वारा स्वयं बनाया गया है और इसके साथ काम करने के बाद स्मृति में नहीं रहना चाहिए। उदाहरण के लिए, प्रोग्रामेटिक रूप से एक SharePoint साइट बनाना, या एक सिस्टम से दूसरे सिस्टम में प्रमाणीकरण प्रमाण-पत्र स्थानांतरित करना।

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

char secret[512]; 
generate_secret(secret, sizeof(secret)); 
do_something_with(secret); 
memset(secret, 0, sizeof(secret)); 
// Secret data is now gone. 

इस तरह के एक दृष्टिकोण में कामयाब रहे तार के साथ संभव नहीं है, जिसका मुख्य कारण:: यह ढेर पर आवंटित किया जा सकता है और जैसे ही कार्यक्रम किया गया था इसे प्रयोग को मंजूरी दे दी

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

SecureString की कोशिश करता परिवर्तनशील और प्रयोज्य द्वारा किया जा रहा है कि समस्या को हल करने, जो एक लिखने के लिए अनुमति देता है:

using (SecureString secret = new SecureString()) { 
    GenerateSecret(secret); 
    secret.MakeReadOnly(); 
    DoSomethingWith(secret); 
} 
// Secret data is now gone. 

Answer 2

मुझे लगता है कि आपके पास इसकी मूल बातें हैं। सिक्योरस्टिंग क्लाइंट साइड पर होने के दृष्टिकोण से डिज़ाइन किया गया है। तो एक डब्ल्यूपीएफ/विनफॉर्म ऐप (और शायद सिल्वरलाइट, अगर यह वहां है तो याद नहीं किया जा सकता है) यह सर्वर साइड ऐप के लिए बहुत अधिक है, स्ट्रिंग को संभालने वाला पहला नहीं होने के कारण।

Answer 3

सिक्योरस्टिंग का उपयोग सिस्टम के बीच सीधी कॉल के लिए नेटवर्क प्रमाण-पत्र आवंटित करने के लिए सबसे अच्छा होता है। यह वेब क्षेत्र में दिया गया है कि यदि क्रेडेंशियल वेब के माध्यम से आया है कि यह कहीं सादे टेक्स्ट में है, लेकिन यदि आपको मानक क्रेडेंशियल कॉल (FTP, निर्देशिका सेवाएं, आदि) के माध्यम से उस क्रेडेंशियल को वापस भेजना है, तो SecureString का उपयोग करना एक गुजरने की विधि के रूप में चोट नहीं है। जबकि आप सही हैं कि स्ट्रिंग पहले से ही आपके सर्वर सिस्टम पर सादा पाठ में है, आप कम से कम सिस्टम के बीच पदचिह्न को कम कर सकते हैं। यदि आप केवल स्थानीय रूप से इस पासवर्ड का उपयोग कर रहे हैं, तो मैं सहमत होगा कि सिक्योरस्ट्रिंग शायद बहुत जरूरी नहीं है।

अच्छी सुरक्षा आदतें, हालांकि, वास्तव में समय बर्बाद नहीं होती हैं।

Answer 4

अगर मैं गलत नहीं हूँ, आप स्ट्रिंग से बाहर रखने के लिए इनपुट निम्नलिखित समाधान का उपयोग कर सकते CLR का प्रबंधन: Web API: how to access multipart form values when using MultipartMemoryStreamProvider?

केवल ReadAsByteArrayAsync() के रूप में ExecutePostProcessingAsync (..) विधि में FormData पढ़ सकते हैं और यह रास्ते में एक स्ट्रिंग कभी नहीं होना चाहिए।

आपको अभी भी इनपुट को सुरक्षित रखने के लिए https की आवश्यकता है।

Answer 5

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

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

यदि संभव हो तो Windows Data Protection API का उपयोग करना एक और विकल्प है।

ध्यान दें कि SecureString का उद्देश्य सामग्री को यथासंभव कम समय में स्मृति में रखना है।