सत्र अपहरण को रोकने का सबसे अच्छा तरीका क्या है?

Question

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

पूरे वेब साइट के लिए एसएसएल / एचटीटीपीएस एन्क्रिप्शन का उपयोग करने का सबसे अच्छा उत्तर है, और आपके पास सबसे अच्छी गारंटी है कि मध्य हमलों में कोई भी आदमी मौजूदा ग्राहक सत्र कुकी को सूँघ नहीं पाएगा?

और शायद सत्र मूल्य पर कुछ प्रकार के एन्क्रिप्शन का उपयोग करना सबसे अच्छा है जो आपके सत्र कुकी में संग्रहीत है?

यदि किसी दुर्भावनापूर्ण उपयोगकर्ता के पास किसी मशीन तक भौतिक पहुँच होती है, तो वे अभी भी एक वैध सत्र कुकी को पुनः प्राप्त करने के लिए फाइलसिस्टम को देख सकते हैं और सत्र का अपहरण करने के लिए इसका उपयोग कर सकते हैं?

Answer 1

सत्र मान को एन्क्रिप्ट करने का शून्य प्रभाव होगा। सत्र कुकी पहले से ही एक मनमाना मूल्य है, इसे एन्क्रिप्ट करने से सिर्फ एक और मनमाना मूल्य उत्पन्न होगा जिसे सूँघा जा सकता है।

एकमात्र वास्तविक समाधान HTTPS है। यदि आप अपनी पूरी साइट पर एसएसएल नहीं करना चाहते हैं (हो सकता है कि आपको प्रदर्शन की चिंता हो), तो आप संवेदनशील क्षेत्रों की रक्षा करने वाले केवल एसएसएल के साथ ही दूर जा सकते हैं। ऐसा करने के लिए, पहले सुनिश्चित करें कि आपका लॉगिन पृष्ठ HTTPS है। जब कोई उपयोगकर्ता लॉग इन करता है, तो नियमित सत्र कुकी के अलावा एक सुरक्षित कुकी सेट करें (जिसका अर्थ है कि ब्राउज़र केवल इसे SSL लिंक पर प्रसारित करेगा)। फिर, जब कोई उपयोगकर्ता आपके "संवेदनशील" क्षेत्रों में से एक पर जाता है, तो उन्हें HTTPS पर पुनर्निर्देशित करें, और उस सुरक्षित कुकी की उपस्थिति की जांच करें। एक वास्तविक उपयोगकर्ता के पास यह होगा, एक सत्र अपहरणकर्ता नहीं होगा।

EDIT : यह उत्तर मूल रूप से 2008 में लिखा गया था। यह अब 2016 है, और आपकी पूरी साइट पर SSL नहीं होने का कोई कारण नहीं है। कोई और अधिक सरल HTTP!

Comments

HTTPS केवल सूँघने से रोकेगा। लेकिन अगर आपके पास XSS है, या सत्र आईडी का अनुमान आसानी से लगाया जा सकता है, या आप सत्र निर्धारण के लिए कमजोर हैं, या आपका सत्र ID संग्रहण कमजोर (SQL इंजेक्शन?) है, तो SSL बिल्कुल भी सुधार नहीं होगा।

— कैलिमो

@Josh यदि किसी दुर्भावनापूर्ण उपयोगकर्ता के पास किसी मशीन तक भौतिक पहुँच है, तो वे अभी भी एक वैध सत्र कुकी को पुनः प्राप्त करने के लिए फाइल सिस्टम को देख सकते हैं और एक सत्र को हाईजैक करने के लिए उपयोग कर सकते हैं?

— 1

यदि किसी दुर्भावनापूर्ण उपयोगकर्ता के पास किसी फ़ाइल सिस्टम के लिए भौतिक पहुँच है, तो उन्हें एक सत्र को हाईजैक करने की आवश्यकता नहीं है।

— जोश हिनमैन

@जोश। यह सच नहीं है, कभी-कभी किसी उपयोगकर्ता के पास एक फ़ाइल सिस्टम तक सीमित भौतिक पहुंच होती है। कल्पना करें कि सहकर्मी द्वारा टॉयलेट में जाने से बचा हुआ एक लैपटॉप, अब मुझे बस इतना करना है कि उस लैपटॉप पर जाएं, EditThisCookie प्लगइन इंस्टॉल करें, Edit.hisCookie एक्सपोर्ट फीचर का उपयोग करते हुए plus.google.com पर अपने कुकीज़ को पकड़ो और अब मेरे पास उसका खाता है । समय लिया: 18 सेकंड।

— पचेरियर

मुझे पूरा यकीन है कि Google में किसी प्रकार की सुरक्षा सुविधा बिल्ड-इन होगी क्योंकि जाहिर है कि सत्र अपहरण के बारे में बात करते समय आप सबसे पहले सोचते होंगे

— xorinzor

Answer 2

एसएसएल केवल सूँघने के हमलों के साथ मदद करता है। यदि किसी हमलावर के पास आपकी मशीन तक पहुंच है तो मैं मान लूंगा कि वे आपकी सुरक्षित कुकी को भी कॉपी कर सकते हैं।

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

मुझे यकीन नहीं है कि यह विचार काम करेगा लेकिन यहाँ जाता है: अपने सत्र कुकी में एक सीरियल नंबर जोड़ें, शायद इस तरह से एक स्ट्रिंग:

सत्रूइड, सीरियल नंबर, करंट डेट / टाइम

इस स्ट्रिंग को एन्क्रिप्ट करें और इसे अपने सत्र कुकी के रूप में उपयोग करें। क्रम संख्या को नियमित रूप से बदलें - हो सकता है कि जब कुकी 5 मिनट पुरानी हो जाए और फिर कुकी को फिर से जारी करें। यदि आप चाहते हैं तो आप इसे हर पृष्ठ दृश्य पर फिर से जारी कर सकते हैं। सर्वर साइड पर, उस सत्र के लिए आपके द्वारा जारी किए गए अंतिम क्रम संख्या का रिकॉर्ड रखें। यदि कोई कभी गलत सीरियल नंबर के साथ एक कुकी भेजता है तो इसका मतलब है कि एक हमलावर कुकी का उपयोग कर सकता है जिसे उन्होंने पहले से इंटरसेप्ट किया था इसलिए सत्र UUID को अमान्य कर दिया और उपयोगकर्ता से अपना पासवर्ड पुनः दर्ज करने के लिए कहा और फिर एक नया कुकी पुनः जारी किया।

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

Comments

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

— क्रश करें

@ क्रश, लेकिन फिर हमलावर को आवंटित खिड़की के बाद बंद कर दिया जाएगा, है ना? तो बहुत कम से कम हमले की खिड़की छोटी है (एर)।

— जोहानिके जुले

केवल समस्या यह है कि यदि उपयोगकर्ता आपकी वेबसाइट को 5 मिनट के लिए छोड़ देता है, तो उन्हें फिर से लॉगिन करना होगा

— elipoultorak

Answer 3

क्या आपने PHP सुरक्षा पर एक किताब पढ़ने पर विचार किया है? अत्यधिक सिफारिशित।

मुझे गैर एसएसएल प्रमाणित साइटों के लिए निम्न विधि के साथ बहुत सफलता मिली है।

1. एक ही खाते के तहत कई सत्रों की अनुमति दें, सुनिश्चित करें कि आप इसे केवल आईपी पते द्वारा जाँच नहीं कर रहे हैं। लॉग इन पर जनरेट टोकन के बजाय चेक करें जो डेटाबेस में यूजर्स सेशन के साथ-साथ आईपी एड्रेस, HTTP_USER_AGENT और उसके बाद जमा होता है।

2. संबंध आधारित हाइपरलिंक्स का उपयोग करने से एक लिंक उत्पन्न होता है (जैसे। http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) इस लिंक को x-BYTE (पसंदीदा आकार) यादृच्छिक नमकीन MD5 स्ट्रिंग के साथ जोड़ा गया है, पृष्ठ पर पुनर्निर्देशित करने से बेतरतीब ढंग से उत्पन्न होता है। टोकन अनुरोधित पृष्ठ से मेल खाता है।

   • पुनः लोड करने पर, कई जांचें की जाती हैं।
   • आईपी ​​एड्रेस की उत्पत्ति
   • HTTP_USER_AGENT
   • सत्र टोकन
   • तुम समझ गए।

3. लघु जीवन अवधि सत्र प्रमाणीकरण कुकी। जैसा कि ऊपर पोस्ट किया गया है, एक कुकी जिसमें एक सुरक्षित स्ट्रिंग है, जो सत्र वैधता के प्रत्यक्ष संदर्भों में से एक है, एक अच्छा विचार है। हर एक्स मिनट को समाप्त करें, उस टोकन को फिर से जारी करना, और नए डेटा के साथ सत्र को फिर से सिंक्रनाइज़ करना। यदि डेटा में कोई गलत मिलान है, तो या तो उपयोगकर्ता को लॉग आउट करें, या उनके सत्र को फिर से प्रमाणित करें।

मैं इस विषय पर एक विशेषज्ञ के रूप में नहीं हूँ, मुझे इस विशेष विषय में थोड़ा अनुभव था, आशा है कि इसमें से कोई भी किसी को भी मदद करता है।

Comments

क्या कोई ऐसी किताबें हैं जो आप सुझाएंगे?

— रिक्की

विशेष रूप से यह देखते हुए कि ओपी PHP के बारे में विशेष रूप से कुछ भी नहीं बताता है, मैं कहूंगा कि यह सिर्फ एक सामान्य सुरक्षा पुस्तक को देखने के लिए बेहतर है (विशेष रूप से विभिन्न भाषाओं के बीच सुरक्षा केवल कार्यान्वयन विवरण में भिन्न होती है, लेकिन अवधारणाएं समान हैं)।

— matts1

2017 में, यहां तक ​​कि फेसबुक / जीमेल आदि एक ही खाते के तहत कई सत्रों की अनुमति देता है (विशेषकर मोबाइल उपकरणों के साथ) जब तक आप अपने उपयोगकर्ताओं से नफरत नहीं करते, # 1 थोड़ा पुराना है।

— काउबर्ट

Answer 4

// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();

// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);

// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
    end_session();
    header("Location: login.php");
    // add some fancy pants GET/POST var headers for login.php, that lets you
    // know in the login page to notify the user of why they're being challenged
    // for login again, etc.
}

यह क्या करता है जो उपयोगकर्ता के सत्र के बारे में 'प्रासंगिक' जानकारी कैप्चर करता है, जानकारी के टुकड़े जो कि एक सत्र के जीवन के दौरान नहीं बदलना चाहिए। एक उपयोगकर्ता अमेरिका और चीन में एक ही समय में कंप्यूटर पर नहीं जा सकता है, है ना? इसलिए यदि आईपी पता उसी सत्र के भीतर अचानक बदल जाता है जिसका तात्पर्य सत्र अपहरण के प्रयास से है, तो आप सत्र को समाप्त करके उपयोगकर्ता को फिर से प्रमाणित करने के लिए मजबूर करते हैं। यह हैक प्रयास को विफल करता है, हमलावर को सत्र तक पहुंच प्राप्त करने के बजाय लॉगिन करने के लिए भी मजबूर किया जाता है। प्रयास के उपयोगकर्ता को सूचित करें (यह थोड़ा ऊपर ajax), और वोला, थोड़ा नाराज + सूचित उपयोगकर्ता और उनके सत्र / सूचना संरक्षित है।

हम उपयोगकर्ता एजेंट और एक्स-फॉरवर्ड-फॉर में फेंक देते हैं, जो प्रॉक्सी / नेटवर्क के पीछे सिस्टम के लिए एक सत्र की विशिष्टता पर कब्जा करने के लिए अपना सर्वश्रेष्ठ करने के लिए करते हैं। आप अधिक जानकारी का उपयोग करने में सक्षम हो सकते हैं फिर, रचनात्मक होने के लिए स्वतंत्र महसूस करें।

यह 100% नहीं है, लेकिन यह बहुत प्रभावी है।

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

सत्र समाप्त करें, उन्हें अनिश्चित काल के लिए वैध नहीं रहने दें।

कुकीज़ पर भरोसा मत करो, वे चोरी हो सकते हैं, यह सत्र अपहरण के लिए हमले के वैक्टर में से एक है।

Comments

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

— goofballLogic

हैश बनाने की जहमत क्यों? $_SESSION['ident'] = $aip . $bip . $agent;उतना ही सुरक्षित होगा।

— दान ब्रे

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

— करीम

प्रॉक्सी और वीपीएन के बारे में क्या? TOR प्रॉक्सी का उपयोग करने वाला कोई भी व्यक्ति अपने खातों से लगातार साइन आउट हो जाएगा .. वास्तव में हर कुछ मिनटों में।

— ब्रैडले

यहां तक ​​कि अगर आप इसे अनदेखा करते हैं, तो आईपी पते को ग्राहक द्वारा हेरफेर किया जा सकता है, इसलिए यह किसी भी हमलावर को रोकने के लिए बहुत कुछ नहीं करेगा।

— ब्रैडले

Answer 5

सुरक्षित कुकी में वर्णित प्रोटोकॉल का प्रयास करें इसलियू, कोवाक्स, हुआंग और गौडा द्वारा पत्र :

जैसा कि दस्तावेज़ में कहा गया है:

एक सुरक्षित कुकी प्रोटोकॉल जो क्लाइंट और सर्वर के बीच चलता है, उसे निम्नलिखित चार सेवाएं प्रदान करने की आवश्यकता है: प्रमाणीकरण, गोपनीयता, अखंडता और एंटी-रीप्ले।

तैनाती में आसानी के लिए:

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

संक्षेप में: यह सुरक्षित है, हल्का है, मेरे लिए बहुत अच्छा काम करता है।

Comments

आपका लिंक प्रोटोकॉल का एक नमूना है - क्या आपके पास कार्यान्वयन के लिए लिंक है? यह बहुत अच्छा होगा - धन्यवाद।

— एडम

Answer 6

सत्र अपहरण को रोकने का कोई तरीका नहीं है 100%, लेकिन कुछ दृष्टिकोण के साथ हम एक हमलावर के सत्र को अपहरण करने के लिए समय कम कर सकते हैं।

सत्र अपहरण रोकने की विधि:

1 - हमेशा एसएसएल प्रमाणपत्र के साथ सत्र का उपयोग करें;

2 - सत्र कुकी को केवल httponly सेट के साथ सही पर भेजें (सेशन को एक्सेस करने के लिए जावास्क्रिप्ट को रोकें)

2 - लॉगिन और लॉगआउट पर सत्र पुनर्जनन आईडी का उपयोग करें (नोट: प्रत्येक अनुरोध पर सत्र पुनर्जनन का उपयोग न करें क्योंकि यदि आपके पास लगातार अजाक्स अनुरोध है तो आपके पास कई सत्र बनाने का मौका है।)

3 - एक सत्र का समय निर्धारित करें

4 - $ _SESSION चर में ब्राउज़र यूजर एजेंट की तुलना प्रत्येक अनुरोध पर $ _SERVER ['HTTP_USER_AGENT'] से की जाती है।

5 - एक टोकन कुकी सेट करें, और उस कुकी के समाप्ति समय को 0 पर सेट करें (जब तक कि ब्राउज़र बंद न हो जाए)। प्रत्येक अनुरोध के लिए कुकी मान को पुन: बनाएँ। (अजाक्स अनुरोध टोकन कुकी को पुन: उत्पन्न नहीं करने के लिए)। पूर्व:

    //set a token cookie if one not exist
    if(!isset($_COOKIE['user_token'])){
                    //generate a random string for cookie value
        $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

        //set a session variable with that random string
        $_SESSION['user_token'] = $cookie_token;
        //set cookie with rand value
        setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
    }

    //set a sesison variable with request of www.example.com
    if(!isset($_SESSION['request'])){
        $_SESSION['request'] = -1;
    }
    //increment $_SESSION['request'] with 1 for each request at www.example.com
    $_SESSION['request']++;

    //verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
    if($_SESSION['request'] > 0){

        // if it's equal then regenerete value of token cookie if not then destroy_session
        if($_SESSION['user_token'] === $_COOKIE['user_token']){
            $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

            $_SESSION['user_token'] = $cookie_token;

            setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
        }else{
            //code for session_destroy
        }

    }

            //prevent session hijaking with browser user agent
    if(!isset($_SESSION['user_agent'])){
        $_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
    }

    if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
      die('session hijaking - user agent');
    }

नोट: अजाक्स अनुरोध नोट के साथ टोकन कुकी को पुन: उत्पन्न न करें: उपरोक्त कोड एक उदाहरण है। ध्यान दें: यदि उपयोगकर्ता लॉगआउट करते हैं तो कुकी टोकन को सत्र के साथ ही नष्ट कर दिया जाना चाहिए

6 - सत्र हाइजैकिंग को रोकने के लिए उपयोगकर्ता आईपी का उपयोग करना एक अच्छा तरीका नहीं है क्योंकि कुछ उपयोगकर्ता प्रत्येक अनुरोध के साथ आईपी बदलते हैं। उन मान्य उपयोगकर्ताओं का उपयोग करें

7 - व्यक्तिगत रूप से मैं डेटाबेस में सत्र डेटा संग्रहीत करता हूं, यह आपके ऊपर है कि आप किस विधि को अपनाते हैं

यदि आप मेरे दृष्टिकोण में गलती पाते हैं तो कृपया मुझे सुधारें। यदि आपके पास सत्र को रोकने के अधिक तरीके हैं तो कृपया मुझे बताएं।

Comments

नमस्ते, im सत्र अपहरण (ASP.NET में) को रोकने की कोशिश कर रहा है और सभी उपर्युक्त चरणों पर विचार किया गया है। यह लगभग काम कर रहा है, लेकिन जब मैं ब्राउज़र के InPStreetBrowsing / incognito मोड का उपयोग करता हूं तो सत्र हाइजैक हो जाता है। क्या आप सेशन में जोड़ने के लिए कोई अतिरिक्त बात सुझा सकते हैं?

— विश्वनाथ मिश्र

Answer 7

सुनिश्चित करें कि आप सत्र आईडी के लिए पूर्णांक पूर्णांक का उपयोग नहीं करते हैं। GUID का उपयोग करने के लिए बेहतर है, या कुछ अन्य यादृच्छिक रूप से उत्पन्न वर्ण स्ट्रिंग।

Answer 8

सत्र अपहरण से सुरक्षा बनाने के कई तरीके हैं, हालांकि ये सभी या तो उपयोगकर्ता संतुष्टि को कम कर रहे हैं या सुरक्षित नहीं हैं।

• आईपी ​​और / या एक्स-फॉरवर्डेड-फॉर चेक। ये काम, और बहुत सुरक्षित हैं ... लेकिन उपयोगकर्ताओं के दर्द की कल्पना करें। वे वाईफाई के साथ एक कार्यालय में आते हैं, उन्हें नया आईपी पता मिलता है और सत्र खो जाता है। फिर से लॉग-इन करने के लिए मिला।

• उपयोगकर्ता एजेंट की जाँच करता है। ऊपर के समान, ब्राउज़र का नया संस्करण बाहर है, और आप एक सत्र खो देते हैं। इसके अतिरिक्त, ये वास्तव में "हैक" करना आसान है। हैकर्स के लिए नकली यूए स्ट्रिंग्स भेजना तुच्छ है।

• लोकलस्टोरेज टोकन। लॉग-ऑन पर एक टोकन उत्पन्न होता है, इसे ब्राउज़र स्टोरेज में स्टोर करें और इसे एन्क्रिप्टेड कुकी (सर्वर-साइड पर एन्क्रिप्टेड) ​​में स्टोर करें। इसका उपयोगकर्ता के लिए कोई साइड-इफेक्ट नहीं है (लोकलस्टोरेज ब्राउज़र अपग्रेड के माध्यम से बना रहता है)। यह उतना सुरक्षित नहीं है - क्योंकि यह केवल अस्पष्टता के माध्यम से सुरक्षा है। इसके अतिरिक्त, आप जेएस (एन्क्रिप्शन / डिक्रिप्शन) को जेएस में जोड़ सकते हैं ताकि इसे और अस्पष्ट किया जा सके।

• कुकी फिर से चल रही है। यह शायद इसे करने का सही तरीका है। चाल केवल एक ग्राहक को एक समय में एक कुकी का उपयोग करने की अनुमति है। इसलिए, सक्रिय उपयोगकर्ता को हर घंटे या उससे कम समय में फिर से जारी किया जाएगा। यदि नया जारी किया जाता है तो पुरानी कुकी अमान्य है। हैक्स अभी भी संभव है, लेकिन बहुत कठिन है - या तो हैकर या वैध उपयोगकर्ता को अस्वीकार कर दिया जाएगा।

Answer 9

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

Comments

लेकिन आप इस नमक को ग्राहक पक्ष में कैसे संग्रहीत करना चाहते हैं कि कोई भी इसे चुरा न सके?

— Dcortez

Answer 10

AFAIK सत्र ऑब्जेक्ट क्लाइंट पर पहुँच योग्य नहीं है, क्योंकि यह वेब सर्वर पर संग्रहीत है। हालाँकि, सत्र आईडी को कुकी के रूप में संग्रहीत किया जाता है और यह वेब सर्वर को उपयोगकर्ता के सत्र को ट्रैक करने देता है।

सत्र आईडी का उपयोग करके सत्र अपहरण से बचने के लिए, आप सत्र ऑब्जेक्ट के अंदर एक हैशेड स्ट्रिंग को स्टोर कर सकते हैं, जिसे दो विशेषताओं, रिमोट एड्र और रिमोट पोर्ट के संयोजन का उपयोग करके बनाया गया है, जिसे अनुरोध ऑब्जेक्ट के अंदर वेब सर्वर पर एक्सेस किया जा सकता है। ये विशेषताएँ उपयोगकर्ता सत्र को उस ब्राउज़र पर बाँधती हैं जहाँ उपयोगकर्ता ने लॉगिन किया था।

यदि उपयोगकर्ता किसी अन्य ब्राउज़र या एक ही सिस्टम पर एक गुप्त मोड से लॉग इन करता है, तो IP एड्र एक समान रहेगा, लेकिन पोर्ट अलग होगा। इसलिए, जब एप्लिकेशन एक्सेस किया जाता है, तो उपयोगकर्ता को वेब सर्वर द्वारा एक अलग सत्र आईडी सौंपा जाएगा।

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

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    HttpSession session = request.getSession();
    String sessionKey = (String) session.getAttribute("sessionkey");
    String remoteAddr = request.getRemoteAddr();
    int remotePort = request.getRemotePort();
    String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
    if (sessionKey == null || sessionKey.isEmpty()) {
        session.setAttribute("sessionkey", sha256Hex);
        // save mapping to memory to track which user attempted
        Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
    } else if (!sha256Hex.equals(sessionKey)) {
        session.invalidate();
        response.getWriter().append(Application.userSessionMap.get(sessionKey));
        response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId()); 
        response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
        return;
    }
    response.getWriter().append("Valid Session\n");
}

मैंने SHA-2 एल्गोरिथ्म का उपयोग करके baeldung में SHA-256 हैशिंग पर दिए गए उदाहरण का उपयोग करके मूल्य को हैश किया

आपकी टिप्पणी की अपेक्षा करता हूँ।

Comments

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

— Jzf

@ ज़ाफ गलती का इशारा करने के लिए शुक्रिया। मैंने आपके सुझाव के अनुसार अपना उत्तर अपडेट कर दिया है। यदि आपको लगता है कि उत्तर सहायक है तो कृपया अपना डाउन वोट हटा दें।

— Jzf

Answer 11

जोखिम को कम करने के लिए आप मूल आईपी को सत्र के साथ जोड़ सकते हैं। इस तरह एक हमलावर को सत्र का उपयोग करने में सक्षम होने के लिए एक ही निजी नेटवर्क के भीतर होना चाहिए।

रेफर करने वाले हेडर की जांच करना भी एक विकल्प हो सकता है लेकिन वे अधिक आसानी से खराब हो जाते हैं।

Comments

नहीं, आप मूल आईपी का उपयोग नहीं कर सकते, क्योंकि यह बदल सकता है - या तो डायनेमिक आईपी के माध्यम से, जब उपयोगकर्ता अस्थायी रूप से डिस्कनेक्ट हो जाता है, या एक प्रॉक्सी फ़ार्म के (अंतर्निहित या स्पष्ट) उपयोग के माध्यम से बदल जाता है। इसके अलावा, एक ही आईएसपी से आने वाले सत्र अपहरणकर्ता एक वैध उपयोगकर्ता के रूप में एक ही प्रॉक्सी और आईपी का उपयोग कर सकते हैं ...

— ओलाफ कोक

पीएचपी-Nuke उनके सत्र दृष्टिकोण के बारे में एक अच्छा पेज है, और वे के बारे में कैसे आई पी करने के लिए यह hooking नहीं सभी आईएसपी के साथ काम करता है विस्तार से बात करते हैं phpnuke.org/...

— Sembiance

मोबाइल इंटरनेट प्रदाताओं के साथ आईपी बदलना बहुत आम है। वोडाफोन के साथ, मेरा आईपी हर अनुरोध के साथ बदलता है।

— ब्लेज

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

— पीटर

Answer 12

द्वारा संरक्षित करें:

$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;

Comments

मैं यह देखने में विफल हूं कि आप यहां क्या कर रहे हैं।

— समोय