PHP सत्र सुरक्षा

Question

PHP के साथ जिम्मेदार सत्र सुरक्षा बनाए रखने के लिए कुछ दिशानिर्देश क्या हैं? पूरे वेब पर जानकारी है और यह समय है जब यह सभी एक ही स्थान पर उतरा है!

Answer 1

आपके सत्र को सुरक्षित रखने के लिए कुछ चीज़ें हैं:

1. उपयोगकर्ताओं को प्रमाणित करने या संवेदनशील संचालन करने के लिए एसएसएल का उपयोग करें।
2. जब भी सुरक्षा स्तर में परिवर्तन (जैसे लॉगिंग) में सत्र आईडी को पुन: बनाएँ। यदि आप चाहें तो आप सेशन आईडी को भी हर अनुरोध पर पुनः प्राप्त कर सकते हैं।
3. सत्र का समय निकाल लें
4. रजिस्टर ग्लोबल्स का उपयोग न करें
5. सर्वर पर प्रमाणीकरण विवरण संग्रहीत करें। यही है, कुकी में उपयोगकर्ता नाम जैसे विवरण न भेजें।
6. की जाँच करें $_SERVER['HTTP_USER_AGENT']। यह सत्र अपहरण में एक छोटा अवरोध जोड़ता है। आप आईपी एड्रेस भी चेक कर सकते हैं। लेकिन यह उन उपयोगकर्ताओं के लिए समस्या का कारण बनता है, जिनके पास कई इंटरनेट कनेक्शन आदि पर लोड संतुलन (जो कि हमारे वातावरण में मामला है) के कारण आईपी एड्रेस बदल रहा है।
7. फ़ाइल सिस्टम पर सत्रों तक पहुंच बंद करें या कस्टम सत्र हैंडलिंग का उपयोग करें
8. संवेदनशील संचालन के लिए, उपयोगकर्ताओं को अपने ऑर्डिनेंस विवरण फिर से प्रदान करने के लिए लॉग इन करने की आवश्यकता पर विचार करें

Comments

केवल कुछ ऑपरेशन के लिए एसएसएल का उपयोग करना पर्याप्त नहीं है, जब तक कि आपके पास एन्क्रिप्टेड और अनएन्क्रिप्टेड ट्रैफ़िक के लिए अलग-अलग सत्र न हों। यदि आप HTTPS और HTTP पर एकल सत्र का उपयोग करते हैं, तो हमलावर इसे पहले गैर-HTTPS अनुरोध पर चुरा लेगा।

— कोर्नेल

-1 उपयोगकर्ता एजेंट स्पूफ के लिए तुच्छ है। आप कचरे के कोड का वर्णन कर रहे हैं और एक सुरक्षा प्रणाली नहीं है।

— किश्ती

@ रूक, यह एक तुच्छ बाधा हो सकती है (हमलावर अपनी साइट का उपयोग करके किसी पीड़ित के उपयोगकर्ता-एजेंट को पकड़ सकता है) और अस्पष्टता के माध्यम से सुरक्षा पर निर्भर करता है लेकिन यह अभी भी एक अतिरिक्त अवरोध है। यदि उपयोगकर्ता-एजेंट HTTP को सत्र के उपयोग के दौरान बदलना था, तो यह बेहद संदिग्ध और सबसे अधिक संभावना है। मैंने कभी नहीं कहा कि आप इसे अकेले इस्तेमाल कर सकते हैं। यदि आप इसे अन्य तकनीकों के साथ जोड़ते हैं तो आपके पास बहुत अधिक सुरक्षित साइट है।

— ग्रोम

@grom मैं अपने दरवाजे भर में स्कॉच टेप का एक टुकड़ा डाल और कहा कि यह में घुसपैठ करने से लोगों को रोकने की तरह लगता है इसकी।

— किश्ती

यदि आप उपयोगकर्ता एजेंट की जाँच कर रहे हैं, तो आप संगतता मोड को चालू करने पर IE8 उपयोगकर्ताओं से सभी अनुरोधों को रोक देंगे। मज़े को देखें मैंने अपने कोड में इस समस्या को ट्रैक किया था: serverfault.com/questions/200018/http-302-problem-on-ie7 । मैं उपयोगकर्ता एजेंट की जांच कर रहा हूं, क्योंकि यह स्पूफ करने के लिए ऐसी तुच्छ बात है, जैसा कि अन्य ने कहा है।

— बेस्टटेंडेंस

Answer 2

हर बार सत्र के सुरक्षा स्तर में बदलाव के लिए एक दिशानिर्देश को session_regenerate_id पर कॉल करना होता है। यह सत्र अपहरण को रोकने में मदद करता है।

Answer 3

मेरे दो (या अधिक) सेंट:

• किसी पर भरोसा मत करो
• फ़िल्टर इनपुट, एस्केप आउटपुट (कुकी, सत्र डेटा आपके इनपुट भी हैं)
• XSS से बचें (अपने HTML को अच्छी तरह से बनाए रखें, PHPTAL या HTMLPurifier पर एक नज़र डालें )
• गहन सुरक्षा
• डेटा को उजागर न करें

इस विषय पर एक छोटी लेकिन अच्छी पुस्तक है: क्रिस शिफ्टलेट द्वारा आवश्यक PHP सुरक्षा ।

आवश्यक PHP सुरक्षा http://shiflett.org/images/essential-php-security-small.png

पुस्तक के मुख पृष्ठ पर आपको कुछ दिलचस्प कोड उदाहरण और नमूना अध्याय मिलेंगे।

आप यहां वर्णित तकनीक (IP & UserAgent) के ऊपर उपयोग कर सकते हैं, पहचान की चोरी से कैसे बचें

Comments

XSS- रोकथाम के लिए +1। इसके बिना CSRF के खिलाफ सुरक्षा करना असंभव है, और इस प्रकार कोई व्यक्ति सत्र आईडी प्राप्त किए बिना सत्र की "सवारी" कर सकता है।

— कोर्नेल

Answer 4

मुझे लगता है कि प्रमुख समस्याओं में से एक (जिसे PHP 6 में संबोधित किया जा रहा है) register_globals है। अभी बचने register_globalsके लिए इस्तेमाल किया जाने वाला एक मानक तरीका है $_REQUEST, $_GETया $_POSTसरणियों का उपयोग करना ।

इसे करने के लिए "सही" तरीका (5.2 के रूप में, हालांकि यह वहां थोड़ा छोटी गाड़ी है, लेकिन 6 के रूप में स्थिर है, जो जल्द ही आ रहा है) फिल्टर के माध्यम से है ।

इसलिए इसके बजाय:

$username = $_POST["username"];

तुम करोगे:

$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);

या अभी भी:

$username = filter_input(INPUT_POST, 'username');

Comments

इसका सवाल से कोई संबंध नहीं है।

— Pixel Developer

वास्तव में? फिर क्यों स्वीकार किए गए उत्तर में वे रजिस्टर ग्लोबल्स का उपयोग नहीं करने का उल्लेख करते हैं? जहां तक ​​कि अधिकांश रन-ऑफ-द-मिल डेवलपर्स का संबंध नहीं है, ग्लोबल्स को पंजीकृत करें और चर हैंडलिंग "सत्र" की छतरी के नीचे आते हैं, भले ही वह तकनीकी रूप से "सत्र" ऑब्जेक्ट का हिस्सा न हो?

— cmcculloh

मैं सहमत हूं, यह पूरी तरह से सवाल का जवाब नहीं देता है , लेकिन यह निश्चित रूप से सवाल के जवाब का हिस्सा है। फिर से, यह स्वीकार किए गए उत्तर में एक बुलेट बिंदु निकालता है, "रजिस्टर ग्लोबल्स का उपयोग न करें"। यह बताता है कि इसके बजाय क्या करना है।

— cmcculloh

Answer 5

इस सत्र निर्धारण पेपर में बहुत अच्छे संकेत हैं जहां हमला हो सकता है। विकिपीडिया पर सत्र निर्धारण पृष्ठ भी देखें ।

Answer 6

IP पते का उपयोग करना वास्तव में मेरे अनुभव का सबसे अच्छा विचार नहीं है। उदाहरण के लिए; मेरे कार्यालय के दो आईपी पते हैं जो लोड के आधार पर उपयोग किए जाते हैं और हम लगातार आईपी पते का उपयोग करते हुए मुद्दों में भाग लेते हैं।

इसके बजाय, मैंने अपने सर्वर पर डोमेन के लिए एक अलग डेटाबेस में सत्रों को संग्रहीत करने का विकल्प चुना है। इस तरह से फ़ाइल सिस्टम पर किसी को भी उस सत्र जानकारी तक पहुँच नहीं है। यह वास्तव में 3.0 से पहले phpBB के साथ मददगार था (वे तय के बाद से) लेकिन यह अभी भी मुझे लगता है कि एक अच्छा विचार है।

Answer 7

यह बहुत तुच्छ और स्पष्ट है, लेकिन हर उपयोग के बाद session_destroy के लिए सुनिश्चित करें। इसे लागू करना मुश्किल हो सकता है यदि उपयोगकर्ता स्पष्ट रूप से लॉग आउट नहीं करता है, तो ऐसा करने के लिए एक टाइमर सेट किया जा सकता है।

यहाँ setTimer () और clearTimer () पर एक अच्छा ट्यूटोरियल है ।

Answer 8

PHP सत्र और सुरक्षा (सत्र अपहरण के अलावा) के साथ मुख्य समस्या यह है कि आप किस वातावरण में हैं। डिफ़ॉल्ट रूप से OS के अस्थायी निर्देशिका में फ़ाइल में सत्र डेटा संग्रहीत करता है। किसी विशेष विचार या योजना के बिना यह एक विश्व पठनीय निर्देशिका है, इसलिए आपके सत्र की सभी जानकारी सर्वर तक पहुंच के साथ किसी के लिए भी सार्वजनिक है।

कई सर्वरों पर सत्र बनाए रखने के लिए। उस बिंदु पर PHP को उपयोगकर्ता द्वारा संभाले गए सत्रों में बदलना बेहतर होगा जहां यह सत्र डेटा के लिए आपके प्रदान किए गए कार्यों को CRUD (कॉल, रीड, अपडेट, डिलीट) कहता है। उस बिंदु पर आप सत्र जानकारी को डेटाबेस या समाधान जैसे समाधान में संग्रहीत कर सकते हैं ताकि सभी एप्लिकेशन सर्वर के पास डेटा तक पहुंच हो।

यदि आप साझा सर्वर पर हैं, तो अपने स्वयं के सत्रों को संग्रहीत करना भी फायदेमंद हो सकता है क्योंकि यह आपको उस डेटाबेस में संग्रहीत करने देगा, जिस पर आप अक्सर नियंत्रण रखते हैं तब फाइल सिस्टम।

Answer 9

मैंने अपने सत्रों को इस तरह सेट किया-

लॉग इन पेज पर:

$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);

(वाक्यांश एक कॉन्फ़िगर पृष्ठ पर परिभाषित)

फिर हेडर पर जो बाकी साइट पर है:

session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {       
    session_destroy();
    header('Location: http://website login page/');
    exit();     
}

Answer 10

php.ini

session.cookie_httponly = 1
change session name from default PHPSESSID

eq Apache हेडर जोड़ें:

X-XSS-Protection    1

Comments

httpd.conf -> <FilesMatch "\" (php | phtml | aspx | ht | html) $ "> हैडर ने X-XSS- प्रोटेक्शन" 1 "</ FilesMatch>

— user956584

ज्ञात हो कि X-XSS-Protectionवास्तव में उपयोगी नहीं है। वास्तव में, स्वयं की रक्षा करने वाला एल्गोरिदम वास्तव में शोषण किया जा सकता है, जिससे यह पहले से भी बदतर हो गया है।

— पचेरियर

Answer 11

मैं आईपी और उपयोगकर्ता एजेंट दोनों की जांच करूंगा कि क्या वे बदलते हैं

if ($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']
    || $_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR'])
{
    //Something fishy is going on here?
}

Comments

यदि उपयोगकर्ता लोड-संतुलित प्रॉक्सी फ़ार्म के पीछे है, तो IP कानूनी रूप से बदल सकता है।

— कोर्नेल

और user_agent हर बार उपयोगकर्ता द्वारा अपने ब्राउज़र को अपग्रेड करने पर बदल सकता है।

— स्कॉट

@ सीट्स मैं आईपी भाग से सहमत हूं, लेकिन ब्राउज़र अपग्रेड के लिए, आप सत्र को तब सेट करेंगे जब वे लॉगिन करेंगे तो मैं यह नहीं देखूंगा कि एक बार फिर से लॉगिन करने के बाद वे नया सत्र बनाए बिना वहां ब्राउज़र को कैसे अपग्रेड करेंगे।

— जेसनडेविस

मेरा मानना ​​है कि IE8 में कंपेटेबल मोड के बीच टॉगल करने पर user_agent भी बदल सकता है। यह नकली भी बहुत आसान है।

हां, लेकिन उन उपयोगकर्ताओं के बारे में क्या जिनके पास स्थिर आईपी eq जीएसएम था और हर आधे घंटे में बदल दिया जाता है। इसलिए, IP को सत्र + होस्ट नाम में संग्रहीत किया गया है, जब IP! = REMOTE_ADDR होस्ट की जाँच करें और hostanmes eq की तुलना करें। 12.12.12.holand.nl-> जब holand.nl == सच है। लेकिन कुछ होस्ट के पास IP आधारित होस्टनाम था, फिर मास्क की तुलना करें 88.99.XX.XX

— user956584

Answer 12

यदि आप session_set_save_handler () का उपयोग करते हैं, तो आप अपना सत्र हैंडलर सेट कर सकते हैं। उदाहरण के लिए आप डेटाबेस में अपने सत्रों को संग्रहीत कर सकते हैं। डेटाबेस सत्र हैंडलर के उदाहरणों के लिए php.net टिप्पणियों का संदर्भ लें।

DB सत्र भी अच्छे हैं यदि आपके पास कई सर्वर हैं अन्यथा यदि आप फ़ाइल आधारित सत्रों का उपयोग कर रहे हैं तो आपको यह सुनिश्चित करने की आवश्यकता होगी कि प्रत्येक वेबसर्वर के पास सत्रों को पढ़ने / लिखने के लिए एक ही फाइल सिस्टम के लिए उपयोग हो।

Answer 13

आपको यह सुनिश्चित करने की आवश्यकता है कि सत्र डेटा सुरक्षित है। अपने php.ini को देखकर या phpinfo () का उपयोग करके आप सत्र सेटिंग्स पा सकते हैं। _session.save_path_ आपको बताता है कि वे कहाँ सहेजे गए हैं।

फ़ोल्डर और उसके माता-पिता की अनुमति की जाँच करें। यह सार्वजनिक (/ tmp) नहीं होना चाहिए या आपके साझा सर्वर पर अन्य वेबसाइटों द्वारा सुलभ होना चाहिए।

मान लें कि आप अभी भी php सेशन का उपयोग करना चाहते हैं, तो आप _session.save_path_ को बदलकर या किसी अन्य फ़ोल्डर का उपयोग करके डेटाबेस में डेटा को _session.save_handler_ बदलकर सेट कर सकते हैं।

आप अपने php.ini में _session.save_path_ (कुछ प्रदाता इसे अनुमति देते हैं) या अपाचे + mod_php के लिए, अपने साइट रूट फ़ोल्डर में एक .htaccess फ़ाइल में सेट करने में सक्षम हो सकते हैं php_value session.save_path "/home/example.com/html/session":। आप इसे रन टाइम पर _session_save_path () _ के साथ भी सेट कर सकते हैं।

सेट और वैकल्पिक सत्र हैंडलर के लिए क्रिस शिफलेट के ट्यूटोरियल या Zend_Session_SaveHandler_DbTable की जाँच करें ।