इंजेक्शन से कैसे बचें

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

सभी प्रकार के इंजेक्शन लोकप्रिय अटैक वैक्टर में से एक हैं: html, जावास्क्रिप्ट, एसक्यूएल। इसलिए, कई प्रतिष्ठित स्रोत विभिन्न मंत्रों के माध्यम से उपयोगकर्ता इनपुट को ढालने की सलाह देते हैं। इस पोस्ट में मैं आपको एक सरल नियम दिखाऊंगा, जिसके बाद आपको इंजेक्शन की समस्या को हल करने की गारंटी दी जाती है।





नियम सरल है: डेटा प्रारूपों को न मिलाएं!

• विभिन्न स्वरूपों के तार निर्दिष्ट न करें:
  

  lblName.Text = person.Name; 

  खराब: HTML: सादा पाठ
  
  

   lblName.Text = HtmlEncode(person.Name); 

  अच्छा: HTML: HTML
  
  
• विभिन्न स्वरूपों की पंक्तियों को न जोड़ें:
  

   "<span>" + person.Name + "</span>" 

  खराब: HTML + सादा पाठ + HTML
  
  

   "<span>" + HtmlEncode(person.Name) + "</span>" 

  अच्छा: HTML + HTML + HTML
  
  
• नेस्टेड स्वरूपों के साथ सावधान रहें:
  

   label.Text = "<script>" + string.Format(script, string.Format(summary, string.Format(personUrl, id)) + "<script>"; 

  खराब: HTML + जावास्क्रिप्ट + URI + पाठ + HTML
  
  

   label.Text = "<script>" + HtmlEncode(string.Format(script, JavaScriptEncode(string.Format(person.Summary, UrlEncode(string.Format(personUrl, id)))))) + "</script>"; 

  अच्छा: HTML + HTML (जावास्क्रिप्ट (URI (पाठ)) + HTML
  

प्रारूप

सभी डेटा का एक प्रारूप होता है। सबसे सरल प्रारूप सादा पाठ है जहाँ सभी वर्ण समान हैं और कोई अतिरिक्त अर्थ नहीं रखते हैं। पाठ डेटा के आधार पर कोई भी अन्य प्रारूप, यह csv, html, जावास्क्रिप्ट हो, नियंत्रण वर्ण हैं - अल्पविराम, टैग, विशेष। अक्षर। उपरोक्त प्रारूप के मिश्रण के साथ, खतरनाक परिस्थितियां उत्पन्न होती हैं जब एक प्रारूप को दूसरे के रूप में माना जाता है।
उदाहरण के लिए, ASP.NET लेबल नियंत्रण के लिए, पाठ गुण HTML के रूप में माना जाता है। इसलिए, यदि हम एक अलग प्रारूप (उदाहरण के लिए, सादा पाठ) में इस संपत्ति को एक मूल्य प्रदान करते हैं, तो हम एक संभावित एचटीएमएल भेद्यता खोलेंगे। यही कारण है कि आपको विशेष स्क्रीन के स्वरूपों के बीच विशेष एडेप्टर का उपयोग करने की आवश्यकता है। अक्षर। इसलिए सादे पाठ से HTML तक एक एडाप्टर "<स्क्रिप्ट>" को "& lt; स्क्रिप्ट & gt;" में बदल देगा। और सादा पाठ से एक URI के लिए एक एडाप्टर "example.com? <Script> alert ('pwned')" </ script> "को" example.com% 3F% 3Ccript% 3Ealert ('pwned')% 3B% 3C% 2Fscript में बदल देगा। % 3E। "
इसी तरह के एडेप्टर लगभग सभी भाषाओं और प्लेटफार्मों में मौजूद हैं। SQL क्वेरी के लिए, यह उन पैरामीटर वाले प्रश्नों का उपयोग करने के लिए पर्याप्त है जो डेटाबेस द्वारा ही संसाधित किए जाएंगे।

आपके जीवन को आसान बनाने के लिए यहां 3 सरल बिंदु दिए गए हैं:

• उपयोग किए गए पाठ चर, गुणों, फ़ील्ड के प्रारूप को जानें। सुविधा के लिए, आप नामों में प्रत्यय जोड़ सकते हैं: HeaderHtml, AvatarUrl।
• एक एडेप्टर लाइब्रेरी बनाएं: HtmlEncode, UrlEncode, JavaScriptEncode।
• विभिन्न स्वरूपों के डेटा के साथ काम करते समय सावधान रहें।

UPD: PHP इंजेक्शन के बारे में
इस लेख में एक चर्चा में, मुझे यह तर्क दिया गया था कि मेरा नियम php इंजेक्शन के साथ काम नहीं करता है। मैं यह दिखाना चाहता हूं कि यह काम करता है। तो, सामान्य कोड पर विचार करें:

 include($_GET['path']); 

अगर मैं GET के अनुरोध में "बुराई .php" पास करता हूं, तो स्क्रिप्ट सुरक्षित रूप से निर्दिष्ट कारनामे को लॉन्च करेगी। अब इस स्थिति को मेरे शासन की शैली पर विचार करें। विवरण से यह स्पष्ट है कि शामिल फ़ंक्शन को वर्तमान फ़ाइल सिस्टम या URI के प्रारूप में एक फ़ाइल पथ की अपेक्षा है। और सामग्री प्रारूप $ _GET ['पथ'] सादा पाठ है। इंजेक्शन से कैसे बचें? एक pathEncode लिखें जो इस पाठ को पथ के सही प्रारूप में ले जाएगा, या यदि खाली स्ट्रिंग को वापस करना असंभव है (उदाहरण के लिए, अनुमत पथों की एक सफेद सूची के खिलाफ जांच करें)। उस मामले में

 include(pathEncode($_GET['path'])); 

या तो निष्पादन योग्य के साथ क्रैश हो जाता है या फ़ाइल अपलोड करता है। मुख्य बात यह स्पष्ट रूप से समझना है कि कौन सा प्रारूप शामिल है और उपयोगकर्ता किस प्रारूप से आता है।