सुरक्षा एक दिलचस्प अवधारणा है और बहुत से लोगों को इसकी ओर आकर्षित करती है। दुर्भाग्य से यह एक जटिल विषय है और पेशेवर भी इसे गलत मानते हैं। मुझे Google (CSRF), Facebook (अधिक CSRF), कई प्रमुख ऑनलाइन खुदरा विक्रेताओं (मुख्य रूप से SQL इंजेक्शन / XSS), साथ ही कॉर्पोरेट और व्यक्तिगत दोनों तरह की हज़ारों छोटी साइटों में सुरक्षा छेद मिले हैं।
ये मेरे सुझाव हैं:
1) पैरामीटरयुक्त क्वेरी का उपयोग करें
पैरामीटरयुक्त क्वेरीज़ क्वेरी को दिए गए मानों को अलग डेटा के रूप में मानने के लिए बाध्य करती हैं, ताकि इनपुट मानों को DBMS द्वारा SQL कोड के रूप में पार्स न किया जा सके। बहुत से लोग अनुशंसा करेंगे कि आप mysql_real_escape_string() का उपयोग करके अपने स्ट्रिंग्स से बचें , लेकिन आम धारणा के विपरीत यह नहीं . है SQL इंजेक्शन के लिए एक कैच-ऑल सॉल्यूशन। उदाहरण के लिए इस प्रश्न को लें:
SELECT * FROM users WHERE userID = $_GET['userid']
अगर $_GET['userid'] 1 OR 1=1 . पर सेट है , कोई विशेष वर्ण नहीं हैं और इसे फ़िल्टर नहीं किया जाएगा। इसके परिणामस्वरूप सभी पंक्तियों को वापस कर दिया जाता है। या, इससे भी बदतर, क्या होगा यदि यह 1 OR is_admin = 1 . पर सेट हो ?
पैरामीटरयुक्त प्रश्न इस प्रकार के इंजेक्शन को होने से रोकते हैं।
2) अपने इनपुट की पुष्टि करें
पैरामीटरयुक्त क्वेरी बहुत अच्छी होती हैं, लेकिन कभी-कभी अनपेक्षित मान आपके कोड के साथ समस्या पैदा कर सकते हैं। सुनिश्चित करें कि आप पुष्टि कर रहे हैं कि वे सीमा के भीतर हैं और वे वर्तमान उपयोगकर्ता को कुछ ऐसा बदलने की अनुमति नहीं देंगे जो उन्हें नहीं करना चाहिए।
उदाहरण के लिए, आपके पास एक पासवर्ड परिवर्तन फ़ॉर्म हो सकता है जो एक स्क्रिप्ट को एक POST अनुरोध भेजता है जो उनका पासवर्ड बदलता है। यदि आप उनकी उपयोगकर्ता आईडी को प्रपत्र में एक छिपे हुए चर के रूप में रखते हैं, तो वे इसे बदल सकते हैं। भेजा जा रहा है id=123 id=321 . के बजाय इसका मतलब यह हो सकता है कि वे किसी और का पासवर्ड बदल दें। सुनिश्चित करें कि प्रकार, श्रेणी और पहुंच के संदर्भ में सब कुछ सही ढंग से मान्य है।
3) प्रदर्शित उपयोगकर्ता-इनपुट से बचने के लिए htmlspecialchars का उपयोग करें
मान लें कि आपका उपयोगकर्ता अपने "मेरे बारे में" कुछ इस तरह दर्ज करता है:</div><script>document.alert('hello!');</script><div>
समस्या यह है कि आपके आउटपुट में उपयोगकर्ता द्वारा दर्ज किया गया मार्कअप होगा। ब्लैकलिस्ट के साथ इसे स्वयं फ़िल्टर करने का प्रयास करना एक बुरा विचार है। htmlspecialchars का प्रयोग करें स्ट्रिंग्स को फ़िल्टर करने के लिए ताकि HTML टैग्स को HTML इकाइयों में परिवर्तित किया जा सके।
4) $_REQUEST का उपयोग न करें
क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ) हमले उपयोगकर्ता को एक लिंक पर क्लिक करने या एक यूआरएल पर जाने के लिए काम करते हैं जो एक स्क्रिप्ट का प्रतिनिधित्व करता है जो उस साइट पर एक क्रिया करता है जिसके लिए वे लॉग इन हैं। $_REQUEST वेरिएबल $_GET . का एक संयोजन है , $_POST और $_COOKIE , जिसका अर्थ है कि आप POST अनुरोध में भेजे गए चर के बीच अंतर नहीं बता सकते (अर्थात input के माध्यम से) आपके फ़ॉर्म में टैग) या एक वैरिएबल जो आपके URL में GET के हिस्से के रूप में सेट किया गया था (उदा. page.php?id=1 )।
मान लीजिए कि उपयोगकर्ता किसी को निजी संदेश भेजना चाहता है। वे sendmessage.php . पर एक POST अनुरोध भेज सकते हैं , to . के साथ , subject और message मापदंडों के रूप में। आइए अब कल्पना करें कि कोई इसके बजाय GET अनुरोध भेजता है:
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
अगर आप $_POST . का इस्तेमाल कर रहे हैं , आपको इनमें से कोई भी पैरामीटर दिखाई नहीं देगा, क्योंकि वे $_GET . में सेट हैं बजाय। आपका कोड $_POST['to'] . नहीं देखेगा या कोई अन्य चर, इसलिए यह संदेश नहीं भेजेगा। हालांकि, यदि आप $_REQUEST . का उपयोग कर रहे हैं , $_GET और $_POST एक साथ अटक जाते हैं, इसलिए एक हमलावर उन मापदंडों को URL के हिस्से के रूप में सेट कर सकता है। जब उपयोगकर्ता उस URL पर जाते हैं, तो वे अनजाने में संदेश भेज देते हैं। वास्तव में चिंताजनक बात यह है कि उपयोगकर्ता को कुछ भी करने की आवश्यकता नहीं है। यदि हमलावर कोई दुर्भावनापूर्ण पृष्ठ बनाता है, तो उसमें एक iframe . हो सकता है जो यूआरएल की ओर इशारा करता है। उदाहरण:
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
इसका परिणाम यह होता है कि उपयोगकर्ता बिना यह जाने कि उन्होंने कुछ किया है, लोगों को संदेश भेज रहे हैं। इस कारण से, आपको $_REQUEST . से बचना चाहिए और $_POST . का उपयोग करें और $_GET इसके बजाय।
5) आपको जो कुछ भी दिया जाता है, उसे संदिग्ध (या यहां तक कि दुर्भावनापूर्ण) समझें
आपको पता नहीं है कि उपयोगकर्ता आपको क्या भेज रहा है। यह वैध हो सकता है। यह हमला हो सकता है। किसी उपयोगकर्ता द्वारा आपको भेजी गई किसी भी चीज़ पर विश्वास न करें। सही प्रकारों में कनवर्ट करें, इनपुट को मान्य करें, जहां आवश्यक हो वहां फ़िल्टर करने के लिए श्वेतसूची का उपयोग करें (ब्लैकलिस्ट से बचें)। इसमें $_GET . द्वारा भेजी गई कोई भी चीज़ शामिल है , $_POST , $_COOKIE और $_FILES ।
अगर आप इन दिशा-निर्देशों का पालन करते हैं, तो सुरक्षा की दृष्टि से आपकी स्थिति उचित है।
