मैं वेब पर चीजों को विकसित करने के लिए नया हूं। अब तक, मैं बुरे लोगों को अपने इनपुट रूपों में एसक्यूएल इंजेक्शन जैसी चीज़ों को रखने और सर्वर पक्ष को सत्यापित करने से रोकने के लिए बहुत समय (50% या उससे अधिक) खर्च कर रहा हूं। क्या यह सामान्य है?वेब विकास के दौरान उपयोगकर्ता इनपुट सत्यापन में मेरे समय का कितना प्रतिशत खर्च किया जाएगा?
नहीं। यह सामान्य नहीं है। हो सकता है आप की जरूरत है:
किसी भी आधुनिक भाषा में दोनों चीजों के लिए समर्थन है।
दयालु सम्मान
मुझे खुशी है कि आप स्वयं को बचाने के लिए देखभाल कर रहे हैं। बहुत ज्यादा नहीं है।
हालांकि अन्य लोगों ने कहा है कि वास्तुकला की बेहतर पसंद आपकी समस्याओं को दूर कर देगी। तैयार बयान का उपयोग करना (अधिकांश भाषाओं के लिए इसका समर्थन होना चाहिए) एसक्यूएल इंजेक्शन हमले दूर कर देगा। इसके अलावा कई डेटाबेस के साथ वे काफी बेहतर प्रदर्शन करेंगे। क्रॉस-साइट स्क्रिप्टिंग हमलों को संभालना अधिक मुश्किल है। लेकिन मूल रणनीति यह तय करना है कि आप उपयोगकर्ता इनपुट से कैसे बचेंगे, यह तय करें कि आप इसे कहां से बचेंगे, और हमेशा इसे उसी स्थान पर करें। सोचने के जाल में मत आना कि बेहतर है! लगातार एक ही स्थान पर इसे एक ही तरीके से करना पर्याप्त होगा, और यह पता लगाने से बच जाएगा कि भागने के कई स्तरों में से कौन सा विशिष्ट बग पैदा कर रहा है।
या पाठ्यक्रम सीखने के लिए सीखें कि कैसे एक सैनी आर्किटेक्चर बनाने और बनाए रखने का अनुभव होता है। और इसके अलावा, यह आपके बुरे अनुभवों पर प्रतिबिंबित होता है। तो अपने वर्तमान दर्द बिंदुओं पर ध्यान दें (ऐसा लगता है कि आप हैं), और उनसे बचने के लिए आप अलग-अलग क्या कर सकते थे इसके बारे में सोचें। यदि आपके पास एक सलाहकार है, तो अपने सलाहकार से बात करें। यह हमेशा इस परियोजना के साथ आपकी मदद नहीं करेगा, लेकिन यह अगले के साथ होगा।
एसक्यूएल इंजेक्शन हमलों को रोकने के लिए बस तैयार कथन के साथ अपने प्रश्न पूछें (सटीक तरीका आपके प्लेटफॉर्म पर निर्भर करेगा)। एक बार ऐसा करने के बाद, आपको कभी भी इस विशेष पहलू से परेशान नहीं होना पड़ेगा। आपको बस हर जगह का उपयोग करने की आवश्यकता है।
सामान्य इनपुट सत्यापन के लिए, आवश्यक फ़ील्ड, संख्या आदि के परीक्षण के लिए सामान्य आधार पर भरोसा करना हमेशा अच्छा होता है। उदाहरण के लिए एएसपी.Net के वैधकर्ता उपयोग करना बहुत आसान है। अंगूठे का एक नियम आपको पालन करना चाहिए, यह आपके लिए ऐसा करने के लिए क्लाइंट-साइड (जावास्क्रिप्ट) पर भरोसा नहीं करना है, क्योंकि इसके आसपास जाना आसान है। हमेशा इसे सर्वर-साइड करें।
अपने रडार के नीचे रखने के लिए एक विशेष मामला यह है कि जब आप समृद्ध सामग्री को पेश करने की अनुमति देते हैं जिसमें HTML/जावास्क्रिप्ट हो सकता है। यह किसी दुर्भावनापूर्ण उपयोगकर्ता को आपके डेटा में जावास्क्रिप्ट इंजेक्ट करने की अनुमति दे सकता है जो कोड को ट्रिगर करेगा जिसे आप इसे प्रस्तुत करते समय नियंत्रित नहीं करते हैं। अपना खुद का सत्यापन कोड रोल करने का प्रयास करें। वेब, नि: शुल्क, परीक्षण किए गए, मैन्टेंट कोड के लिए खोजें जो आपके लिए यह करेगा। जेफ के पास पॉडकास्ट में से एक में उस संबंध में कुछ पॉइंटर्स थे।
एक बार जब आप अपना इनपुट सत्यापन कोड स्वचालित करते हैं, तो ऐसा करने में लगाए गए समय को सीधे आपके व्यावसायिक नियमों की जटिलता से संबंधित होना चाहिए। तो एक सामान्य नियम के रूप में: उन्हें सरल रखें।
@Jeremy - कुछ पीएचपी बारीकियों
यह डेटाबेस प्रश्नों की बात आती है, हमेशा कोशिश करते हैं और तैयार parameterised प्रश्नों का उपयोग करें। mysqli और PDO पुस्तकालय इसका समर्थन करते हैं। यह mysql_real_escape_string जैसे भागने वाले कार्यों का उपयोग करने से असीम रूप से सुरक्षित है।
हां, mysql_real_escape_string प्रभावी रूप से केवल एक स्ट्रिंग एस्केपिंग फ़ंक्शन है। यह एक जादू बुलेट नहीं है। यह सब कुछ खतरनाक पात्रों से बच जाएगा ताकि वे एक क्वेरी स्ट्रिंग में उपयोग करने के लिए सुरक्षित हो सकें। हालांकि, अगर आप पहले से अपने इनपुट को sanitize नहीं करते हैं, तो आप कुछ हमले वैक्टरों के लिए कमजोर हो जाएगा।
$result = "SELECT fields FROM table WHERE id = ".mysql_real_escape_string($_POST['id']);
आप को देखने के लिए कि इस का फायदा उठाने के लिए असुरक्षित है सक्षम होना चाहिए:
निम्नलिखित एसक्यूएल कल्पना कीजिए।
id पैरामीटर सामान्य हमले वेक्टर निहित कल्पना कीजिए:
1 OR 1=1
वहाँ में अपने सांकेतिक शब्दों में बदलना करने के लिए कोई जोखिम भरा वर्ण है, तो यह सीधे बचने फिल्टर के माध्यम से पारित होगा। हमें छोड़कर:
SELECT fields FROM table WHERE id = 1 OR 1=1
जो एक सुंदर एसक्यूएल इंजेक्शन वेक्टर है।
जबकि ये कार्य उपयोगी हैं, उन्हें देखभाल के साथ उपयोग किया जाना चाहिए। आपको यह सुनिश्चित करने की ज़रूरत है कि सभी वेब इनपुट कुछ डिग्री के लिए मान्य हैं। इस मामले में, हम देखते हैं कि हम का शोषण किया जा सकता है क्योंकि हमने यह नहीं देखा कि एक चर के रूप में हम एक चर के रूप में उपयोग कर रहे थे, वास्तव में संख्यात्मक था। PHP में आपको यह जांचने के लिए व्यापक रूप से कार्यों का एक सेट उपयोग करना चाहिए कि इनपुट पूर्णांक, फ्लोट्स, अल्फान्यूमेरिक इत्यादि हैं। लेकिन जब SQL की बात आती है, तो तैयार कथन का सबसे अधिक मूल्य ध्यान में रखते हैं। उपर्युक्त कोड सुरक्षित रहेगा यदि यह एक तैयार कथन था क्योंकि डेटाबेस कार्यों को पता था कि 1 OR 1=1 मान्य शाब्दिक नहीं है।
htmlspecialchars() के लिए। यह स्वयं का एक खनन क्षेत्र है।
PHP में एक वास्तविक समस्या है जिसमें इसमें विभिन्न एचटीएमएल से संबंधित भागने वाले कार्यों का पूरा चयन है, और वास्तव में कौन से कार्यों पर कोई स्पष्ट मार्गदर्शन नहीं है।
सबसे पहले, यदि आप एक HTML टैग के अंदर हैं, तो आप वास्तविक समस्या में हैं।
echo '<img src= "' . htmlspecialchars($_GET['imagesrc']) . '" />';
को देखो हम पहले से ही एक HTML टैग के अंदर कर रहे हैं, इसलिए हम < की जरूरत नहीं है या> कुछ भी खतरनाक नहीं है। हमारे हमले वेक्टर बस हो सकता है
तरह<img src= "javascript:alert(document.cookie)" />
हमले सीधे के माध्यम से हो जाता है javascript:alert(document.cookie)
अब परिणामी एचटीएमएल लग रहा है।
यह और भी खराब हो जाता है। क्यूं कर? क्योंकि htmlspecialchars केवल डबल कोट्स को एन्कोड करता है और एकल नहीं।तो अगर हम था
echo "<img src= '" . htmlspecialchars($_GET['imagesrc']) . ". />";
हमारी बुराई हमलावर अब नया पैरामीटर
इंजेक्षनpic.png' onclick='location.href=xxx' onmouseover='...
हमें
<img src='pic.png' onclick='location.href=xxx' onmouseover='...' />
इन मामलों में देता कर सकते हैं, वहाँ कोई जादुई गोली है, तो आप सिर्फ करने के लिए है स्वयं इनपुट इनपुट करें। यदि आप खराब वर्णों को आजमाते और फ़िल्टर करते हैं तो आप निश्चित रूप से असफल हो जाएंगे। श्वेतसूची दृष्टिकोण लें और केवल अच्छे वर्णों को छोड़ दें। उदाहरण के लिए XSS cheat sheet देखें कि विविध वेक्टर
भले ही आप HTML टैग के बाहर htmlspecialchars ($ string) का उपयोग करते हैं, फिर भी आप बहु-बाइट वर्णसेट हमले वैक्टरों के लिए कमजोर हैं।
सबसे प्रभावी आप निम्नानुसार mb_convert_encoding और htmlentities के संयोजन का उपयोग करना है।
$str = mb_convert_encoding($str, ‘UTF-8′, ‘UTF-8′);
$str = htmlentities($str, ENT_QUOTES, ‘UTF-8′);
यहां तक कि यह आईई 6 को कम करने के तरीके के कारण आईई 6 कमजोर छोड़ देता है। हालांकि, जब तक आईई 6 उपयोग बंद नहीं हो जाता है, तब तक आप आईएसओ -885 9 -1 जैसे अधिक सीमित एन्कोडिंग पर वापस आ सकते हैं।
जबकि आप PHP विशिष्ट कार्यों के बारे में बात कर रहे हैं, सिद्धांत सभी langugages पर लागू होते हैं। एसक्यूएल इंजेक्शन/एक्सएसएस को समझना इसे रोकने के लिए पहला कदम है। – Wayne
तैयार बयान पर बस एक नोट। सबसे पहले, आपको संग्रहीत प्रक्रियाओं का उपयोग करने की कोशिश करनी चाहिए यदि आप कर सकते हैं ... वे ज्यादातर मामलों में शायद एक बेहतर समाधान हैं।
दूसरा, वे दोनों केवल एसक्यूएल इंजेक्शन से आपकी रक्षा करते हैं जब तक आप गतिशील एसक्यूएल का उपयोग नहीं करते हैं, यानी एसक्यूएल जो अधिक एसक्यूएल लिखता है और फिर इसे निष्पादित करता है। इस मामले में वे अप्रभावी होंगे - और इसलिए प्रक्रियाओं को संग्रहीत किया जाएगा।
आपके द्वारा खर्च किए जाने वाले समय के प्रतिशत के संबंध में: सत्यापन बहुत महत्वपूर्ण है और कुछ समय नहीं लगता है, तो कुछ विचार नहीं लेते हैं। लेकिन प्रतिशत इस बात पर निर्भर करता है कि आपका आवेदन कितना बड़ा है, नहीं? एक बहुत ही छोटे आवेदन में, केवल एक न्यूजलेटर पंजीकरण कहें, यह काफी संभव है कि सत्यापन आपके समय का एक बड़ा प्रतिशत लेता है।
बड़े अनुप्रयोगों में, यानी जहां आपके पास बहुत सारे प्रस्तुति कोड हैं, यह सामान्य नहीं है।
मुझे आपकी समस्या दिखाई देती है। ऐसा लगता है कि आपके पास सुरक्षा तर्क कोड कोड पर छिड़काव है। और हर बार जब आप संभावित खतरनाक कोड लिखते हैं तो आपको सभी सुरक्षा शामिल करने के लिए सावधान रहना होगा। और हर बार एक नया खतरा खत्म हो जाता है, आपको इन सभी बयानों से गुजरना होगा और यह सत्यापित करना होगा कि वे सुरक्षित हैं।
आप इस तरह से वास्तविक सुरक्षा नहीं कर सकते हैं।
आपके पास कुछ रैपर होना चाहिए, जो असुरक्षित कोड हार्ड उत्पन्न करना मुश्किल होगा। उदाहरण के लिए, तैयार बयान। लेकिन आप एक ओआरएम का उपयोग करना चाह सकते हैं, जैसे रूबी ऑन एक्टिव रिकार्ड, या आपके ढांचे में कुछ समकक्ष।
आउटपुट और एक्सएसएस सुरक्षा के लिए, सुनिश्चित करें कि आउटपुट डिफ़ॉल्ट रूप से HTML से बच निकला है। फिर यदि आपको वास्तव में जेनरेट किए गए HTML को उपयोगकर्ता को आउटपुट करने की आवश्यकता है, तो आप इसे स्पष्ट रूप से करेंगे, और यह सत्यापित करना आसान होगा।
सीएसआरएफ सुरक्षा के लिए एक सामान्य समाधान भी खोजने का प्रयास करें।आम तौर पर इसे एक सत्यापन टोकन स्पष्ट रूप से बनाने की आवश्यकता के बिना, स्वचालित रूप से अपना कर्तव्य करना चाहिए, और इसे मैन्युअल रूप से सत्यापित करना, इसे छोड़ना, या अनुरोध को अस्वीकार करना चाहिए।
आपको एक समस्या का सामना करना पड़ रहा है जिसे केवल सामान्यीकृत करके हल किया जा सकता है।
कोशिश इनपुट सत्यापन के सामान्य प्रकार की पहचान करने के लिए आप
पर एक विशेष संदर्भ ('स्क्रिप्ट', 'चयन', 'ड्रॉप' ...) की उम्मीद नहीं है डी डेटा को संसाधित करने से पहले व्यवस्थित रूप से कॉल करें।
सभी डेटाबेस एक्सेस तैयार कथन के साथ किया जाना चाहिए और क्वेरी स्ट्रिंग को संयोजित नहीं करना चाहिए।
सभी आउटपुट से बच जाना चाहिए, क्योंकि आप अपने डेटाबेस में से बचने वाली सभी चीज़ों को स्टोर नहीं करना चाहते हैं।
बैंड/सामाजिक दृष्टिकोण का एक अच्छा तरीका यह है: अपने उपयोगकर्ताओं को सर्वोत्तम तरीके से पहचानें। पहचानने का मौका उतना ही अधिक होगा जितना कम वे सिस्टम के साथ मूर्ख होंगे। कोड भेजने के लिए अपना मोबाइल फोन नंबर प्राप्त करें, उनके क्रेडिट कार्ड आदि की जांच करें
उदाहरण: एक विशेषता जिसे मैं बाद में जोड़ना चाहता हूं, किसी के लिए एक पूर्व-स्वरूपित HTML दस्तावेज़ को टेक्स्ट बॉक्स में कॉपी और पेस्ट करने के लिए है। – danmine