बस उस ट्रस्ट पर विचार करें जो सर्वर के पास है।सत्र अपहरण और PHP
सत्र निर्धारण: पूरी साइट के लिए SSL एन्क्रिप्शन: निर्धारण "session_regenerate_id()" केवल प्रमाणीकरण में (login.php)
सत्र sidejacking मैं उपयोग से बचने के लिए।
क्या मैं सुरक्षित हूं?
धन्यवाद।
ओडब्ल्यूएएसपी A3-Broken Authentication and Session Management पढ़ें। OWASP A5-CSRF के बारे में भी पढ़ें, जिसे कभी-कभी "सत्र सवारी" कहा जाता है।
आप एक php हेडर फाइल में इस कोड का उपयोग करना चाहिए:
ini_set('session.cookie_secure',1);
ini_set('session.cookie_httponly',1);
ini_set('session.use_only_cookies',1);
session_start();
इस कोड session fixation से बचाता है। यह xss के खिलाफ document.cookie तक पहुंचने में भी मदद करता है जो कि एक तरीका है कि Session Hijacking हो सकता है। केवल HTTPS लागू करने के लिए कुकीज़ OWASP A9-Insufficient Transport Layer Protection को संबोधित करने का एक अच्छा तरीका है। HTTPS का उपयोग करने का यह तरीका कभी-कभी "सुरक्षित कुकीज़" कहा जाता है, जो इसके लिए एक भयानक नाम है। STS एक बहुत ही अच्छी सुरक्षा सुविधा है, लेकिन सभी ब्राउज़र इसका समर्थन नहीं करते हैं (अभी तक)।
आपका उत्तर कम से कम एक +10 का हकदार है, और मेरे वोट के साथ आपको यह मिला। प्रश्नों के युगल सिर्फ यह सुनिश्चित करने के लिए कि मैं समझ गया: 1) 'cookie_secure' मुझे सत्र में हमेशा https पर काम करने के लिए लागू करेगा, है ना? 2) 'कुकी_httponly' क्या करता है? मैंने PHP स्पष्टीकरण पढ़ा, लेकिन जब यह कहता है कि जेएस फॉर्म पढ़ने की कुकीज़ को रोकता है, तो मुझे यह नहीं मिलता है, वास्तव में कुकीज़ को कई परिस्थितियों में जेएस द्वारा पढ़ा जाना चाहिए। धन्यवाद, और एफवाईआई: चूंकि PHP 5.3.0 'session.use_only_cookies' डिफ़ॉल्ट रूप से 1 है http://it.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies –
मैं सत्र में उपयोगकर्ता एजेंट और आईपी जानकारी संग्रहीत करने और प्रत्येक अनुरोध पर इसे सत्यापित करने का भी सुझाव दूंगा। यह बुलेट प्रूफ नहीं है, लेकिन यह मजबूती में काफी महत्वपूर्ण वृद्धि है। जबकि UA फोर्जिंग वास्तव में आसान है, आईपी फोर्जिंग, जबकि संभव हो, बहुत कठिन है ... लेकिन आपको उन उपयोगकर्ताओं के साथ समस्या हो सकती है जो एओएल उपयोगकर्ताओं जैसे राउंड-रॉबिन आईपी सिस्टम के पीछे हैं ...
" आईपी फोर्जिंग "या अधिक सामान्य रूप से आईपी स्पूफिंग कहा जाता है, तीन तरह के हैंडशेक के कारण इंटरनेट पर एक टीसीपी कनेक्शन के लिए असंभव है। हालांकि कॉर्पोरेट नेटवर्क पर लोड बैलेंसर्स या वाईफाई हॉट स्पॉट्स बदलने के कारण एक वैध उपयोगकर्ता का आईपी पता सत्र के दौरान बदल सकता है। – rook
यह काफी संभव है। इसके लिए केवल एक एमआईटीएम शैली के हमले की आवश्यकता होती है (जहां हमलावर को अंत बिंदु राउटर में से एक तक पहुंच प्राप्त होती है, और फिर वे जो भी चाहें कर सकते हैं) ... – ircmaxell
यदि आप उस आईपी पर भेजे गए पैकेट तक पहुंच सकते हैं तो यह "फोर्जिंग" नहीं है। –
सबसे अच्छा अभ्यास I कभी भी पाया गया है कि डेटा डेटा डेटाबेस या टेक्स्ट फ़ाइल में सहेजता है। डेटाबेस में उपयोगकर्ता एजेंट होगा, और आईपी रिकॉर्ड होगा और यह सुनिश्चित करने के लिए हर अनुरोध की जांच करें कि सत्र कभी दूसरे द्वारा अपहरण नहीं किया गया है।
उदाहरण के लिए डेटाबेस में सत्र कैसे सहेजा गया है, आप codeigntier सत्र लाइब्रेरी में कार्यान्वयन देख सकते हैं। मेरी राय में इस तरह किसी को सत्र को हाइजक्ट करने से रोकने के लिए काफी बचाया जाता है।
उपयोगकर्ता एजेंट की जांच करना व्यर्थ है क्योंकि यह एक हमलावर नियंत्रित चर है। डेटाबेस में सत्र आईडी को संग्रहीत करने का अर्थ है कि एसक्यूएल इंजेक्शन हमलावर को सिस्टम तक तत्काल पहुंच प्रदान करता है, इसलिए उसे लॉगिन करने के लिए पासवर्ड हैश तोड़ने की आवश्यकता नहीं होगी। आईपी एड्रेस की जांच करना त्रुटि प्रवण है क्योंकि यह एक वैध सिस्टम पर बदल सकता है, उदाहरण के लिए यदि वह कॉर्पोरेट नेटवर्क पर लोड बैलेंसर के पीछे है। – rook
@Rook - आप मानते हैं कि डेटाबेस एसक्यूएल इंजेक्शन के लिए कमजोर है। तैयार बयानों या संग्रहीत प्रक्रियाओं का उचित उपयोग, और पैरामीटर के उचित स्वच्छता, एसक्यूएल इंजेक्शन की अनुमति नहीं देगा। – AgmLauncher
@AgmLauncher यह डेटाबेस में सादे टेक्स्ट में पासवर्ड संग्रहीत करने के बराबर है। एक विफलता पर योजना बनाना चाहिए। – rook
यह किस प्रकार की साइट है? –
@MrXexxx एक ऐसी साइट जहां डेवलपर्स इसे हैक करना नहीं चाहते हैं। – rook
@ द रूक, मैं ओपी से बात कर रहा था, यह एक वास्तविक सवाल था, आपकी टिप्पणी दोनों मुखर और पूरी तरह से अनुपयोगी है। –