सुरक्षित और लचीला क्रॉस-डोमेन सत्र

Question

मुझे कोई समस्या है जिसमें मुझे उम्मीद है कि आप सहायता कर सकते हैं। मान लीजिए कि मैं "ब्लैमो" नामक एक कल्पित कंपनी के लिए काम करता हूं, और हमारे पास "लॉग" नामक एक काल्पनिक उत्पाद है। मैं एक सिस्टम स्थापित करने की कोशिश कर रहा हूं जहां कोई logfromblammo.com में लॉग इन कर सकता है और हमारे कुछ उत्पादों को ऑर्डर कर सकता है, और फिर जब वे खरीद के लिए तैयार होते हैं तो चेकआउट.ब्लैममो.com पर उनके ऑर्डर के लिए भुगतान करने के लिए जाते हैं। आखिर में मैं ब्लैमो को अपनी वेबसाइट के साथ एक नया काल्पनिक उत्पाद लॉन्च करने की अनुमति देना चाहता हूं: rockfromblammo.com, और यह साइट checkout.blammo.com के साथ एक सत्र साझा करने में भी सक्षम है ताकि उपयोगकर्ता दोनों उत्पाद में एक शॉपिंग कार्ट रख सकें वेबसाइटों।

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

मैंने ओपनआईडी जैसे समाधानों को संक्षेप में देखा है, लेकिन मुझे हमारे मौजूदा प्रमाणीकरण विधि के साथ जो भी समाधान है, उसे एकीकृत करने में सक्षम होना चाहिए, जो कि बहुत मजबूत नहीं है। क्या अकेले PHP के माध्यम से ऐसा करने का कोई अच्छा तरीका है?

Answer 1

आप क्या कर सकते हैं सत्रों को ले जाने के लिए साइटों के बीच "क्रॉस-ओवर" लिंक बनाते हैं।

क्वेरी स्ट्रिंग के माध्यम से सत्र आईडी को पास करना सबसे आसान तरीका है; जैसे

http://whateverblammo.com/?sessid=XXYYZZ 

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

इसका मतलब यह सुरक्षित नहीं है; एक के लिए, उपयोगकर्ता गलती से पता बार कॉपी/पेस्ट कर सकते हैं और इस प्रकार अपना सत्र निकाल सकते हैं। इस एक्सपोजर को सीमित करने के लिए, आप तुरंत प्राप्त करने के बाद सत्र आईडी के बिना किसी पृष्ठ पर रीडायरेक्ट कर सकते हैं।

ध्यान दें कि सत्र आईडी पर mcrypt() का उपयोग करने से अधिक मदद नहीं मिलेगी, क्योंकि यह समस्या की कीमत की दृश्यता नहीं है; सत्र अपहरण अंतर्निहित मूल्य के बारे में परवाह नहीं करता है, केवल यूआरएल की इसकी पुनरुत्पादन।

आपको यह सुनिश्चित करना होगा कि आईडी केवल एक बार उपयोग की जा सके; यह एक सत्र चर कि रहता है बनाने के द्वारा किया जा सकता है उपयोग का ट्रैक गिनती:

$_SESSION['extids'] = array(); 

$ext = md5(uniqid(mt_rand(), true)); // just a semi random diddy 
$_SESSION['extids'][$ext] = 1; 

$link = 'http://othersite/?' . http_build_query('sessid' => session_id() . '-' . $ext); 

जब प्राप्त किया:

list($sid, $ext) = explode('-', $_GET['sessid']); 
session_id($sid); 
session_start(); 
if (isset($_SESSION['extids'][$ext])) { 
    // okay, make sure it can't be used again 
    unset($_SESSION['extids'][$ext]); 
} 

आप इन कड़ियों हर बार एक सीमा पार कर जाता है की जरूरत है क्योंकि सत्र आखिरी बार से पुनर्जन्म प्राप्त हो सकता है।

Answer 2

तुम इतनी तरह सत्र कुकी डोमेन निर्धारित करने की आवश्यकता:

session_set_cookie_params($lifetime,$path,'.site.com') 

यह तभी साइटों TLD (शीर्ष स्तरीय डोमेन) सहित एक ही डोमेन नाम पर कर रहे हैं काम करेंगे।

, अधिक जानकारी के लिए here देखें

वैकल्पिक रूप से आप पहुँच सत्र की कोशिश कर को देख रहे हैं डोमेन पार, में site2.com को site1.net से है, तो यह नहीं किया जा सकता है।

Answer 3

यह किया जा सकता है, लेकिन सरल कुकीज़ के साथ नहीं और यह मामूली नहीं है। आप जो भी कर रहे हैं वह एक ही साइन ऑन (एसएसओ) समाधान है, जो Google के शेयर के लॉगिन के साथ i.google.com, gmail.com, youtube.com आदि के समान है

मैंने अतीत में इसे लागू करने के लिए ओपनआईडी का उपयोग किया है ।

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

यदि वे पहले से ही लॉग इन हैं (यहां तक ​​कि एक अलग लक्षित साइट से), तो उन्हें फिर से लॉग इन करने की आवश्यकता नहीं है।

उपयोगकर्ता को फिर यूआरएल में टोकन के अतिरिक्त लक्ष्य साइट पर भेजा जाता है। यह टोकन लक्ष्य साइट के सर्वर द्वारा प्रमाणीकरण सर्वर के साथ प्रमाणीकृत सत्यापित करने के लिए उपयोग किया जाता है।

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

Answer 4

तो यह ठीक है आपकी साइट जावास्क्रिप्ट पर भरोसा करने के लिए कार्य करने के लिए, आप शायद कुछ निम्नलिखित की तरह कर सकता है:

आप blammo.com पर एक सत्र हैं और आप rockblammo.com से उस तक पहुंच चाहते हैं। Rockblammo.com पृष्ठ पर आप blammo.com/get-session.js से <script> लोड कर सकते हैं, यह (सर्वर पक्ष से) सत्र-आईडी लौटाएगा। एक बार लौटने के बाद, आप पृष्ठ में एक नया <script> टैग डालते हैं, जो rockblammo.com/set-session.js?sessionId=XXX पर इंगित करता है, जहां XXX आपको सत्र-आईडी है जिसे आपने अभी blammo.com से प्राप्त किया है। अब, rockblammo.com के सर्वर पक्ष पर, सत्र कुकी अद्यतन और इस सत्र-आईडी पर सेट है। आगे बढ़ते हुए, दो पेज अब एक ही सत्र-आईडी साझा करेंगे, और मानते हैं कि उनके पास बैकएंड पर एक ही सत्र स्टोर तक पहुंच है, वे सिंक हो जाएंगे।

उदा। blammo.com/get-session.js से उत्पादन होगा:

var sessionId = "XXX"; 
var s = document.createElement("script"); 
s.src = "/set-session.js?sessionId=" + escape(sessionId); 
document.body.appendChild(s); 

rockblammo.com/set-session.js से उत्पादन खाली होगा, लेकिन इस तरह के रूप में एक HTTP शीर्ष लेख, शामिल होंगे:

Set-Cookie: sessionId=XXX 

आप जावास्क्रिप्ट पर भरोसा नहीं करना चाहते हैं, तो आप कर सकते थे शायद दो साइट्स के बीच आगे और पीछे रीडायरेक्ट करके और सत्र-पासिंग क्वेरी को एक क्वेरी-स्ट्रिंग पैरामीटर (जीईटी परम) में भेजकर ऐसा ही करें।

Answer 5

क्रॉस डोमेन अजाक्स में, आपको वह कुकी मिल सकती है और, बाद में, क्रॉस डोमेन अनुरोधों के लिए सत्र खो जाता है।

header('Access-Control-Allow-Origin: https://example.com'); 
header('Access-Control-Allow-Credentials: true'); 

और जे एस में आप जा रहे: मामले में आप अपने उप s2.example.com आप PHP के लिए हेडर में गुणों का उपयोग करने की आवश्यकता होगी करने के लिए से आप साइट example.com ajax कॉल करने दिया जाएगा

xhrFields: { withCredentials: true } 

अन्यथा कुकीज़ पास नहीं की जाती हैं और आप अपने सबडोमेन पर सत्र का उपयोग नहीं कर सकते हैं। उप डोमेन में

पूर्ण जे एस अनुरोध सत्र की खो बिना हो जाएगा:

$.ajax({ 
    url: "https://s2.example.com/api.php?foo=1&bar=2", 
    xhrFields: { withCredentials: true }, 
    success:function(e){ 
     jsn=$.parseJSON(e); 
     if(jsn.status=="success") { 
       alert('OK!'); 
     } else { 
       alert('Error!'); 
     } 
    } 
})