जब उपयोगकर्ता लॉग इन होता है तो मुझे PHP सत्र में स्टोर करने की आवश्यकता क्या होती है?

Question

वर्तमान में जब उपयोगकर्ता लॉग इन किया गया, तो मैंने 2 सत्र बनाए।

$_SESSION['logged_in'] = 1; 
$_SESSION['username'] = $username; // user's name 

ताकि, उन पृष्ठ में लॉग इन करने की आवश्यकता है, मैं सिर्फ ऐसा करते हैं:

if(isset($_SESSION['logged_id'])){ 
// Do whatever I want 
} 

वहाँ किसी भी सुरक्षा खामियों है? मेरा मतलब है, क्या मेरे सत्र को हैक करना आसान है? लोग सत्र कैसे हैक करते हैं? और मैं इसे कैसे रोकूं ??

संपादित करें:

बस इस पाया:

http://www.xrvel.com/post/353/programming/make-a-secure-session-login-script

http://net.tutsplus.com/tutorials/php/secure-your-forms-with-form-keys/

बस लिंक नहीं मिला, उन तरीकों काफी अच्छा कर रहे हैं ?? कृपया अपनी राय दें। मुझे अभी तक सबसे अच्छा जवाब नहीं मिला है।

Answer 1

शब्दावली

• उपयोगकर्ता: एक आगंतुक।
• ग्राहक: किसी विशेष मशीन पर स्थापित एक विशेष वेब-सक्षम सॉफ़्टवेयर।

---

समझौता सत्र

आदेश में समझने के लिए कैसे अपने सत्र सुरक्षित बनाने के लिए, आपको पहले समझना चाहिए कैसे सत्र काम करते हैं।

के कोड के इस टुकड़े देखते हैं:

session_start(); 

जैसे ही आप फोन है कि, पीएचपी एक कुकी (डिफ़ॉल्ट रूप से) PHPSESSID कहा जाता है के लिए दिखेगा। यदि यह नहीं पाया जाता है, यह बना दिया जाएगा:

PHPSESSID=h8p6eoh3djplmnum2f696e4vq3 

यदि यह पाया जाता है, यह PHPSESSID का मूल्य लेता है और फिर इसी सत्र लोड करता है। उस मान को session_id कहा जाता है।

यही एकमात्र चीज है जिसे ग्राहक पता चलेगा। जो भी आप सत्र चर में जोड़ते हैं वह सर्वर पर रहता है, और क्लाइंट को कभी भी स्थानांतरित नहीं किया जाता है। यदि आप $_SESSION की सामग्री बदलते हैं तो वह चर बदलता नहीं है। जब तक आप इसे नष्ट नहीं करते हैं या यह समय समाप्त होता है तब तक यह हमेशा रहता है। इसलिए, यह $_SESSION की सामग्री को खराब करने की कोशिश करने के लिए बेकार है या अन्य माध्यमों से ग्राहक को उस जानकारी को कभी प्राप्त या भेजता नहीं है।

फिर, एक नया सत्र के मामले में, आप चर सेट हो जाएगा:

$_SESSION['user'] = 'someuser'; 

ग्राहक है कि जानकारी कभी नहीं देखेंगे।

---

समस्या

एक सुरक्षा समस्या उत्पन्न हो सकती है जब एक दुर्भावनापूर्ण उपयोगकर्ता एक अन्य उपयोगकर्ता के session_id चुरा लेता है। किसी प्रकार की जांच के बिना, वह उस उपयोगकर्ता का प्रतिरूपण करने के लिए स्वतंत्र होगा। हमें क्लाइंट की पहचान करने के लिए एक रास्ता खोजने की जरूरत है (उपयोगकर्ता नहीं)।

एक रणनीति (सबसे प्रभावी) में यह जांचना शामिल है कि सत्र शुरू करने वाले क्लाइंट का आईपी सत्र का उपयोग कर व्यक्ति के आईपी जैसा ही है।

if(logging_in()) { 
    $_SESSION['user'] = 'someuser'; 
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR']; 
} 

// The Check on subsequent load 
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) { 
    die('Session MAY have been hijacked'); 
} 

कि रणनीति के साथ समस्या यह है कि एक ग्राहक (लंबी अवधि के सत्र पर) एक लोड संतुलन, या का उपयोग करता है, तो उपयोगकर्ता एक गतिशील आईपी है, यह एक झूठी चेतावनी ट्रिगर किया जाएगा है।

एक और रणनीति ग्राहक के उपयोगकर्ता एजेंट की जाँच शामिल है:

if(logging_in()) { 
    $_SESSION['user'] = 'someuser'; 
    $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT']; 
} 

// The Check on subsequent load 
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) { 
    die('Session MAY have been hijacked'); 
} 

कि रणनीति के नकारात्मक पक्ष यह है कि अगर ग्राहक उन्नयन यह ब्राउज़र है या कोई एडऑन (कुछ उपयोगकर्ता-एजेंट के कहते हैं) को स्थापित करता है, उपयोगकर्ता-एजेंट स्ट्रिंग बदल जाएगी और यह एक झूठी चेतावनी ट्रिगर करेगा।

एक और रणनीति प्रत्येक 5 अनुरोधों पर session_id को घुमाने के लिए है। इस तरह, session_id सैद्धांतिक रूप से अपहृत होने के लिए पर्याप्त समय तक नहीं रहता है।

if(logging_in()) { 
    $_SESSION['user'] = 'someuser'; 
    $_SESSION['count'] = 5; 
} 

// The Check on subsequent load 
if(($_SESSION['count'] -= 1) == 0) { 
    session_regenerate_id(); 
    $_SESSION['count'] = 5; 
} 

आप इन रणनीतियों में से प्रत्येक को अपनी इच्छानुसार जोड़ सकते हैं, लेकिन आप डाउनसाइड्स को भी जोड़ देंगे।

दुर्भाग्यवश, कोई समाधान मूर्ख-प्रमाण नहीं है। यदि आपका session_id समझौता किया गया है, तो आप इसके लिए काफी कुछ कर रहे हैं। उपर्युक्त रणनीतियों केवल स्टॉप-गैप उपायों हैं।

Answer 2

आप PHP here में सत्र सुरक्षा पर एक मार्गदर्शिका पा सकते हैं।

Answer 3

आप जावास्क्रिप्ट (एक्सएसएस-> क्रॉससाइड स्क्रिप्टिंग हमले) के माध्यम से सत्र चुरा सकते हैं .. आपको हमेशा अपने सत्र को सुरक्षित करने के लिए नमकीन MD5 हैश का उपयोग करना चाहिए।

सत्र अपहरण बचने के लिए आप उपयोगकर्ता एजेंट

$ _SERVER [ 'HTTP_USER_AGENT']

हैश में

रूप में अच्छी तरह रखना चाहिए।

अपने उदाहरण में:

$_SESSION['logged_in'] = 1; 
$_SESSION['username'] = $username; // user's name 
$_SESSION['hash']  = md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT']); // user's name hashed to avoid manipulation 

सत्र का उपयोग करने से पहले, सुनिश्चित करें कि यह सही हैश का उपयोग करता है:

if (!$_SESSION['hash']==md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT'])){ 
    die ('session hash not corrected') 
} 

Answer 4

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

तो जब में उपयोगकर्ता लॉग:

// not the most secure hash! 
$_SESSION['checksum'] = md5($_SESSION['username'].$salt); 

और एक संवेदनशील क्षेत्र में प्रवेश करने से पहले:

if (md5($_SESSION['username'].$salt) != $_SESSION['checksum']) 
{ 
    handleSessionError(); 
} 

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

आप अतिरिक्त सुरक्षा के लिए डेटाबेस का उपयोग कर अपने स्वयं के सत्र हैंडलिंग कोड कर सकते हैं। जूमला की तरह कुछ कठोर सीएमएस भी आईपी लॉग करते हैं।हालांकि, इस कारण कुछ आईएसपी

Answer 5

का उपयोग करने वाले लोगों के लिए समस्याएं उपयोगकर्ता को पहचानने के लिए आप आईपी पता, ब्राउज़र हस्ताक्षर इत्यादि स्टोर कर सकते हैं। प्रत्येक अनुरोध पर, यह देखने के लिए कि क्या कुछ संदिग्ध हुआ है, वर्तमान मूल्यों के खिलाफ जांचें।

ध्यान रखें कि कुछ लोग प्रदाताओं के पीछे हैं जो बिल्कुल गतिशील आईपी पते का उपयोग करते हैं, इसलिए उन लोगों को अक्सर लॉग आउट किया जा सकता है।

Answer 6

मुझे लगता है कि दूसरे को 'log_in' होना चाहिए?

सत्र सुरक्षा के बारे में कुछ संसाधन:

phpsec

shiflett

Answer 7

यह हास्यास्पद है।

सत्र अपहरण तब होता है जब (आमतौर पर एक क्रॉस साइट स्क्रिप्टिंग हमले के माध्यम से) कोई आपके सत्र आईडी (जो एक कुकी द्वारा स्वचालित रूप से वेब सर्वर पर भेजा जाता है) को रोकता है।

किसी उदाहरण के लिए इस पोस्ट की है:

तो जब में उपयोगकर्ता लॉग:

// नहीं सबसे सुरक्षित हैश! $ _SESSION ['चेकसम'] = एमडी 5 ($ _ सत्र ['उपयोगकर्ता नाम']। $ नमक);

और एक संवेदनशील क्षेत्र में प्रवेश करने से पहले:

अगर (।! Md5 ($ _ सत्र [ 'उपयोगकर्ता नाम'] $ नमक) = $ _SESSION [ 'चेकसम']) {
handleSessionError(); गलत है, लेकिन व्यर्थ नहीं -}

क्या इस

1. लवण साथ कुछ गड़बड़ है के माध्यम से जाने की सुविधा देता है। कोई भी आपके डॉन एमडी 5 को क्रैक नहीं कर रहा है, जो परवाह करता है कि यह
2. सत्र में संग्रहीत एक ही चर के md5 के साथ एक SESSION चर के md5 की तुलना कर रहा है - आप सत्र से सत्र की तुलना कर रहे हैं। अगर चीज अपहृत हो जाती है तो यह कुछ भी नहीं करेगी।

$_SESSION['logged_in'] = 1; 
$_SESSION['username'] = $username; // user's name 
$_SESSION['hash']  = md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT']); 

// उपयोगकर्ता का नाम हेरफेर

किसके द्वारा हेरफेर से बचें से बचने के लिए टुकड़ों में बांटा? जादुई सत्र faeries? आपके सत्र चर को संशोधित नहीं किया जाएगा जब तक कि आपके सर्वर से समझौता नहीं किया जाता है। हैश केवल 48 वर्ण स्ट्रिंग में आपकी स्ट्रिंग को अच्छी तरह से सघन करने के लिए है (उपयोगकर्ता एजेंट थोड़ा लंबा प्राप्त कर सकते हैं)।

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

आपको दुखद सच्चाई मिलती है।

जैसे ही आपकी सत्र आईडी से समझौता किया जाता है, आप चले गए हैं। आप अनुरोध के दूरस्थ पते की जांच कर सकते हैं और सुनिश्चित कर सकते हैं कि सभी अनुरोधों में वही रहता है (जैसा मैंने किया) और यह आपके ग्राहक आधार के 99% के लिए पूरी तरह से काम करेगा। फिर एक दिन आपको ऐसे उपयोगकर्ता से कॉल मिलेगा जो लोड संतुलित प्रॉक्सी सर्वर वाले नेटवर्क का उपयोग करता है, अनुरोध अलग-अलग आईपी (कभी-कभी गलत नेटवर्क पर भी) के माध्यम से बाहर आ रहे होंगे और वह उसे खो देंगे सत्र दाएं और केंद्र छोड़ दिया।

Answer 8

सत्र निर्धारण को रोकने के लिए, जो मूल रूप से एसआईडी का अनुमान लगा रहा है या विभिन्न विधियों का उपयोग करके इसे चोरी कर रहा है। इससे कोई फर्क नहीं पड़ता कि आपके सत्र तर्क को कितना परिष्कृत किया गया है, यह निश्चित रूप से कुछ डिग्री तक चोरी करने के लिए कमजोर होगा। यही कारण है कि जब भी आप कुछ महत्वपूर्ण करते हैं तो आपको आईडी को पुन: उत्पन्न करना होगा। उदाहरण के लिए यदि आप एक पोस्ट बना रहे हैं या व्यवस्थापक में सेटिंग बदल रहे हैं, तो पहले सत्र-पुन: उत्पन्न-आईडी चलाएं। फिर हैकर को फिर से हैकिंग की प्रक्रिया से गुज़रना पड़ता है। यह मूल रूप से हैकर को एक बार एक आईडी के साथ गोली मार दी जाती है जब वह बर्बाद हो जाती है।

http://us.php.net/manual/en/function.session-regenerate-id.php

या आप आईडी को बदल सकते हैं कि हर इतना

बदल जाता है अगर ($ _ सत्र [ 'काउंटर'] == 3) {session_regenerate_id(); $ _ सत्र [ 'काउंटर'] == 0 }

इसके अलावा, $ _SERVER ['HTTP_USER_AGENT'] बहुत विश्वसनीय नहीं है। न केवल उस कारण से बचने की कोशिश करें, बल्कि हैकर्स बीसी के लिए यह सुविधाजनक है क्योंकि वे जानते हैं कि इसके लिए एजेंटों का व्यापक रूप से उपयोग किया जाता है। इसके बजाय $ _SESSION ['id_token'] = sha1 (फ़ाइल मेमोरी, फ़ाइल नाम, समय जैसी कुछ पागल जानकारी) का उपयोग करने का प्रयास करें।

Answer 9

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

उदाहरण: "###। ###। ### .---" केवल '#' के साथ चिह्नित आईपी पते का हिस्सा सत्यापित किया जाएगा।

192.168.1.101
192.168.1.102
192.168.1।XXX

सभी को बराबर माना जाता है।

जैकब