2009-03-17 16 views
7

दोनों वेब और एमवीसी के सापेक्ष नवागंतुक के रूप में, मैं सुरक्षा सर्वोत्तम प्रथाओं का एक अच्छा सारांश ढूंढ रहा हूं जो मुझे लागू करना चाहिए।एएसपी.NET एमवीसी साइट

साइट "मामूली संवेदनशील डेटा" के साथ सार्वजनिक रूप से सामना कर रही होगी (जिसका अर्थ है कि हम मुकदमा नहीं कर सकते हैं, लेकिन संभवतः डेटा खत्म होने पर कई दोस्त नहीं बनेंगे!) और निम्नलिखित सुरक्षा कदम उठाए जाएंगे: ए: फॉर्म/सदस्यता प्रमाणीकरण और प्राधिकरण बी: एसक्यूएल इंजेक्शन को रोकने के लिए पैरामीटरेटेड प्रश्न। सी: निष्क्रियता के x मिनट के साथ स्वत: टाइमआउट सी: क्लाइंट के लिए सर्वर एन्क्रिप्शन

आप और क्या सलाह देते हैं?

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

+0

उत्कृष्ट सवाल, खासकर यदि आप सादा एएसपी.NET से आ रहे हैं। – Soviut

+0

धन्यवाद। मान लीजिए या नहीं, मेरी अधिकांश वेब गतिविधि लगभग 10 साल पहले क्लासिक एएसपी के साथ आई थी। मुझे बहुत कुछ करने के लिए मिल गया है! – Aaron

उत्तर

4
  • आप कुकीज़ का उपयोग कर रहे हैं, तो उन पहचान करने के लिए, एक मनमाना टोकन पहचान के लिए ग्राहक पर स्टोर करने के लिए (जैसे कि एक GUID के रूप में) का उपयोग सुनिश्चित करें। मैंने बहुत सारी वेबसाइटें देखी हैं जो मेरी कुकी में अपना ईमेल पता या उपयोगकर्ता नाम संग्रहीत करती हैं ... बस इसे दूसरे में बदलना होगा!

  • अपने सॉफ़्टवेयर को लिखें ताकि यह medium trust के तहत चलाया जा सके।

+0

पहली टिप्पणी इतनी स्पष्ट और आसान है कि यह शानदार है! कभी 100 वर्षों में इसके बारे में सोचा नहीं होगा :) मध्यम निश्चित रूप से लागू होता है और मैं करूँगा। धन्यवाद! – Aaron

+0

यदि आपको यह उपयोगी लगता है तो उत्तर को ऊपर उठाने के लिए स्वतंत्र महसूस करें। शायद यह भी स्वीकार करें अगर यह सबसे अच्छा होने के समाप्त होता है। –

3

यदि आप वेब विकास के लिए नए हैं आप cross site scripting (XSS) के बारे में पता होना चाहिए। आप ASP.NET MVC में इसके विरुद्ध सुरक्षा के लिए Http.Encode सहायक विधि का उपयोग कर सकते हैं।

1

फिल Haack- द्वारा इस post पर एक नजर डालें में से एक एमएस देव के विकास में शामिल किया गया।

इसके अतिरिक्त Microsoft Anti-Cross Site Scripting Library पर एक नज़र आने वाले सभी मापदंडों

1
  1. को फिल्टर करने की शायद तुम तरीके कि बाहर या नहीं से आह्वान किया जा सकता है का चयन करना चाहिए। उदाहरण के लिए http://yourhost.com/edit/deletealltable जैसी किसी भी तालिका को हटाने जैसी विधि को सावधान रहें। सुनिश्चित करें कि आप अपनी कक्षा और विधियों को अच्छी तरह डिज़ाइन करते हैं। और सार्वजनिक विधि को आह्वान करने से रोकने के लिए गुण [NonAction] दें।

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

  3. किसी भी अप्रयुक्त कचरा फ़ाइलों को हटाएं जैसे आपके समाधान फ़ोल्डर में अप्रयुक्त फ़ाइलों को हटा दें।

  4. टेक्स्टबॉक्स जैसे किसी भी इनपुट नियंत्रण की जांच करें और दोबारा जांचें और सत्यापित करें। मैं बस आपके सिस्टम को हैक करने के लिए टेक्स्टबॉक्स में कुछ दे सकता हूं।
  5. यदि आप एमवीसी और नियमित एएसपी.नेट के बीच मिश्रण का उपयोग करते हैं, तो कृपया उनके बीच किसी भी निर्भरता को हटा दें।
+0

क्या आप एमवीसी और नियमित वेबफॉर्म के बीच निर्भरता को हटाने की व्याख्या कर सकते हैं? मुझे यकीन नहीं है कि आपका क्या मतलब है। धन्यवाद! उदाहरण के लिए – Aaron

+0

, एक नियमित एएसपीएक्स एक फैंसी नियंत्रण प्रदर्शित करेगा और फिर एमवीसी http: // yourhost/ग्राहक/getall से डेटा प्राप्त करें और जावास्क्रिप्ट का उपयोग करके परिणाम प्रस्तुत करें। यह ठीक है, लेकिन आपके पास – nickotech2000

0

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

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

2

सुनिश्चित करें कि आप आदेश अनुरोधों से बाहर निकलें। सुनिश्चित करें कि क्लाइंट को संवेदनशील डेटा देखने की अनुमति देने से पहले प्रमाणित किया गया है, या कुछ मामलों में, सुनिश्चित करें कि क्लाइंट डेटा मैनिपुलेशन की अनुमति देने से पहले, सही चैनल के माध्यम से आ गया है। उदाहरण के लिए, यदि उत्पाद विवरण पृष्ठ से अनुरोध आया तो केवल एक आइटम को अपने कार्ट में जोड़ने की अनुमति दें। यदि आप चेक नहीं करते हैं, तो कोई भी कार्रवाई के साथ गड़बड़ कर सकता है। यूआरएल http://server/cart/add/XYZ123 जैसा होगा और कोई भी 'आईडी' पैरामीटर को ट्विक कर सकता है।

+0

दोनों में अधिक रखरखाव कोड है, मैं यह पूछने के लिए थोड़ा शर्मिंदा हूं कि यह आसान है ... लेकिन मैं अनुरोध पृष्ठ का नाम कैसे प्राप्त करूं (उचित चैनल से आने के लिए सुनिश्चित करें)? अनुरोध वस्तु का वह हिस्सा है? धन्यवाद! – Aaron

+0

आप उस इकाई की पहचान करने के लिए कुकी/सत्र चर का उपयोग कर सकते हैं जिसके साथ आप काम कर रहे हैं। फिर केवल उस इकाई पर कार्रवाई की अनुमति दें। आप "पिछला" यह सेट करेंगे, यह दर्शाते हुए कि आप पहले से ही वहां रहे हैं। –

संबंधित मुद्दे