2010-02-21 34 views
5

हमने सेट कुकीज़ के साथ PHP का उपयोग कर डेटाबेस संचालित वेबसाइट बनाई है और अब इसे HTTP स्पूफिंग को रोकने की आवश्यकता है, यह कैसे करें इस पर कोई विचार है? हम इसके साथ शुरुआती हैं इसलिए कोई मदद शानदार होगीHTTP स्पूफिंग को कैसे रोकें?

+1

यूआरएल क्या है ?? –

+0

एक बार जब हम सुरक्षा मुद्दों को पूरा कर लेते हैं तो इसे अपलोड किया जा रहा है – Jermain

उत्तर

6

आप HTTP अनुरोधों को "खराब" नहीं कर सकते हैं। आप सर्वर से अनुरोध भेजते हैं, और सर्वर उचित प्रतिक्रिया देता है।

मुझे लगता है कि आप जो भी रोकने की कोशिश कर रहे हैं वह कुकी स्पूफिंग है। यह ध्यान में रखते हुए कि कुकीज़ क्लाइंट-साइड पर संग्रहीत हैं, उपयोगकर्ताओं को उनकी सामग्री को संशोधित करने से रोकने के लिए आप कुछ भी नहीं कर सकते हैं।

अपनी कुकीज़ में संवेदनशील जानकारी स्टोर न करें। वे ग्राहक द्वारा सुरक्षित और आसानी से पढ़ और संशोधित नहीं हैं।

इसके बजाय PHP सत्र का उपयोग करें। सत्र कैसे काम करते हैं और उन्हें सुरक्षित रखने के तरीके पर पूर्ण स्पष्टीकरण one of my previous answers में पढ़ा जा सकता है।

  • सत्र निर्धारण
    रोकथाम आदेश समय की राशि एक हमलावर चोरी करने के लिए है कम करने के लिए अनुरोध की एक नई session_id हर एक्स संख्या से जेनरेट करें:

    अनिवार्य रूप से, सत्र हासिल करने दो मोर्चों पर किया जाता है आईडी।

  • विशिष्ट ग्राहक
    उपयोग आईपी की पहचान और/या उपयोगकर्ता-एजेंट विशिष्ट ग्राहक की पहचान करने और सत्र में संग्रहीत लोगों के खिलाफ हर पृष्ठ लोड पर कि मान की जाँच करने के लिए। यह वास्तव में केवल दो विकल्प हैं जिन्हें आपको विशिष्ट रूप से क्लाइंट की पहचान करना है।

यहां तक ​​कि उस जगह में साथ

, कोई समाधान नहीं मूर्ख प्रूफ है और एक बार अपने session_id समझौता किया है, तो आप काफी के लिए किया जाता है।

फिर से, गहराई से स्पष्टीकरण के लिए, कृपया my previous answer देखें।

+0

ठीक है धन्यवाद उपयोगी लगता है – Jermain

+0

@Jermain: फिर मेरे उत्तर के बाईं ओर स्थित चेकमार्क पर क्लिक करके अपने स्वीकृत उत्तर का उत्तर देने के लिए स्वतंत्र महसूस करें। –

+0

मैं अभी तक पंजीकृत नहीं हूं लेकिन एक बार पंजीकृत होने पर मैं – Jermain

2

क्या स्पूफिंग? HTTP डेटा स्थानांतरित करने के लिए सिर्फ एक प्रोटोकॉल है, यह वास्तव में कुछ भी खराब नहीं होगा।

ऐसा करने की बात जानकारी की धोखाधड़ी को रोकने के लिए नहीं है, बल्कि क्लाइंट पर कभी भरोसा नहीं करना है। कुकीज के मामले में, कुकी डेटा को स्वीकार करने से पहले डेटाबेस के विरुद्ध तुलना किए गए एक छिद्रित छद्म-यादृच्छिक मान को स्टोर करें।

UPDATED:

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

  1. डेटाबेस

के खिलाफ वास्तविक डेटा

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

    सबसे अच्छा अभ्यास पर कुछ और पढ़ने: http://jaspan.com/improved_persistent_login_cookie_best_practice

  • +0

    हमें HTTP संदेशों को खराब करने के प्रयासों का पता लगाने की आवश्यकता है यदि इससे मदद मिलती है? – Jermain

    +0

    शायद आप जो भी सोचते हैं उसके बारे में एक विशिष्ट उदाहरण का वर्णन कर सकते हैं। –

    +0

    यदि कोई व्यक्ति उस कुकी को पाता है जो PHP सत्र का प्रबंधन करने के लिए उपयोग करता है, तो किसी को अलग मशीन पर किसी को रोकने के लिए मैन्युअल रूप से कुकी को उसी मान पर सेट करना और आपको होने का नाटक करना है? – Jermain

    2

    आप man-in-the-middle छिपकर बातें सुनने को रोकने के लिए चाहते हैं, आप HTTPS है, जो नेटवर्क पर एक सुरक्षित चैनल बनाता है, का उपयोग कर सकते हैं बशर्ते कि पर्याप्त सिफ़र सुइट उपयोग किया जाता है और उस सर्वर प्रमाणपत्र verified and trusted है।

    नोट: मूल प्रश्न संदिग्ध था। अब यह स्पष्ट है कि सवाल कुकी स्पूफिंग के बारे में है।

    +1

    सवाल वास्तव में बकवास है, इसलिए यह उत्तर * एक * इसकी व्याख्या के लिए अच्छी सलाह प्रदान करता है। – deceze

    +0

    हाँ अच्छी तरह से मैंने उल्लेख किया कि मैं एक नौसिखिया था, इसलिए इसे ध्यान में रखें, कहीं – Jermain

    +0

    शुरू करने के लिए आप सही हैं, इसलिए मैंने अपना -1 हटा दिया। –

    0

    स्पूफिंग? समझौता पहचान के साथ एकमात्र वास्तविक समस्या कुकी चोरी है।

    जब भी आप HTTP हेडर पर कुकी भेजते हैं, तो यह जांचने के लिए, यह आईपी पते के विरुद्ध जांचने के लिए आप क्या कर सकते हैं। उदाहरण के लिए:

    <?php 
    session_start(); 
    $rec = db_query('select count(*), ip from session where session_id = "' . session_id() . '"'); 
    
    list ($last_count, $last_ip) = $rec[0]; 
    
    if (! $last_count) { 
        # add it into the database 
        db_query('insert into session (session_id, ip) values (' . 
         '"' . session_id() . '", ' . 
         '"' . $_SERVER['REMOTE_ADDR'] . '"' . 
        ')'); 
    } else { 
        if ($last_ip != $_SERVER['REMOTE_ADDR']) { 
         print "user has stolen a cookie!"; 
        } 
    } 
    ?> 
    

    लेकिन इसका उन लोगों पर नकारात्मक प्रभाव हो सकता है जिनके आईएसपी उन्हें गतिशील आईपी पता जारी करते हैं।

    +0

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

    0

    मुझे पता है कि इसका उत्तर दिया गया है, लेकिन मैं एक और तकनीक जोड़ना चाहता हूं जिसका उपयोग मैं विशेष रूप से प्रशासन लॉग इन के लिए उपयोगी हूं। सामान्य रूप से सत्र का उपयोग करें लेकिन मिश्रण में निर्देशिका सुरक्षा जोड़ें।

    इस तरह यदि कोई सत्र अपहरण कर लिया गया है तो अपहरणकर्ता को भी लॉगिन लॉगिन प्राप्त करने में सक्षम होना चाहिए।

    मैं इस तकनीक का उपयोग फोरम प्रशासन के लिए करता हूं। कुछ मंचों को आसानी से हैक किया जाता है और इससे एक हैकर हो रही है और गंभीर समस्याएं आ रही हैं।

    डीसी

    संबंधित मुद्दे