ASP.NET MVC 3/4: एंटी-हैकिंग

बहुत पहले नहीं मैंने हब पर SQL इंजेक्शन के बारे में अगला लेख पढ़ा फिर यह विचार दिखाने के लिए पैदा हुआ कि ASP.NET MVC में सुरक्षा कैसी है।

सबसे पहले, हम एक साधारण साइट बनाएंगे, मैंने चरण-दर-चरण निर्माण का वर्णन नहीं किया है, मैं सिर्फ इस्तेमाल की जाने वाली तकनीकों का एक गुच्छा कहूँगा: ASP.NET MVC4 और इकाई फ्रेमवर्क 4.3.1 (डेटाबेस के साथ काम करने के लिए ओआरएम)। परियोजना को लेख के अंत में डाउनलोड किया जा सकता है।

नतीजतन, हमें एक स्थिर समाचार और टिप्पणियों को जोड़ने की क्षमता के साथ एक साइट मिली।

क्रॉस-साइट स्क्रिप्टिंग (XSS)

---

XSS के साथ अपनी हैक शुरू करते हैं, हम टिप्पणियों को जोड़कर पृष्ठ पर स्क्रिप्ट एम्बेड करेंगे।
अब हम एक स्क्रिप्ट के साथ एक टिप्पणी जोड़ने की कोशिश करेंगे:



हम एक टिप्पणी जोड़ने के लिए क्लिक करते हैं और हमें एक त्रुटि मिलती है, अफसोस, हम कभी विधि तक नहीं पहुंचे:



वेबसाइट काम करने का सबसे तेज़ तरीका क्या है? बेशक विधि के लिए सत्यापन काट लें:

[ValidateInput(false)] 

यह एक कार्य नहीं है, फिर से हमारी स्क्रिप्ट निष्पादित नहीं की गई है:



ऐसा इसलिए होता है, क्योंकि डिफ़ॉल्ट रूप से, सभी पाठ एन्कोडेड और आउटपुट एन्कोडेड होते हैं, स्थिति बदल सकती है:

 @Html.Raw() 

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

एसक्यूएल इंजेक्शन

---

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



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

क्रॉस-साइट अनुरोध क्षमा (CSRF)

---

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

इससे निपटने के लिए, एमवीसी के पास प्रस्तुति के लिए एक सहायक है, जो फॉर्म बॉडी में होना चाहिए:

 @Html.AntiForgeryToken() 

अब नियंत्रक (एक्शन) विधि के लिए विशेषता:

 [ValidateAntiForgeryToken] 

आइए देखें कि हमने क्या किया (मैंने XSS के साथ पृष्ठ में इस तर्क को जोड़ा), हम सामान्य अनुरोध करते हैं:



छिपे हुए क्षेत्रों के अलावा, हमें कुकीज़ भी मिलीं:



अब इस छिपे हुए फ़ील्ड को हटाएं और परिणाम देखें (कम से कम तीन विकल्प, दृश्य से हटा दें, इसे फायरबग से हटा दें और मेरे लिए फ़िडलर में संगीतकार के माध्यम से अधिक दिलचस्प है, सफल अनुरोध खींचें और अनुरोध बॉडी में इस पैरामीटर को हटा दें):



यह याद रखने योग्य है कि यह पैरामीटर हर अनुरोध के साथ उत्पन्न नहीं होता है और भविष्य में पैकेट को हैक करके हैक किया जा सकता है।

जानकारी छिपाना

---

कई लोग इस पर ध्यान नहीं देते हैं, लेकिन मेरा मानना ​​है कि यह आइटम बहुत महत्वपूर्ण है। एक धातु के दरवाजे के लिए एक ताला चुनना, मैंने सीखा कि कई ताले बस एक ड्रिल के साथ खोले जा सकते हैं, तीन मोटे बोल्ट (सिलेंडर जो बाहर जाते हैं) हो सकते हैं, लेकिन यह सही एक छेद को ड्रिल करने के लिए पर्याप्त है
जगह (इसलिए कमजोर स्थानों पर पॉइंट स्ट्राइक बोलने के लिए) और महल खुला है। इसी तरह, यदि आप कहते हैं कि आपके पास इस तरह के और ऐसे आईआईएस हैं, जैसे और एएसपी.नेट का ऐसा संस्करण, आदि। आप एक हमलावर को अमूल्य सहायता प्रदान करते हैं! मैं एक कप चाय के साथ एल्माह के लॉग को साफ करना पसंद करता हूं और देखता हूं कि वे मेरी साइट पर php, mysql को खोजने की कोशिश करते हैं, यह निर्धारित करने के लिए अद्भुत सेवाओं का उपयोग करके कि सीएमएस का उपयोग किया जाता है, आदि।

यहाँ मेरी साइट अब लौट रही है:



X-Powered-by को निकालें:

 <system.webServer> ... <httpProtocol> <customHeaders> <remove name="X-Powered-By" /> </customHeaders> </httpProtocol> ... </system.webServer> 

ASP.NET संस्करण:

 <system.web> ... <httpRuntime enableVersionHeader="false" /> ... </system.web> 

Application_Start में MVC संस्करण:

 MvcHandler.DisableMvcResponseHeader = true; 

और सबसे कठिन हिस्सा सर्वर है, जिसके लिए हम एक HttpModule बनायेंगे:

  public class CustomServerHeaderModule : IHttpModule { public void Init(HttpApplication context) { context.PreSendRequestHeaders += OnPreSendRequestHeaders; } public void Dispose() { } private void OnPreSendRequestHeaders(object sender, EventArgs e) { HttpContext.Current.Response.Headers.Set("Server", "Apache 2000 Server"); } } 

और विन्यास में जोड़ें:

  <system.webServer> ... <modules runAllManagedModulesForAllRequests="true"> ... <add name="CustomServerHeader" type="HackingMVC.HttpModules.CustomServerHeaderModule" /> </modules> ... <system.webServer> 

परिणामस्वरूप, हमें यह परिणाम मिला:

एक निष्कर्ष के बजाय

---

यह कुछ भी नहीं है कि ASP.NET अपनी सुरक्षा के लिए प्रसिद्ध है, MVC बहुत सक्रिय रूप से विकसित हो रहा है, जो प्रत्येक संस्करण के साथ अधिक से अधिक दिलचस्प होता जा रहा है। कुछ बिंदुओं पर विचार नहीं किया गया था, मैंने कुछ याद किया, लेकिन यह केवल कुछ का उल्लेख करने के लिए पर्याप्त है, किसी भी मामले में एक लेख के ढांचे के भीतर इस तरह के एक बड़ा विषय पर विचार करना असंभव है। यह इस तथ्य पर ध्यान देने योग्य है कि साइट पर एसएसएल का उपयोग करना बहुत महत्वपूर्ण है, क्योंकि अन्यथा प्राधिकरण के दौरान आपका डेटा चोरी हो सकता है, किसी भी पृष्ठ पर सत्र, प्राधिकरण टोकन या कोई अन्य डेटा चोरी हो जाता है, जो सुरक्षा की बहुत उपेक्षा करता है। JSON हाइजैकिंग और तथ्य यह है कि चेतावनी को फेंकना आसान नहीं है, यदि आप अनुमति के बिना GET अनुरोध के माध्यम से डेटा प्राप्त करने का प्रयास करते हैं, तो इस तरह से याद रखें, इस तरह से आपको केवल डेटा देना चाहिए जो खोने के लिए डरावना नहीं है। मैंने उन समस्याओं का केवल एक हिस्सा दिखाया, जो आपके सामने आ सकती हैं और जिसे विकसित करते समय आपको ध्यान देना चाहिए।

इस साइट के लिए पीएस विश और हैकिंग विकल्प का स्वागत है: ज़िप आर्काइव । (8.7 एमबी, चूंकि डाउनलोड किए गए NuGet पैकेज समाधान / प्रोजेक्ट में शामिल हैं) या पैकेज के बिना ज़िप संग्रह (706 Kb)।

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