में बफर ओवरफ़्लो/ओवररन संभव है पूरी तरह से प्रबंधित एएसपीनेट वेब पोर्टल में बफर ओवरफ्लो/ओवररन कमजोरियां हो सकती हैं। अगर हाँ इसका परीक्षण कैसे किया जा सकता है।क्या पूरी तरह से प्रबंधित एएसपीनेट सी # वेब एप्लिकेशन
जब तक आप वेबसर्वर या .NET/ASP.NET स्टैक का उपयोग नहीं करते हैं।
सामान्य मामले में, आपको बफर ओवररन्स के बारे में चिंता करने की आवश्यकता नहीं है। यह प्रबंधित कोड के प्रमुख फायदों में से एक है, कचरा संग्रह शायद अन्य प्रमुख लाभ है।
कुछ किनारे के मामले हैं जिनके बारे में आपको अवगत होना चाहिए - किसी भी समय आपका प्रबंधित कोड अप्रबंधित कोड (Win32 API कॉल, COM इंटरऑप, पी/Invoke, आदि) के साथ इंटरैक्ट करता है, अप्रबंधित में बफर ओवररन्स की संभावना है कोड, प्रबंधित कोड से पारित पैरामीटर के आधार पर।
"असुरक्षित" के रूप में चिह्नित कोड भी सीधे बफर ओवरफ्लो के कारण मेमोरी पतों में हेरफेर कर सकता है। अधिकांश सी # कोड "असुरक्षित" कीवर्ड का उपयोग किए बिना लिखा गया है, हालांकि।
मेरे पास एक उपकरण (एचपी देव निरीक्षक) मेरे एएसपी.NET ऐप के भीतर एक संभावित "संभावित पैरामीटर बफर ओवरफ़्लो" का पता लगाता था और ऐसा इसलिए था क्योंकि हमारे टेक्स्टबॉक्स में से एक में हमारे पास अधिकतम लम्बाई = "20" नहीं था ..
विभिन्न प्रकार के बफर ओवरफ्लो, अच्छी तरह से। यदि आपके टेक्स्टबॉक्स का मान अनचेक किया गया है, ओह, कहें, एक एसक्यूएल पैरामीटर, यह कहर बरबाद कर सकता है - या यदि यह किसी ऐसे फ़ंक्शन को पास कर दिया गया है जो पैरामीटर के लिए "कथुलू के कॉल" के पूरे पाठ की अपेक्षा नहीं कर रहा था, तो यह बुरी तरह से बर्ताव करना। जानें कि समझदार उपयोगकर्ता (जैसे कि एफएफ के वेब डेवलपर एक्सटेंशन का उपयोग करने वाले) केवल मैक्सलेथेंथ को बंद कर सकते हैं। यह एक सुविधा रक्षा है, ऐसा कुछ नहीं जिसे आपको गिनना चाहिए। यदि आपको कोई फर्क पड़ता है तो आपको हमेशा लंबाई के लिए उपयोगकर्ता इनपुट की जांच करनी चाहिए। – Broam
क्या आप और अधिक समझा सकते हैं। –
यदि आपका कोड पूरी तरह से प्रबंधित है, तो आपके द्वारा लिखे गए कोड को ओवरफ़्लो बफर करने का कोई तरीका नहीं है। लेकिन स्टैक (.NET और ऐसे) जिन्हें आप शीर्ष पर बनाए गए हैं, शुद्ध प्रबंधित कोड में नहीं लिखे गए हैं, इसलिए उनको शोषण करने की संभावना है, भले ही यह छोटा हो। –
आपके उत्तर के लिए बहुत बहुत धन्यवाद। –