सिर्फ हेडस्टफ के लिए (इसलिए आपको यह पता चल जाएगा कि फ़्रेड-आई- ने इस कोड का उपयोग न करने के लिए क्यों कहा) - मैं इसे कुछ हद तक अलग करने जा रहा हूं, क्रम में, जैसा कि मैं इसके माध्यम से जाता हूं (यह नहीं है प्रश्न करने वाले व्यक्ति पर एक व्यक्तिगत खुदाई - लेकिन सिर्फ एक विचार देने के लिए कि LAMP स्टैक पर आधे रास्ते के सुरक्षित एप्लिकेशन को बनाने की कोशिश करने के लिए थोड़ी देखभाल और पूर्वविचार की आवश्यकता होती है ... और खूनी दिमागी निंदक को सबसे खराब मानने के साथ जोड़ा जाता है। मानवता मदद करती है):
प्वाइंट 1
कोई बड़ी बात नहीं है - लेकिन वास्तव में यदि आप एक सत्र शुरू करने जा रहे हैं तो आपको एक सत्र शुरू करना चाहिए, भले ही $_POST हो डेटा या नहीं। आपको शायद अपनी कॉन्फ़िग फ़ाइल की आवश्यकता होगी और किसी और चीज़ से पहले शीर्ष पर सत्र शुरू करना चाहिए।
टर्मिनल त्रुटि नहीं (क्योंकि आपके पास कोई सत्र सत्यापन नहीं है) - बस अजीब।
प्वाइंट 2
आपको इस फ़ाइल में आउटपुट मिला है (echo ) इसलिए यह दस्तावेज़ रूट के अंतर्गत होना चाहिए और वेब ट्री में उपलब्ध होना चाहिए।
include("config.php");
यह वास्तव में ठीक से नहीं लिखा गया है यह संभवतः require_once 'config.php'; होना चाहिए (यह मानते हुए कि यह एक आवश्यक प्रोग्राम फ़ाइल है और वैकल्पिक शामिल नहीं है जिसे विफल होने दिया जा सकता है) लेकिन वह त्रुटि नहीं। त्रुटि यह है कि आपको अपनी कॉन्फ़िगरेशन फ़ाइल अपने दस्तावेज़ रूट के अंदर मिल गई है। उस फ़ाइल में एक सर्वर गलत कॉन्फ़िगरेशन या साधारण टाइपो, सैद्धांतिक रूप से, उस फ़ाइल की सामग्री को सादे पाठ में स्क्रीन पर आउटपुट करने की अनुमति दे सकता है, संभावित रूप से आपके डेटाबेस कनेक्शन स्ट्रिंग्स (और कौन जानता है) को दुनिया + कुत्ते को प्रकट कर सकता है।
कॉन्फ़िगरेशन फ़ाइलें वेब ट्री के बाहर मौजूद होनी चाहिए या, ऐसा न होने पर, .htaccess जैसी किसी चीज़ से सुरक्षित निर्देशिका के अंदर होनी चाहिए Deny from all . उन्हें HTTP पर कभी भी एक्सेस नहीं किया जाना चाहिए।
प्वाइंट 3
mysql पुस्तकालय बहिष्कृत है और इसका उपयोग बिल्कुल नहीं किया जाना चाहिए; MySQLi या PDO जाने का रास्ता है, आदर्श रूप से बाध्य मापदंडों/मानों के साथ:
व्यक्तिगत रूप से मुझे पीडीओ के लिए मिल गया था।
अंक 4 और 5
$password = mysql_real_escape_string(stripslashes(md5($_POST['password'])));
सबसे पहले, इसका क्रम गलत है। आप हैशिंग कर रहे हैं $_POST['password'] और फिर स्ट्रिप्सलाश करने का प्रयास - एक बार हैश किए जाने के बाद कोई स्लैश नहीं होगा। हालांकि यदि आप लोगों को पासवर्ड में स्लैश (या जो कुछ भी) का उपयोग करने से रोकने की कोशिश कर रहे हैं, तो आपको स्ट्रिंग को हैश करने से पहले उन्हें हटाना होगा।
अगला md5 पासवर्ड हैशिंग एल्गोरिथम के रूप में उपयोग नहीं किया जाना चाहिए, यह कमजोर पाया गया है और इसे जितनी बार चाहिए, उससे कहीं अधिक बार स्ट्रिंग टकराव बनाने के लिए मजबूर किया जा सकता है।
हां, आपको चाहिए पासवर्ड के बजाय पासवर्ड के केवल हैश या "फिंगरप्रिंट" स्टोर करें, लेकिन आदर्श रूप से आप नमक और हैश (कम से कम sha1 के साथ) चाहते हैं ) उन पासवर्डों को केवल md5() . में फेंकने के बजाय समारोह।
देखें:http://uk3.php.net/mcrypt उदाहरण के लिए
और अपनी पसंद के खोज इंजन का उपयोग करके "पासवर्ड सॉल्टिंग हैशिंग" पर एक खोज करें।
प्वाइंट 6
SELECT id FROM $table
WHERE username = '" . $username . "'
and password = '" . $password . "';
मैंने = . में जोड़ा वह मूल प्रश्न से गायब था, लेकिन फिर भी, आपकी क्वेरी में उपयोगकर्ता नाम और पासवर्ड से मेल नहीं खाते ... अगर कोई आपके उपयोगकर्ता नाम में SQL इंजेक्शन प्राप्त करने में कामयाब रहा तो पासवर्ड कभी भी चेक नहीं किया जाएगा। कल्पना कीजिए:
SELECT user.id
FROM user WHERE user.username = 'fred' OR 1 = 1
-- AND user.password = 'abc123'
डेटाबेस से उपयोगकर्ता आईडी और पासवर्ड फ़िंगरप्रिंट का चयन करना और फिर डेटाबेस परत में पासवर्ड जाँच पर भरोसा करने के बजाय एप्लिकेशन में पासवर्ड का मूल्यांकन करना बेहतर है। इसका मतलब यह भी है कि आप अपने पासवर्ड को मान्य करने के लिए एप्लिकेशन में ही एक समर्पित हैशिंग और साल्टिंग एल्गोरिदम का उपयोग कर सकते हैं।
प्वाइंट 7
$_SESSION['user'] = $_POST["username"];
यह केवल सत्र में उपयोगकर्ता नाम संग्रहीत कर रहा है? इसे किसी भी तरह से "लॉगिन सत्यापनकर्ता" के रूप में उपयोग नहीं किया जाना चाहिए, विशेष रूप से क्योंकि आपके सत्र में अपहरण ।
सत्र आईडी को लाइव सत्र की कुकी से आसानी से देखा जा सकता है और किसी और के लॉगिन को "उधार" लेने की आवश्यकता होगी। आपको कम से कम उपयोगकर्ता के आईपी पते, UserAgent स्ट्रिंग या अपेक्षाकृत स्थिर डेटा के कुछ अन्य संयोजन को जोड़कर सत्र के अपहरण की संभावना को कम करने का प्रयास करना चाहिए, जिसकी तुलना आप प्रत्येक पृष्ठ पर कर सकते हैं ... हालांकि व्यावहारिक रूप से किसी भी दृष्टिकोण में कमियां हैं (विशेष रूप से, जैसा कि मैंने पाया है, यदि आपके पास AOL का उपयोग करने वाले विज़िटर हैं) - लेकिन आप अपहरण को कम करने के लिए संभवतः 99+% प्रभावी सत्र फ़िंगरप्रिंट बना सकते हैं, जिसमें उपयोगकर्ता के सत्र को गलती से डंप किए जाने की बहुत कम संभावना है।
आदर्श रूप से आप सीएसआरएफ हमले जब उपयोगकर्ता को डेटाबेस पर "विशेषाधिकार प्राप्त" कार्रवाई करने की आवश्यकता होती है (उनके विवरण या जो कुछ भी अपडेट करें)। जब उपयोगकर्ता लॉग इन करता है तो टोकन डेटाबेस और/या एसएसएल कुकी में संग्रहीत एक पूरी तरह यादृच्छिक और अद्वितीय कोड हो सकता है (यह मानते हुए कि उपयोगकर्ता HTTPS के बाहर डेटाबेस को अपडेट करने वाली कोई भी क्रिया नहीं कर सकता है क्योंकि यह केवल डेटा संचारित करेगा इंटरनेट पर स्पष्ट पाठ में - जो एक बुरा विचार . होगा )।
टोकन को किसी भी/सभी रूपों के लिए एक छिपे हुए फॉर्म फ़ील्ड में रखा जाता है और जब भी वह फॉर्म सबमिट किया जाता है तो कुकी (या सत्र या डेटाबेस) में संग्रहीत मान के विरुद्ध चेक किया जाता है। यह सुनिश्चित करता है कि फ़ॉर्म सबमिट करने वाले व्यक्ति का आपकी वेबसाइट पर कम से कम एक लाइव सत्र हो।
